Proposal for DDR Queries

["eberhard speer jr." <se...@ducis.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Irrespective of the future vocabulary etc standards of DeviceMap --
and other, commercial, DDRs -- it is to be expected that certain sites
will not maintain their own 'local' DDR but will rely on 3rd parties.

Below I outline a proposal for standardization of such DDR Queries.
I intend to implement this proposed standard in the coming week, using
the OpenDDR resources on my demo site www.ducis.net/Miri.
When implemented I will post the relevant URL.

Looking forward to your comments,

Kind Regards,

eberhard speer jr.

==========================================
(http://www.ducis.net/Documentation/RFC_DDR_UA.txt)

Additional HTTP/1.1 Header : Ddr-User-Agent

Abstract
This document proposes an additional HTTP request-header field for use
in Device Description Repository (DDR) queries.
All terms used and requirements described in this document are to be
interpreted as described in RFC 2616.

Table of Contents
1. Introduction
2. Overall Operation
3. UA resolution request
4. Ddr-User-Agent
5. DDR Response
6. Colophon

1. Introduction
Web content delivered to mobile devices usually benefits from being
tailored to take into account a range of factors such as screen size,
markup language support and image format support. Such information is
stored in "Device Description Repositories" (DDRs).
(http://www.w3.org/TR/DDR-Simple-API/)

A DDR relies on a request's User-Agent (RFC 2616 sec 14.43) to
identify a device and thus it's properties and capabilities.

A number of APIs covering a range of scenarios to access DDRs have
been described.
The specific scenario addressed in this document is one where the site
receiving the original request relies on a 3rd party DDR accessible
via HTTP.

A number of mainly proprietary APIs describe message/response formats
for this type of services. The object here is to propose a standard
communication format, specifically dealing with the issue of
transferring the original request's user-agent string (UA) to the 3rd
party DDR via HTTP.

2. Overall Operation

request ----> content site
              extract request UA
              UA resolution request ----> DDR
                                    <---- DDR Response
              content formatting
        <---- content response

3. UA resolution request
In order to avoid :
- - possible issues with transferring the original request's UA, URL
encoded, as part of an URL's query string,
- - proprietary formats;
and in order to facilitate :
- - the simplest possible approach,
- - functionality scaling using RESTy and/or proprietary messaging formats,
this standard proposed that the UA resolution request uses an
additional HTTP request-header field : Ddr-User-Agent.

4. Ddr-User-Agent
The Ddr-User-Agent request-header field for UA resolution requests is
identical to the User-Agent header field as described in RFC 2616 sec
14.43, except that :
- - it contains the UA from the original request as received by the
content site, to be resolved by the DDR
- - it MUST be included in an UA resolution request to a DDR

Example:

       Ddr-User-Agent: SoftBank/1.0/832T/TJ001

DDR in this case can be read as Device Description Request.

Header Field Name : Ddr-User-Agent
Protocol : http
Status : (proposed) standard
Reference : http://www.ducis.net/Documentation/RFC_DDR_UA.txt

5. DDR Response
This standard further proposes that the DDR's response consists of :

1 - response codes : standard HTTP status codes (RFC 2616 sec 10)
where the following status codes are assumed to have 'additional'
meaning :

204 - No Content : UA in Ddr-User-Agent header field could not be
identified/resolved.
400 - Bad Request : Ddr-User-Agent header field missing.

2 - response body : the response body MUST only contain, vocabulary
dependent property-value, key-value pairs in the data serialization
format indicated in the response's Content-Type (MIME) header.

6. Colophon
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.
Distribution of this memo is unlimited.

6.1 Version
- - 08/12/2012 : basic RFC : esjr :
http://www.ducis.net/Documentation/RFC_DDR_UA.txt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQwt+AAAoJEOxywXcFLKYcK/YIAMWfnhM1y3CAOnTC/7Tqviyv
vblB6tuIT3XeTdZts/g+LciHz3gMW8JbkUqsD1Y4ULx3DeceBVVTxKblpzst1UjB
zk5erM+VtxEDSfK9w1ot0RBgWJ3YQNcJjDw9RFeg66yic90w47NCB7hV3KoJy+Tz
aPOYGfzXgzveY2MU0H+zs8seXsnXUieH10JAh43gvpv+aVKivDw0JdyJKSn2D8v6
TqyaMm7ZrlJPbWHSuzHthGNP70ad5cwmDxMNv8srKU/FDHUHAeyc+c7mfc9QAPbe
tgFalLVNyqAS1WlhcVmzIn7njYVaFzjfX3q/ztWNtQPzWd2WXNUp8LxoTudJeBc=
=BX+u
-----END PGP SIGNATURE-----