IETF HTTP WG Johan Hjelm, Ericsson Internet draft 31 October 2000 Expires: April 2001 Content Negotiation Header in HTTP Scenarios Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This memo explores some scenarios for the use of a feature description header in HTTP, to be used for content negotiation. It is intended to provide some grounding in specific use-cases for decisions about goals and design. Hjelm Internet draft [Page 2] CNHHTTP Scenarios 31 October 2000 Table of contents Status of this memo 1. Introduction.......2 1.1 Structure of this document...........................................3 1.2 Document terminology and conventions........................................3 1.3 Discussion of this document...........................................3 2. General issues.............................................4 3. Scenarios.......................................5 3.1 Content adaption using resource and client description........................................3 3.2. Proposed header format........................6 3.3. Resource description format selection.........7 3.4 Profile-warning header.............................................7 3.6 Examples.......................................9 3.6.1 Mandatory and end-to-end.........................................9 3.6.2 Optional and end-to-end........................................10 3.6.3 Mandatory and hop-by-hop ..................................................11 3.6.4 Optional and hop-by-hop........................................13 3.6.5. Response with Warning...........................................15 3.6.6. Enable the HTTP cache expiration model(end-to-end).................................16 3.6.7. Enable the HTTP cache expiration model(hop-by-hop).................................17 4. Resource capability data formats...........................................18 4.1 CC/PP.........................................18 4.2 CONNEG............................................20 4.3 RESCAP........................................20 4.4 SDP (RFC 2327).............................................21 5. Security considerations....................................21 5.1 Unauthorized access or disclosure........................................21 6. Acknowledgements..................................22 7. References.....................................22 8. Author's address...........................................22 Appendix A: Amendment history ..................................................23 1. Introduction This memo explores scenarios where a header in HTTP can be used to provide capability information about the terminal requesting information, and the users preferences for the use of these capabilities (e.g. sound on/off). These capabilities preferences can be described in a variety of formats, e.g. CC/PP, CONNEG, SDP, or other now existing or non-existing formats. This document is intended to provide some grounding in specific use-cases for decisions about CNHHTTP goals and design. Hjelm Internet draft [Page 3] CNHHTTP Scenarios 31 October 2000 1.1 Structure of this document Section 2 makes some general comments about expected usage and deployment. It also compares the proposed header to the existing HTTP headers. Section 3 describes a number of usage scenarios that motivate the design. Section 4 describes a number of possible resource description formats that could be transported in the proposed header. Section 5 disucsses security issues. 1.2 Document terminology and conventions CNHHTTP refers to RFC 2616 as well as the additional header that is being designed by the proposed CNHHTTP working group. This is provisionally referred to as the "accept-profile" header. NOTE: Comments like this provide additional nonessential information about the rationale for parts of this document. [[[Editorial comments and questions about outstanding issues are provided in triple brackets like this. These working comments should be resolved and removed prior to final publication.]]] 1.3 Discussion of this document Discussion of this document should take place on the Content Negotiation Header in HTTP list. Please send comments regarding this document to: To subscribe to this list, send a message to "" containing the command "subscribe www-ccpp-protocol" (without quotation marks) in the message body. NOTE: The name has historical reasons. To see what has gone on before you subscribed, please see the mailing list archive at: http://lists.w3.org/public/www-ccpp-protocol/ Hjelm Internet draft [Page 4] CNHHTTP Scenarios 31 October 2000 2. General issues Presentation of the current web is frequently designed for users with Large screens and high-end computers. With device types proliferating, there is an emerging need for content to be formatted for rendering on different devices and different modalities such as text, sound or a combination. Hardware and layout characteristics (for example, the display or input capabilities), as well as the software environments are as heterogeneous as the devices and device types themselves. In addition, presentation preferences varies between individual users. For content on the current World Wide Web to then be usable, the application server needs to be aware of the context or situation in which the information is being presented. In HTTP, there is no header to describe the feature set of a terminal when making a request (even though some, e.g. the User-Agent header, describes certain features). The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. Several headers can be used to provide information about some aspects of the terminal, but none is intended to provide a full description. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method invocation. RFC 2616 lists the following relevant headers: Accept Accept-Charset Accept-Encoding Accept-Language Pragma User-Agent It is also true that the headers available are not limited to these, since it already says in RFC 2616 that "an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header fields or within extension header fields not defined by this specification." There are, however, inherent limitations to these in the context discussed here. The Accept request-header field can be used to specify certain media types which are acceptable for the response. There is no way of specifying anything else but media types, however. This means that there is no way of handling variations within media types using the Accept field. Nor does the User-agent header field solve the particular problem at hand. Its semantics are, after all, limited to product name and comment. Hjelm Internet draft [Page 5] CNHHTTP Scenarios 31 October 2000 The method discussed is a special case of server-driven content negotiation, as discussed in RFC 2616. Several disadvantages of the method are presented. For instance, the RFC states that "it is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?)." While it is true that an absolutely optimal representation would require more information than can be made available, it is still quite possible to achieve an optimized presentation for the current transaction, given an incomplete information set, provided the salient parameters are present. The RFC also states that "Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential violation of the user's privacy." The privacy aspect is discussed in section 5. The question of the inefficiency has turned out to be different from what was expected when the RFC was written. Given that the majority of requests are directed at a small number of sites, and they already use database-driven content generation techniques, often with cookies and other, non-standard, methods to describe the user and the device, it is unlikely that this would introduce any additional load on the system. Given that file sizes of responses have tended to increase in the last few years, it is also unlikely that even the most comprehensive description would affect the assymmetry of the web. What we propose is to introduce a new header, that would be capable of containing a full description of the terminal and the users preferences for its use, as requested. It is provisionally referred to as the "accept-profile" header. A profile in this context is simply a collection of properties that describe the capabilities of the client and its environment. 3. Scenarios This section summarizes some intended uses for the CNHHTTP header, provisionally called "accept-profile". It should be noted that the use of the proposed header is very similar to those of the User Agent header. Indeed, the way that is used in actuality is often reminescent of the methods described here. 3.1 Content adaption using resource and client description In the case of HTTP, a user agent generates, encodes and appends a profile onto an outgoing HTTP request at the requesting end. Intermediate proxies along the path of the request can append additional descriptions of their capabilities or services. Hjelm Internet draft [Page 6] CNHHTTP Scenarios 31 October 2000 At the origin server, the profile can be dynamically composed from fragments of capability assertions collected from various sources (e.g CC/PP repositories) indicated by a default URI, then parsed and interpreted to determine the features of the presentation environment. The content can be generated either by using filtering techniques specific to a device or user's preferences, the method being out of scope of this discussion, or by selecting an appropriate presentation format with the content intact (e.g. variants of a style sheet). Depending upon the application, a suitable variant of the content itself may also be selected (from a set) or dynamically generated (from a database). The adapted content is returned in the HTTP response, possibly further transformed by the intermediate network elements and finally rendered to the client. 3.2. Proposed header format While this document is no specifications, it is worth making a few notes based on [OHTO] and experiences from the deployment of CCPP-Ex. The strategy in CCPP-ex is to send a request with as little as possible profile information, using references (URIs) to enable the dynamical composition of a profile. Overrides can then be sent to these references. This is strictly speaking not a matter for the protocol (but the data format, the resolution of inline references not being a problem for the protocol but in the case of CC/PP the RDF processor), except for one thing: Caching of profiles, which can be done using the cache management mechanisms in HTTP. As an example of overrides, 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 fully enumerated 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. The Profile header field in the CC/PP Exchange Protocol is a request-header field, which conveys a list of references which address CC/PP descriptions. Hjelm Internet draft [Page 7] CNHHTTP Scenarios 31 October 2000 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 = sp; < MD5 message digest encoded by base64 > DIGIT = The "accept-profile" header can use a similar, but simplified, format. 3.3. Resource description format selection Given that a large number of devices exist, and that some formats may be more suitable to the description of a user device, agent, or environment than others in certain contexts, it is not desirable to restrict the number of device description formats. Rather, the number of possible formats should be kept as open as possible. One way of achieving this is to use the "accept-profile" header as an encapsulation of a format defined elsewhere. This will mean that the receiving server will need a method to return an error message, if it can not parse the format of the content. One solution is to include a field that designates the format of the description. If this is not parseable, the server would return an error message. (HTTP status code 415 Unsupported Media Type). This implies that the server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. This implies that the header should contain a field where the content type of the format is given (as registred by IANA). See further section 4 for a listing of some possible device description formats. If the content type is not registred, it will either result in an error message, or the semantics will have to be built into the server (i.e. this would be the case when using a non-standardized format). 3.4 Profile-warning header In case the header can be parsed, but appropriate action can not be taken on the content, a field similar to the Profile-warning field in the CCPP-ex protocol is useful. 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 "accept-profile" header field to a server, the server inquires of CC/PP repositories the CC/PP descriptions using the absolute URIs in the "accept-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. Hjelm Internet draft [Page 8] CNHHTTP Scenarios 31 October 2000 In CCPP-ex, the server responds to the client with the Profile-warning header field if any one of the CC/PP descriptions could not be obtained, or any one of the CC/PP descriptions is stale. This mechanism can be used outside the CCPP-ex protocol as well, for instance when a profile is claimed to be in one format, but can not be parsed; or when a header has been cached (see section 3.5 Cacheability) but can not be retrieved, a case that would be equivalent to the case of a repository not being resolvable above. 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 absolute URI and the host are given in RFC2396 [RFC2396], and the definitions of the quoted-string and the HTTP-date are given in RFC 2616. The warn-code assignes three digits. The "1xx" indicates the status of the profile (e.g. if 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 absolute URI or the host corresponding to the type of the warn-code. The warn-target indicates the absolute URI when the warn-code is of the form "1xx". The warn-target indicates the host when the warn-code is of the form "2xx". This is a list of the currently defined warn-codes in CCPP-ex, each with a recommended warn-text in English, and a description of its meaning. 100 OK MAY be included if the cache or repository replies with first-hand or fresh information. The warn-target indicates the absolute URI which addresses the descriptions in the repository, or the URI for the cached profile. 101 Used stale profile MUST be included if the CC/PP repository replies with stale information. Whether the description is stale or not is decided by analyzing the HTTP header information with which the repository or cache 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 absolute URI which addresses the description in the repository or cache. 102 Not used profile MUST be included if the description could not be obtained(e.g. the repository or cache is not available.). The warn-target indicates the absolute URI which addresses the description in the repository or cache. Hjelm Internet draft [Page 9] CNHHTTP Scenarios 31 October 2000 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. 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. 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. 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. 3.6 Examples The following examples show some scenarios using the CC/PP exchange protocol. 3.6.1 Mandatory and end-to-end The scenario is listed below. 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. 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. 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. The origin server generates the tailored content according to the enumerated CC/PP Hjelm Internet draft [Page 10] CNHHTTP Scenarios 31 October 2000 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. 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 .... 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 Hjelm Internet draft [Page 11] CNHHTTP Scenarios 31 October 2000 3.6.2 Optional and end-to-end The scenario is listed below. The user agent issues an optional extension request(GET) with the Profile header and the Profile-Diff header. 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. 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. 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 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 .... Hjelm Internet draft [Page 12] CNHHTTP Scenarios 31 October 2000 [4. OriginServer --> UserAgent] HTTP/1.1 200 OK Cache-control: no-cache Content-Type: text/html Content-Length: 1200 .... 3.6.3 Mandatory and hop-by-hop The scenario is listed below. 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. 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. Otherwise, the first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs. 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. The origin server responds to the first-hop proxy with the content. 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 .... Hjelm Internet draft [Page 13] CNHHTTP Scenarios 31 October 2000 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] 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 .... 3.6.4 Optional and hop-by-hop The scenario is listed below. The user agent issues an optional extension request(GET) with the Profile header and the Profile-Diff header. 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. Otherwise, the first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions using the absoluteURIs. The first-hop proxy generates the request and issues the request to the origin server. The origin server responds to the first-hop proxy with the content. 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 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==" Hjelm Internet draft [Page 14] CNHHTTP Scenarios 31 October 2000 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] 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 .... Hjelm Internet draft [Page 15] CNHHTTP Scenarios 31 October 2000 3.6.5. Response with Warning The scenario is listed below. The user agent issues a request. The origin server issues requests to the CC/PP repositories to get the CC/PP descriptions. 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". 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.) 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 .... Hjelm Internet draft [Page 16] CNHHTTP Scenarios 31 October 2000 3.6.6. Enable the HTTP cache expiration model(end-to-end) The scenario is listed below. The user agent issues a request. The origin server issues requests to the CC/PP repositories to get the CC/PP descriptions. 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 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 .... Hjelm Internet draft [Page 17] CNHHTTP Scenarios 31 October 2000 3.6.7. Enable the HTTP cache expiration model(hop-by-hop) The scenario is listed below. The user agent issues a request. The first-hop proxy issues requests to the CC/PP repositories to get the CC/PP descriptions. The first-hop proxy generates and issues a request to the origin server. The origin server responds to the first-hop proxy with the content. 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 Content-Length: 1200 Vary: Content-Type, Content-Encoding, Content-Language, Content-Length Expires: Tue, 05 Mar 1999 16:00:00 GMT .... Hjelm Internet draft [Page 18] CNHHTTP Scenarios 31 October 2000 [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 4. Resource capability data formats There are a variety of capability formats that are used to describe the data which is intended to be transported in the proposed header. It is also likely that other formats will occur in the future. The following list constitutes examples, and is in no way intended to be complete. Note that most of these are not registred as MIME content types. (http://www.isi.edu/in-notes/iana/assignments/media-types/media-types) 4.1 CC/PP The CC/PP format is a format for device and user environment description using RDF, the W3C Resource Description Framework. The CC/PP architecture model defines a machine understandable RDF schema upon which vocabularies can be independently developed and implemented. This enables it to be used for adaption of content based on comparison matching with policy descriptions in servers and proxies. It also incorporates a method for adding information about proxies to the client information. CC/PP is defined in RDF, which is encoded in XML. However, to facilitate the management of the information, an application type has been registred with IANA [[Will be]]. CC/PP has mechanisms to append proxy profiles to client profiles. It also has a mechanism to refer to default values inline using a URI. This makes it possible to send a very compact profile, but it has to be resolved in the server. Below is an example CC/PP description: Hjelm Internet draft [Page 19] CNHHTTP Scenarios 31 October 2000 PPC 320x200 640x400 EPOC 2.0 Symbian Mozilla 5.0
  • text/plain
  • text/vnd.wap.wml
    •
  • text/plain
  • text/vnd.wap.wml
  • text/html
    •  Hjelm Internet draft [Page 20] CNHHTTP Scenarios 31 October 2000     4.2 CONNEG CONNEG is a format using feature-tags from a registry maintained by IANA. The feature set syntax is built upon the principle of using feature set predicates as "mathematical relations" which define constraints on feature handling capabilities. This allows that the same form of feature set expression can be used to describe sender, receiver and file format capabilities. This has been loosely modelled on the way that relational databases use Boolean expresions to describe a set of result values, and a syntax that is based upon LDAP search filters. A framework for such negotiation is described in [CONNEG-FW]. A part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. Descriptions of media feature capabilities need to be based upon some underlying vocabulary of individual media features. A format for such a vocabulary and procedures for registering media features within this vocabulary are presented in [CONNEG]. 4.3 RESCAP RESCAP consists of two protocol parts: * a general resolution protocol that will translate resource identifiers to a list of attributes. * an administrative model and update protocol that can be used to set up and maintain the information the resolution protocol accesses. Web and other data resources may have associated metadata (URCs?). A combination of DNS and RESCAP protocols might be used to access this resource metadata. HTTP might be used instead of RESCAP, but the RESCAP goals suggest two possible advantages over HTTP: lightweight access for small items of information that are accessed frequently, and the RESCAP administrative model suggests a possibility for easier administration of metadata for metadata about a family of related resources. However, the RESCAP group has not specified any way of transporting information over HTTP. The suggested CNHTTP "accept-profile" header can be used for this. Type of metadata: Resource URLs o Media feature expressions (from the drafts, it is unclear what - but this could concievably be CC/PP or Conneg expressions) List of other types "to be added" Hjelm Internet draft [Page 21] CNHHTTP Scenarios 31 October 2000 4.4 SDP (RFC 2327) SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. Session directories assist the advertisement of conference sessions and communicate the relevant conference setup information to prospective participants. SDP is designed to convey such information to recipients. Session descriptions can be conveyed using methods which include electronic mail and the World Wide Web. For both email and WWW distribution, the use of the MIME content type "application/sdp" should be used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner. Interesting to note is that RFC 2327 does not define how the data should be conveyed over HTTP. It is, however, conceptually no different from any other capability exchange information (since the session setup actually takes place using another protocol). That implies that SDP could be transported as part of the CNHTTP "accept-profile" header as well. This is an example SDP session description of an ITU H.332 session: c=IN IP4 224.5.6.7 a=type:H332 m=audio 49230 RTP/AVP 0 m=video 49232 RTP/AVP 31 m=application 12349 udp wb m=control 49234 H323 mc c=IN IP4 134.134.157.81 5. Security considerations Since the architecture discussed above essentially consists of an additional header in HTTP, the security threats and problems are foreseen to be the same as for HTTP in general. [[[The rest of this section has yet to be fleshed out]]] 5.1 Unauthorized access or disclosure Privacy aspects, i.e. the user information being accessed by an unauthorized party, is a possible security threat. This becomes more pertinent in the case of "accept-profile" than with other headers, since the aggregated information gives more detail about the user agent (depending on capability information encoding), and can be used to draw conclusions about the user. RFC 2616 section 15.1.4 outlines the problem. Hjelm Internet draft [Page 22] CNHHTTP Scenarios 31 October 2000 In the time since its writing, there have been various attempts at solving this. The most promising to date is P3P [P3P] which enables the selection of information elements to be sent to the server. However, the last word is not said on this topic, and until a fully secure solution has been fleshed out, users should be presented with the option of switching off the use of the "accept-profile" header. Another possible security threat is response spoofing. In the traditional use of HTTP, this would not be a large problem, since it would just mean that a request or a response document got redirected. However, if the information contained in the request or response is sensitive, e.g. contains personal information or configuration information, this will lead to problems of the kind implied in section 5.1. However, the solution of these problems is beyond the scope of HTTP (being the use of secure transports, for instance). A special case would be when the profile contains attached information about intermediaries, such as proxies (as is a possible case in CC/PP). This could lead to the involontary disclosure of firewall configuration information to a third party. No solution for this is known, and the solution is most likely out of the scope of HTTP. Secure transport is one option, the encryption of the header information another. Keeping parts of profiles private is another option, actually addressed by P3P, but the solution is beyond the scope of the "accept-profile" header, since this would determine the content of the profile, and not affect the transport as such. The CC/PP Trust Model document (forthcoming) discusses some of these possible threats, and their solutions. 6. Acknowledgements The author wishes to acknowledge the assistance of the CC/PP working group, the WAP Forum UAPROF drafting comittee and the CNHTTP ad-hoc group, specifically Hidetaka Ohto of Panasonic, who unknowingly has contributed enormously. 7. References [[[Full citations to be supplied]]] 8. Author's address Johan Hjelm Nippon Ericsson KK Ichiban-kan 5F, YRP center, 3-4 Hikarino-oka, Yukosuka 239-0847 Kanagawa Japan Telephone: +81-468-47-5383 Facsimile: +81-468 47-5370 E-mail: johan.hjelm@nrj.ericsson.se Hjelm Internet draft [Page 23] CNHHTTP Scenarios 31 October 2000 Appendix A: Amendment history 00a 31-Oct-2000 Memo initially created. 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.