-----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-----
