Network Working Group H. Ohto Internet-Draft World Wide Web Expires: October 30, 2000 Consortium/Panasonic. J. Hjelm World Wide Web Consortium/Ericsson. May 2000 CC/PP exchange protocol based on HTTP Extension Framework draft-ietf-ohto-ccpp-exchange-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 30, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract In this document we describe the CC/PP exchange protocol based on the HTTP Extension Framework[1]. CC/PP[3], "Composite Capability/Preference Profiles: A user side framework for content negotiation", is an extensible format based on RDF[4], RDF-Schema[5] for describing device capabilities and user preferences. CC/PP can be provided by the user to servers and content providers. The servers can use this information describing the user's preferences to customize the service or content provided. The ability of RDF to reference profile information via URIs assists in minimizing the number of network transactions required to adapt content to a device, while the CC/PP fits well into the current and future protocols being developed. This document proposes a HTTP extension Ohto & Hjelm Expires October 30, 2000 [Page 1] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 called "CC/PP exchange protocol" to exchange CC/PP descriptions effectively. The CC/PP exchange protocol is based on the HTTP Extension Framework and complies with [HTTP/1.1[2]]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic requirements for CC/PP exchange protocol . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol considerations . . . . . . . . . . . . . . . . . . 6 5. CC/PP exchange protocol . . . . . . . . . . . . . . . . . . 7 5.1 Extension Declaration . . . . . . . . . . . . . . . . . . . 7 5.2 Header fields . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.1 Profile header . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.2 Profile-Diff header . . . . . . . . . . . . . . . . . . . . 10 5.2.3 Profile-warning header . . . . . . . . . . . . . . . . . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1 Mandatory and end-to-end . . . . . . . . . . . . . . . . . . 15 6.2 Optional and end-to-end . . . . . . . . . . . . . . . . . . 17 6.3 Mandatory and hop-by-hop . . . . . . . . . . . . . . . . . . 18 6.4 Optional and hop-by-hop . . . . . . . . . . . . . . . . . . 20 6.5 Response with Warning . . . . . . . . . . . . . . . . . . . 22 6.6 Enable the HTTP cache expiration model(end-to-end) . . . . . 23 6.7 Enable the HTTP cache expiration model(hop-by-hop) . . . . . 24 7. Security considerations . . . . . . . . . . . . . . . . . . 27 References . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 Ohto & Hjelm Expires October 30, 2000 [Page 2] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 1. Introduction The CC/PP framework is a mechanism for describing the capabilities and preferences associated with users and user agents accessing the World Wide Web. Information about user agents includes the hardware platform, system software, applications and user preferences (P3P[6]). The user agent capabilities and preferences can be thought of as metadata,or properties and descriptions of the user agent's hardware and software. The CC/PP descriptions are intended to provide information necessary to adapt the content and the content delivery mechanisms to best fit the capabilities and preferences of the user and its agents. The major disadvantage of this format is that it is verbose. Some networks are very slow and this would be a moderately expensive way to handle metadata. There are several optimizations possible to help deal with network performance issues. One strategy is to use a compressed form of XML (e.g. WBXML[14]), and a complementary strategy is to use references(URIs). Instead of enumerating each set of attributes, a reference can be used to name a collection of attributes such as the hardware platform defaults. This has the advantage of enabling the separate fetching and caching of functional subsets. Another problem is to propogate changes to the current CC/PP descriptions to an origin server, a gateway or a proxy. One solution is to transmit the entire CC/PP descriptions with each change. This is not ideal for slow networks. An alternative is to send only the changes. The CC/PP exchange protocol does not depend on the profile format which it conveys. Therefore another profile format besides the CC/PP description format could be applied to the CC/PP exchange protocol. Ohto & Hjelm Expires October 30, 2000 [Page 3] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 2. Basic requirements for CC/PP exchange protocol The basic requirements for the CC/PP exchange protocol are listed below. 1. The transmissions of the CC/PP descriptions should be HTTP/1.1-compatible. 2. The CC/PP exchange protocol should support an indirect addressing scheme based on RFC2396[7] for referencing profile information. 3. Components used to construct CC/PP descriptions, such as vendor default descriptions, should be independently cacheable. 4. The CC/PP exchange protocol should provide a lightweight exchange mechanism that permits the client to avoid resending the elements of the CC/PP descriptions that have not changed since the last time the information was transmitted. Ohto & Hjelm Expires October 30, 2000 [Page 4] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 3. Terminology All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) used by HTTP/1.1[2]. Implementors will need to be familiar with the notation in order to understand this specification. The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," "MAY," and "MAY NOT" in this document are to be interpreted as described in RFC2119[8]. The many terms used in this document are defined and explained in the HTTP/1.1 specification[2], including "client," "user agent," "server," "origin server," "proxy," "gateway," "request-header," "response-header," "field-name," "field-value," "end-to-end," "hop-by-hop," "quoted-string," "HTTP-date," "first-hand," "fresh" and "stale". The reader is expected to be familiar with the HTTP/1.1 specification and its terminology. The following terms are used in this specification. o CC/PP description : The device capabilities and user preferences which are described in the CC/PP framework. A CC/PP description is intended to provide information necessary to adapt the content and the content delivery mechanisms to best fit the capabilities and preferences of the user and its agents. o CC/PP repository : An application program which maintains CC/PP descriptions. The CC/PP repository should be HTTP/1.0 or HTTP/1.1 compliant. The CC/PP repository is not required to comply with the CC/PP exchange protocol. Ohto & Hjelm Expires October 30, 2000 [Page 5] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 4. Protocol considerations Our protocol strategy is to send a request with profile information as little as possible using references(URIs). For example, a user agent issues a request with URIs which address the profile information, and if the user agent changes the value of an attribute, such as turning sound off, only that change is sent together with the URIs. When an origin server receives the request, the origin server inquires of CC/PP repositories the CC/PP descriptions using the list of URIs. Then the origin server creates a tailored content using the fully enumerated CC/PP descriptions. The origin server might not obtain the fullyenumerated CC/PP descriptions when any one of the CC/PP repositories is not available. In this case, it depends on the implementation whether the origin server should respond to the request with a tailored content, a non-tailored content or an error. In any case, the origin server should inform the user agent of the fact. A warning mechanism has been introduced for this purpose. It is likely that an origin server, a gateway or a proxy will be concerned with different device capabilities or user preferences. For example, the origin server may have responsibility to select content according to the user preferred language, while the proxy may have responsibility to transform the encoding format of the content. Therefore gateways or proxies might not forward all profile information to an origin server. The CC/PP exchange protocol might convey natural language codes within header field-values. Therefore internationalization issues must be considered. The internationalization policy of the CC/PP exchange protocol is based on RFC2277[9]. Considering how to maintain a session like RTSP (RFC2326[13]) is worthwhile from the point of view of minimizing transactions(i.e. the session mechanism could permit the client to avoid resending the elements of the CC/PP descriptions that have not changed since the last time the information was transmitted). However a session mechanism would reduce cache efficiency, and requires maintaining states between a user agent and an origin server (RFC2109[12]). The CC/PP exchange protocol is designed as a session-less(stateless) protocol. A session mechanism for exchanging CC/PP is beyond the scope of this specification. It might be designed for the future version of the CC/PP exchange protocol. Ohto & Hjelm Expires October 30, 2000 [Page 6] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 5. CC/PP exchange protocol We propose the CC/PP exchange protocol based on the HTTP Extension Framework. The HTTP Extension Framework is a generic extension mechamism for HTTP/1.1, which is designed to interoperate with existing HTTP applications. 5.1 Extension Declaration An extension declaration is used to indicate that an extension has been applied to a message and possibly to reserve a part of the header namespace identified by a header field prefix. The HTTP Extension Framework introduces two types of extension declaration strenght: mandatory and optional, and two types of extension declaration scope: hop-by-hop and end-to-end(See HTTP extension Framework[1].) Which type of the extension declaration strengths and/or which type of the extension declaration scopes should be used depends on what the user agent needs to do. The strength of the extension declaration should be mandatory if the user agent needs to obtain an error response when a server(an orgin server, a gateway or a proxy) does not comply with the CC/PP exchange protocol. The strength of the extension declaration should be optional if the user agent needs to obtain the non-tailored content when a server does not comply with the CC/PP exchange protocol. The scope of the extension declaration should be hop-by-hop if the user agent has an apriori knowledge that the first hop proxy complies with the CC/PP exchange protocol. The scope of the extension declaration should be end-to-end if the user agent has an apriori knowledge that the first hop proxy does not comply with the CC/PP exchange protocol, or the user agent does not use a proxy. The extension identifier for the CC/PP exchange protocol is as follows: "http://www.w3.org/1999/06/24-CCPPexchange" NOTE: The integrity and persistence of the extension identifier("http://www.w3.org/1999/06/24-CCPPexchange") should be maintained and kept unquestioned throughout the lifetime of the extension. The name space prefix is generated dynamically.(See Section 3. Extension Declarations of HTTP extension Framework spec[1].) Ohto & Hjelm Expires October 30, 2000 [Page 7] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 5.2 Header fields 5.2.1 Profile header The Profile header field is a request-header field, which conveys a list of references which address CC/PP descriptions. The grammar for the Profile header field is as follows: Profile = profile-field-name ":" 1#reference profile-field-name = "Profile" reference = <"> ( absoluteURI | profile-diff-name ) <"> profile-diff-name = profile-diff-number "-" profile-diff-digest profile-diff-number = 1#DIGIT profile-diff-digest = DIGIT = The Profile header field-value is a list of references. Each reference in the Profile header field represents the corresponding entity of the CC/PP description. A reference is either an absoluteURI or a profile-diff-name. An entity of a CC/PP description which is represented by an absoluteURI exists outside of the request, and an entity of a CC/PP description which is represented by a profile-diff-name exisits inside of the request(i.e. in the Profile-Diff header field. See Profile-Diff header (Section 5.2.2)). The absoluteURI in the Profile header field addresses an entity of a CC/PP description which exists in the World Wide Web. CC/PP descriptions may originatefrom multiple sources(e.g. hardware vendors, software vendors, etc). A CC/PP description which is provided by a hardware vendor or a software vendor SHOULD be addressed by an absoluteURI. A user agent issues a request with these absoluteURIs in the Profile header instead of sending whole CC/PP descriptions, which contributes to reducing the amount of transaction. The syntax of the absoluteURI MUST conform to RFC2396[7]. An absoluteURI can unambiguously be distinguished from a profile-diff-name by the presence of a colon(":") in the Profile header field-value. The profile-diff-name in the Profile header field addresses a CC/PP description in the corresponding Profile-Diff header within the same request. When the Profile header field includes a profile-diff-name, the corresponding Profile-Diff header MUST be included within the same request. The main reason why the profile-diff-name is introduced is to specify the priority of each CC/PP description in the Profile header field-value. The priority is indicated by the order of references(i.e. absoluteURI or profile-diff-name) in the Profile Ohto & Hjelm Expires October 30, 2000 [Page 8] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 header field-value. The latest reference in the Profile header field-value has the highest priority. Therefore a CC/PP description which is represented by the latest reference can override CC/PP descriptions which are represented by the precedent references. This is the default behavior in the absence of schema rules. NOTE: The CC/PP schema provides its own overriding/protection rules. When applying these schema, a CC/PP description which is represented by the latest reference must not override the precedent CC/PP descriptions. The profile-diff-name consists of a profile-diff-number part and a profile-diff-digest part. The profile-diff-number is the number which indicates the corresponding Profile-Diff header. Multiple Profile-Diff headers are allowed to appear in the same request. Threfore the profile-diff-number is introduced for the purpose of indicating the corresponding Profile-Diff header. The profile-diff-number is generated, and corresponds to the suffix of the corresponding Profile-Diff header field-name in the same request. The profile-diff-digest is generated by applying MD5 message digest algorithm(RFC1321[10]) and Base64 algorithm(See Section 6.8. Base64 Content-Transfer-Encoding in the MIME specification(RFC2045[11])) to the corresponding Profile-Diff header field-value. The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. The Base64 algorithm takes as input arbitrary binary data and produces as output printable encoding data of the input. The profile-diff-digest is introduced for the efficiency of the cache table look up in gateways, proxies and user agent.When the server uses some headers to select a representation that is subject to server-driven negotiation, these headers SHOULD be included in the Vary header field(See section 13.6 for use of the Vary header field by caches and section 14.44 for use of the Vary header field by servers in HTTP/1.1[2].) In that case, with introducing the profile-diff-digest, only the Profile header should be included in the Vary header instead of including the Profile header and the all multiple Profile-Diff headers because the profile-diff-digest(finger print of the Profile-Diff header field-value) could represent the Profile-Diff header field-value. Therefore gateways, proxies and user agent look up and examine only the Profile header for the validation of the cache expiration model. The generation method of the profile-diff-name is as follows: 1. The MD5 algorithm is applied to the CC/PP description which is Ohto & Hjelm Expires October 30, 2000 [Page 9] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 the value of the corresponding Profile-Diff header field. 2. The Base64 algorithm is applied to the output of step1. 3. Insert the profile-diff-number at the head of the output of step2. The examples of the Profile header are as follows: Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw" Profile: "http://www.aaa.com/hw","1-uKhJE/AEeeMzFSejsYshHg==", "http://www.bbb.com/sw" NOTE: There is a choice to put all the references and CC/PP descriptions in one header instead of separating multiple Profile-Diff headers from Profile header. It is simple but we do not introduce this solution. The reasons are as follows: 1. The headers should be small because some implementations of servers and proxies have the restriction of the header length. 2. It is difficult to parse the header field when the profile descriptions and URI are mixed within the same header field-value. 3. The CC/PP exchange protocol aims for independence from the profile format which it conveys. Therefore the mixture of references and profile descriptions is undesirable. ( e.g. when a profile format is required to add an absoluteURI at the top of the profile description, it causes problems.) 5.2.2 Profile-Diff header The Profile-Diff header field is a request-header field, which contains CC/PP description. The Profile-Diff header field is always used with Profile header in the same request(See Profile header (Section 5.2.1)). All profile information could be represented by absoluteURIs in the Profile header. In this case, the Profile-Diff header field does not have to be added to the request. On the other hand, only one Profile-Diff header can contain all profile information. In this case, the Profile header includes only the profile-diff-name which indicates the Profile-Diff header. Ohto & Hjelm Expires October 30, 2000 [Page 10] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 The grammar for the Profile-Diff header field is as follows: Profile-Diff = profile-diff-field-name ":" profile-desc profile-diff-field-name = "Profile-Diff-" profile-diff-number profile-desc = The Profile-Diff header field-name(profile-diff-field-name) consists of the prefix("Profile-Diff-") and the following profile-diff-number. The profile-diff-number is the number which indicates the corresponding profile-diff-name in the Profile header. Multiple Profile-Diff headers are allowed to appear in the same request. Threfore the profile-diff-number is introduced for the purpose of indicating the corresponding profile-diff-name in the Profile header. The profile-diff-number is generated and corresponds to the prefix of the profile-diff-name in the Profile header field within the same request(See Profile header (Section 5.2.1)). The profile-diff-number SHOULD be increased by 1 when a Profile-Diff header is added by a user agent, a gateway, or a proxy. The examples of the profile-diff-field-name are as follows: Profile-Diff-1: Profile-Diff-10: It MUST NOT be allowed to appear "0" at the head of the profile-diff-number because of avoiding ambiguity of correspondence. (e.g, "Profile-Diff-01:" or "Profile-Diff-0015" is not allowed). Multiple Profile-Diff headers MUST NOT have the same profile-diff-number in the same request. The format of the profile-desc complies with the HTTP/1.1 specification. The HTTP/1.1 header field-values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as a space(SP). Having the HTTP/1.1 cache mechanisms work well, the Profile-Diff header field-value SHOULD shape into some kind of canonical representations(See in the Canonical XML Version 1.0[15]). NOTE : The canonical representation form will be introduced from the related activities(XML Core WG in W3C) when the specification is fixed. NOTE: To minimize the transaction of CC/PP descriptions, we might consider a binary representation of a CC/PP description. In this case, the binary representation might not be included within the Ohto & Hjelm Expires October 30, 2000 [Page 11] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 HTTP header field because of the confliction between CR/LF code and the part of the binary representation. The birary representation should be included in the entity body. To consider the binary representation is beyond the scope of this specification. The Profile-Diff header can contain complete CC/PP description. In this case, the Profile header includes only the profile-diff-name which indicates the Profile-Diff header. The example is as follows: Profile: "1-P1GRkSjKK50aTWXXndFcSQ==" Profile-Diff-1: ..... 5.2.3 Profile-warning header The Profile-warning header field is a response-header field, which is used to carry warning information. When a client issues a request with the Profile header field to a server, the server inquires of CC/PP repositories the CC/PP descriptions using the absoluteURIs in the Profile header field. If any one of the CC/PP repositories is not available, the server might not obtain the fully enumerated CC/PP descriptions, or the server might not obtain first-hand or fresh CC/PP descriptions. The server SHOULD respond to the client with the Profile-warning Ohto & Hjelm Expires October 30, 2000 [Page 12] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 header field if any one of the CC/PP descriptions could not be obtained, or any one of the CC/PP descriptions is stale. The grammar for the Profile-warning header field is as follows: Profile-warning = profile-warning-field-name ":" 1#warning-value profile-warning-field-name = "Profile-Warning" warning-value = warn-code SP warn-target SP warn-text [SP warn-date] warn-code = 3DIGIT warn-target = (absoluteURI | host [ ":" port ]) warn-text = quoted-string warn-date = <"> HTTP-date <"> The definitions of the absoluteURI and the host are given from RFC2396[7], and the definitions of the quoted-string and the HTTP-date are given from HTTP/1.1[2]. The warn-code assignes three digits. The "1xx" indicates the status of the CC/PP description(e.g. it is fresh or stale). The "2xx" indicates the type of the content adaptation applied to the message(e.g. content selection, content transformation, or content generation). The warn-target indicates either the absoluteURI or the host corresponding to the type of the warn-code. The warn-target indicates the absoluteURI when the warn-code forms "1xx". The warn-target indicates the host when the warn-code forms "2xx". This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its meaning. o 100 OK : MAY be included if the CC/PP repository replies with first-hand or fresh information. The warn-target indicates the absoluteURI which addresses the CC/PP descriptions in the CC/PP repository. o 101 Used stale profile : MUST be included if the CC/PP repository replies with stale information. Whether the CC/PP description is stale or not is decided in accordance with the HTTP header information with which the CC/PP repository responds(i.e. when the HTTP/1.1 header includes the Warning header field whose warn-code is 110 or 111.). The warn-target indicates the absoluteURI which addresses the CC/PP description in the CC/PP repository. o 102 Not used profile : MUST be included if the CC/PP description could not be obtained(e.g. the CC/PP repository is not available.).The warn-target indicates the absoluteURI which addresses the CC/PP description in the CC/PP repository. Ohto & Hjelm Expires October 30, 2000 [Page 13] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 o 200 Not applied : MUST be included if the server replies with the non-tailored content which is the only one representation in the server. The warn-target indicates the host which addresses the server. o 201 Content selection applied : MUST be included if the server replies with the content which is selected from one of the representations in the server. The warn-target indicates the host which addresses the server. o 202 Content generation applied : MUST be included if the server replies with the tailored content which is generated by the server. The warn-target indicates the host which addresses the server. o 203 Transformation applied : MUST be added by an intermediate proxy if it applies any transformation changing the content-coding (as specified in the Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the response. The warn-target indicates the host which addresses the proxy. The examples of the Profile-warning header are as follows: Profile-Warning:102 http://www.aaa.com/hw "Not used profile", 202 www.w3.org "Content generation applied" Profile-Warning:101 http://www.aaa.com/hw "Used stale profile", 102 http://www.bbb.com/sw "Not used profile", 200 18.23.0.23:80 "Not applied" "Wed, 31 Mar 1999 08:49:37 GMT" Ohto & Hjelm Expires October 30, 2000 [Page 14] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 6. Examples The following examples show some scenarios using the CC/PP exchange protocol. 6.1 Mandatory and end-to-end The scenario is listed below. 1. The user agent issues a mandatory extension request(M-GET) with the Profile header and the Profile-Diff header. The Profile-Diff header field-name is generated dynamically. The name space header prefix "99" of the Profile and the Profile-Diff header field-name is generated and correspond to the name space indicator "ns=99" in the extension declaration header(Man). Furthermore, the suffix number "1" of the Profile-Diff header field-name "99-Profile-Diff-1" is generated and corresponds to the prefix "1" of the profile-diff-name "1-uKhJE/AEeeMzFSejsYshHg==" in the Profile header field in the same request. In this example, only one Profile-Diff header field apprears in the request. However multiple Profile-Diff headers could apprear in a request if needed. 2. The origin server examines the extension declaration header and determines if it is supported for this message, If not, it responds with a 510(Not Extended) status code. 3. Otherwise the origin server splits the "M-" prefix from the method name and processes the remainder of the request according to the semantic of the extension and of the existing HTTP/1.1 method name(GET), and then the origin server gets the list of the references(i.e. absoluteURI and profile-diff-name) in the Profile header field. After that the origin server issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs("http://www.aaa.com/hw","http://www.bbb.com/sw"). These requests/reponses can be cached by the usual HTTP cache mechanisms so that these requests are HTTP requests. 4. The origin server generates the tailored content according to the enumerated CC/PP descriptions, and sends back the tailored content with the mandatory extension response header(Ext). In this example, the content is not cacheable so that the origin server indicates no-cache directives in the Cache-control header field. Ohto & Hjelm Expires October 30, 2000 [Page 15] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 The requests and responses according to the scenario is described below. [1. UserAgent --> OriginServer] M-GET /a-resource HTTP/1.1 Host: www.w3.org Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=99 99-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" 99-Profile-Diff-1: [2. OriginServer --> UserAgent (case of failure)] HTTP/1.1 510 Not Extended [3. OriginServer --> CCPPrepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [4. OriginServer --> UserAgent] HTTP/1.1 200 OK Ext: Cache-control: no-cache Content-Type: text/html Content-Length: 1200 .... Ohto & Hjelm Expires October 30, 2000 [Page 16] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 NOTE: If the Profile-Diff header field is too long, the request(1.) might not be successful because some implementations of origin server/gateway/proxy restrict the length of headers. The alternative is to transmit runtime changes in an entity body. This solution is beyond the scope of the CC/PP exchange protocol. [0. UserAgent --> OriginServer] M-POST /a-resource HTTP/1.1 Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=99 99-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw", "uKhJE/AEeeMzFSejsYshHg==" Host: www.w3.org Content-Type: text/xml Content-Length: 258 6.2 Optional and end-to-end The scenario is listed below. 1. The user agent issues an optional extension request(GET) with the Profile header and the Profile-Diff header. 2. The origin server examines the extension declaration header(Opt) and determines if it is supported for this message. If not, the origin server ignores the extension headers, and sends back the non-tailored content. 3. Otherwise, the origin server gets the list of the absoluteURIs in the Profile header field. After that the origin server issues requests to the CC/PP repositories to get the CC/PP descriptions using these absoluteURIs. 4. The origin server generates the tailored content according to the enumerated CC/PP descriptions, and sends back the tailored content. The requests and responses according to the scenario is described below. [1. UserAgent --> OriginServer] GET /a-resource HTTP/1.1 Host: www.w3.org Opt: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=19 Ohto & Hjelm Expires October 30, 2000 [Page 17] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 19-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" 19-Profile-Diff-1: [2. OriginServer --> UserAgent (case of failure)] HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1200 .... [3. OriginServer --> CCPPrepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [4. OriginServer --> UserAgent] HTTP/1.1 200 OK Cache-control: no-cache Content-Type: text/html Content-Length: 1200 .... 6.3 Mandatory and hop-by-hop The scenario is listed below. 1. The user agent issues a mandatory extension request(M-GET) with the Profile header and the Profile-Diff header. According to the HTTP extension framework specification for the hop-by-hop extension, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. In this example, "C-Man", "64-Profile" and "64-Profile-Diff-1" are protected by the Connect header field. 2. The first-hop proxy examines the extension declaration header(C-Man) and determines if it is supported for this message. If not, it responds with a 510(Not Extended) status code. Ohto & Hjelm Expires October 30, 2000 [Page 18] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 3. Otherwise, the first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs. 4. The first-hop proxy generates the request with the Accept, Accept-Charset, Accept-Encoding and Accept-Language, using the enumerated CC/PP descriptions, and issues the request to the origin server. 5. The origin server responds to the first-hop proxy with the content. 6. The first-hop proxy transforms the content into the tailored content using the enumerated CC/PP descriptions. After that the first-hop proxy sends back the tailored content with the mandatory hop-by-hop extension response header(C-Ext). The requests and responses according to the scenario is described below. [1. UserAgent --> Proxy] M-GET /a-resource HTTP/1.1 Host: www.w3.org C-Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=64 64-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" 64-Profile-Diff-1: Connection: C-Man, 64-Profile, 64-Profile-Diff-1 [2. Proxy --> UserAgent (case of failure)] HTTP/1.1 510 Not Extended [3. Proxy --> CCPPrepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [4. Proxy --> OriginServer] GET /a-resource HTTP/1.1 Host: www.w3.org Accept: text/xml, text/html, */* Ohto & Hjelm Expires October 30, 2000 [Page 19] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 Accept-Charset: UTF-16, iso-2022-JP Accept-Encoding: compress, gzip Accept-Language: ja, en [5. OriginServer --> Proxy] HTTP/1.1 200 OK Cache-control: no-cache Content-Type: text/html; charset=UTF-16 Content-Encoding: compress Content-Language: ja Content-Length: 1200 .... [6. Proxy --> UserAgent] HTTP/1.1 200 OK C-Ext: Cache-control: no-cache Content-Type: text/xml; charset=UTF-16 Content-Encoding: compress Content-Language: ja Content-Length: 900 .... 6.4 Optional and hop-by-hop The scenario is listed below. 1. The user agent issues an optional extension request(GET) with the Profile header and the Profile-Diff header. 2. The first-hop proxy examines the extension declaration header(C-Opt) and determines if it is supported for this message. If not, the first-hop proxy foreward requests to the origin server after the first-hop proxy get rid of the headers which are listed in the Connection header. 3. Otherwise, the first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs. 4. The first-hop proxy generates the request and issues the request to the origin server. 5. The origin server responds to the first-hop proxy with the content. 6. The first-hop proxy transforms the content into the tailored content using the enumerated CC/PP descriptions. After that the first-hop proxy sends back the tailored content to the user Ohto & Hjelm Expires October 30, 2000 [Page 20] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 agent. The requests and responses according to the scenario is described below. [1. UserAgent --> Proxy] GET /a-resource HTTP/1.1 Host: www.w3.org C-Opt: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=80 80-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" 80-Profile-Diff-1: Connection: C-Opt, 80-Profile, 80-Profile-Diff-1 [2. Proxy --> OriginServer (case of failure)] GET /a-resource HTTP/1.1 Host: www.w3.org [3. Proxy --> CCPPrepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [4. Proxy --> OriginServer] GET /a-resource HTTP/1.1 Host: www.w3.org Accept: text/xml, text/html, */* Accept-Charset: UTF-16, iso-2022-JP Accept-Encoding: compress, gzip Accept-Language: ja, en [5. OriginServer --> Proxy] HTTP/1.1 200 OK Cache-control: no-cache Content-Type: text/html; charset=UTF-16 Content-Encoding: compress Content-Language: ja Content-Length: 1200 .... [6. Proxy --> UserAgent] Ohto & Hjelm Expires October 30, 2000 [Page 21] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 HTTP/1.1 200 OK Cache-control: no-cache Content-Type: text/xml; charset=UTF-16 Content-Encoding: compress Content-Language: ja Content-Length: 900 .... 6.5 Response with Warning The scenario is listed below. 1. The user agent issues a request. 2. The origin server issues requests to the CC/PP repositories to get the CC/PP descriptions. 3. The CC/PP description is obtained successfully(200 OK) from "http://www.aaa.com/hw", while the CC/PP description could not be obtained (404 Not Found) from "http://www.bbb.com/sw". 4. The origin server generates the tailored content using only the CC/PP description from "http://www.aaa.com/hw", and sends back the tailored content with the Profile-Warning response header. (when the origin server did not obtain the fully enumerated CC/PP descriptions, it depends on the implementation whether the origin server should respond to the request with a tailored content, a non-tailored content or an error.) Ohto & Hjelm Expires October 30, 2000 [Page 22] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 The requests and responses according to the scenario is described below. [1. UserAgent --> OriginServer] M-GET /a-resource HTTP/1.1 Host: www.w3.org Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=25 25-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw" [2. OriginServer --> CCPPrepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [3. CCPPrepositories --> OriginServer] HTTP/1.1 200 OK ;; www.aaa.com .... HTTP/1.1 404 Not Found ;; www.bbb.com [4. OriginServer --> UserAgent] HTTP/1.1 200 OK Ext: 25-Profile-warning: 102 http://www.bbb.com/sw "Not used profile", 202 www.w3.org "Content generation applied" Cache-control: no-cache Content-Type: text/html Content-Length: 1200 .... 6.6 Enable the HTTP cache expiration model(end-to-end) The scenario is listed below. 1. The user agent issues a request. 2. The origin server issues requests to the CC/PP repositories to get the CC/PP descriptions. 3. The origin server generates and sends back the tailored content. In this example, the origin server indicates no-cache="Ext" and max-age=1200 directives in the Cache-control header field, which means the origin server intends to use the HTTP cache expiration model. The Vary header and the Expires header are also included. Therefore the response which is cached along the Ohto & Hjelm Expires October 30, 2000 [Page 23] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 request/response chain might be used without revalidation with the origin server. The Profile-Diff header field does not have to be included in the Vary header field because the change of the Profile-Diff header is represented by profile-diff-name "1-uKhJE/AEeeMzFSejsYshHg==" in the Profile header field. The requests and responses according to the scenario is described below. [1. UserAgent --> OriginServer] M-GET /a-resource HTTP/1.1 Host: www.w3.org Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=70 70-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" 70-Profile-Diff-1: [2. OriginServer --> CCPPRepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [3. OriginServer --> UserAgent] HTTP/1.1 200 OK Ext: Cache-control: max-age=1200, no-cache="Ext" Vary: Man, 70-Profile Expires: Tue, 05 Mar 1999 16:00:00 GMT Content-Type: text/html Content-Length: 1200 .... 6.7 Enable the HTTP cache expiration model(hop-by-hop) The scenario is listed below. 1. The user agent issues a request. 2. The first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions. Ohto & Hjelm Expires October 30, 2000 [Page 24] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 3. The first-hop proxy generates and issues a request to the origin server. 4. The origin server responds to the first-hop proxy with the content. 5. The first-hop proxy transforms and sends back a tailored content with the Cache-control header, the Vary header and the Expires header. Therefore the response might be used by the user agent without revalidation. The requests and responses according to the scenario is described below. [1. UserAgent --> Proxy] M-GET /a-resource HTTP/1.1 Host: www.w3.org C-Man: "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=67 67-Profile: "http://www.aaa.com/hw", "http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" 67-Profile-Diff-1: Connection: C-Man, 67-Profile [2. Proxy --> CCPPrepositories] GET http://www.aaa.com/hw HTTP/1.1 Host: www.aaa.com .... GET http://www.bbb.com/sw HTTP/1.1 Host: www.bbb.com .... [3. Proxy --> OriginServer] GET /a-resource HTTP/1.1 Host: www.w3.org Accept: text/xml, text/html, */* Accept-Charset: UTF-16, iso-2022-JP Accept-Encoding: compress, gzip Accept-Language: ja, en [4. OriginServer --> Proxy] HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-16 Content-Encoding: compress Content-Language: ja Ohto & Hjelm Expires October 30, 2000 [Page 25] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 Content-Length: 1200 Vary: Content-Type, Content-Encoding, Content-Language, Content-Length Expires: Tue, 05 Mar 1999 16:00:00 GMT .... [5. Proxy --> UserAgent] HTTP/1.1 200 OK C-Ext: Cache-control: max-age=1200, no-cache="C-Ext" Content-Type: text/xml; charset=UTF-16 Content-Encoding: compress Content-Language: ja Content-Length: 900 Vary: C-Man, 67-Profile Expires: Tue, 05 Mar 1999 16:00:00 GMT .... Ohto & Hjelm Expires October 30, 2000 [Page 26] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 7. Security considerations The Profile and Profile-diff headers can reveal information about the hardware, software and user preferences to all servers which are accessed. Especially when headers in which the user preferences is included, implementers are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved. This specification allows gateways/proxies which are in between a user agent and an origin server to add multiple CC/PP descriptions. This opens to attacks by malicious/inadvertent gateways/proxies. In addition, the security considerations of this specifcation are the same as those of the HTTP Extension Framework. Ohto & Hjelm Expires October 30, 2000 [Page 27] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 References [1] Frystyk, H., Leach, J. and S. Lawrence, "An HTTP Extension Framework", RFC 2774, February 2000. [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, J. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [3] Reynolds, F., Hjelm, J., Dawkins, S. and S. Singhal, "Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation", W3C Note, July 1999. [4] Lassila, O. and R. Swick, "Resource Description Framework, (RDF) Model and Syntax Specification", W3C Recommendation, February 1999. [5] Brickley, D. and R.V. Guha, "Resource Description Framework (RDF) Schema Specification 1.0", W3C Candidate Recommendation, March 2000. [6] Cranor, L., Langheinrich, M., Marchiori, M., Presler-Marshall, M. and J. Reagle, "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Working Draft, April 2000. [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [9] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. [12] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. [13] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol(RTSP)", RFC 2396, April 1998. [14] Martin, B. and B. Jano, "WAP Binary XML Content Format", W3C Ohto & Hjelm Expires October 30, 2000 [Page 28] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 Note, June 1999. [15] Bray, T., Clark, J., Tauber, J. and J. Cowan, "Canonical XML Version1.0", W3C Working Draft, January 2000. Authors' Addresses Hidetaka Ohto World Wide Web Consortium/Panasonic. 545 Technology Square Cambridge, MA 02139 US Phone: +1 617 258 0982 EMail: ohto@w3.org URI: http://www.w3.org/ Johan Hjelm World Wide Web Consortium/Ericsson. 545 Technology Square Cambridge, MA 02139 US Phone: +1 617 253 9630 EMail: johan@w3.org URI: http://www.w3.org/ Ohto & Hjelm Expires October 30, 2000 [Page 29] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 Appendix A. Acknowledgements The authors wish to acknowledge the contributions from WAP Forum/UAPROF WG members, especially we would like to thank Sandeep Shinghal, Lalitha Suryanarayana and Mikael Nilsson. The authors also wish to acknowledge the contributions from Franklin Reynolds, Henrik Frystyk Nielsen and staff members of the W3C. Ohto & Hjelm Expires October 30, 2000 [Page 30] Internet-Draft draft-ietf-ohto-ccpp-exchange-00 May 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Ohto & Hjelm Expires October 30, 2000 [Page 31]