Internet DRAFT - draft-hjelm-http-cnhttp-scenarios
draft-hjelm-http-cnhttp-scenarios
IETF HTTP WG Johan Hjelm, Ericsson
Internet draft 31 October 2000
Expires: April 2001
Content Negotiation Header in HTTP Scenarios
<draft-hjelm-http-cnhttp-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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:
<www-ccpp-protocol@w3.org>
To subscribe to this list, send a message to
"<www-ccpp-protocol@w3.org>" 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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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 = <any US-ASCII digit "0".."9">
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
[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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
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: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
[2. OriginServer --> UserAgent (case of failure)]
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1200
....
<!-- non-tailored content -->
[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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
[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: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
80-Profile-Diff-1: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF> [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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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: <?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
<Description ID="SoftwarePlatform" PRF:Sound="On" />
</RDF>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
[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:
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-
19991014#">
<Description about="http://www.example.com/MyProfile">
<ccpp:component>
<Description about="http://www.example.com/TerminalHardware">
<type resource="http://www.example.com/Schema#
HardwarePlatform" />
<ccpp:Defaults>
<Description>
Hjelm Internet draft [Page 19]
CNHHTTP Scenarios 31 October 2000
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
<type resource="http://www.example.com/Schema#
HardwarePlatform" />
<uaprof:CPU>PPC</uaprof:CPU>
<uaprof:ScreenSize>320x200</uaprof:ScreenSize>
</Description>
</ccpp:Defaults>
<uaprof:ScreenSize>640x400</uaprof:ScreenSize>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/TerminalSoftware">
<type resource="http://www.example.com/Schema#
SoftwarePlatform" />
<ccpp:Defaults>
<Description>
<type resource="http://www.example.com/Schema#
SoftwarePlatform" />
<uaprof:OSName>EPOC</uaprof:OSName>
<uaprof:OSVersion>2.0</uaprof:OSVersion>
<uaprof:OSVendor>Symbian</uaprof:OSVendor>
</Description>
</ccpp:Defaults>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/Browser">
<type resource="http://www.example.com/Schema#
BrowserUA" />
<ccpp:Defaults>
<Description>
<type resource="http://www.example.com/Schema#
BrowserUA" />
<uaprof:BrowserName>Mozilla</uaprof:BrowserName>
<uaprof:BrowserVersion>5.0</uaprof:BrowserVersion>
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp:Defaults>
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
<li>text/html</li>
</Bag>
Hjelm Internet draft [Page 20]
CNHHTTP Scenarios 31 October 2000
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
</uaprof:CcppAccept>
</Description>
</ccpp:component>
</Description>
</RDF>
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
<draft-ietf-rescap-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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
<Draft-Hjelm-HTTP-CNHTTP-scenarios-00.txt>
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.
