|
Owner |
Richard Jacob |
|
Release |
2.0 |
|
Status |
proposed |
|
Version History |
|||
|
Date |
Author |
Version |
Description |
|
|
Richard Jacob |
Draft-1 |
Initial draft |
The CC/PP framework is a mechanism for agents accessing the World Wide Web. Information about user agents includes the hardware platform, system software, applications and user preferences. The user agent capabilities and preferences can be thought of as metadata, or properties and descriptions of the user agent's hardware and software. The CC/PP descriptions are intended to provide information necessary to adapt the content and the content delivery mechanisms to best fit the capabilities and preferences of the user and its agents.
Furthermore the W3C defines the CC/PP exchange protocol based on the HTTP Extension Framework [HTTPext] which allows to transport the CC/PP profile information (or more exact: references to profiles) over plain HTTP.
Other standardization bodies like OMA also refer to CC/PP and define transport mechanisms similar to the CC/PP exchange protocol like the UAProf specification (defines W-HTTP).
Currently WSRP only specifies the UserAgent String as the only means to identify the end-user’s agent. Obviously this is not a satisfactory and comprehensive vehicle to transport device information and end-user preferences.
CC/PP seems to be well accepted standard communicate this information.
A handheld device accesses the Consumer portal via HTTP or WAP and provides its device capabilities and user preferences using CC/PP. This information needs to flow to remote portlets in order to being able to generate markup adhering to that profile information.
This feature proposal describes an optional means to transport the CC/PP information via WSRP in a similar way defined in the CC/PP exchange protocol.
It does not deal with details about how the profile information is interpreted by the Producer/portlets nor how CC/PP profiles are defined. The focus is clearly on the transport mechanism using the WSRP protocol.
CC/PP exchange protocol defines the following headers:
The Profile header field is a
request-header field, which conveys a list of references which address CC/PP
descriptions.
The grammar for the Profile header
field is as follows:
Profile = profile-field-name ":" 1#reference
profile-field-name = "Profile"
reference = <"> ( absoluteURI | profile-diff-name ) <">
profile-diff-name = profile-diff-number "-" profile-diff-digest
profile-diff-number = 1#DIGIT
profile-diff-digest = sp; < MD5 message digest encoded by base64 >
DIGIT = <any US-ASCII digit "0".."9">
The Profile header field-value is a
list of references. Each reference in the Profile header field represents the
corresponding entity of the CC/PP description. A reference is either an
absoluteURI or a profile-diff-name. An entity of a CC/PP description which is
represented by an absoluteURI exists outside of the request, and an entity of a
CC/PP description which is represented by a profile-diff-name exisits inside of
the request(i.e. in the Profile-Diff header field. See
Section 5.2.2 Profile-Diff
header).
The absoluteURI in the Profile
header field addresses an entity of a CC/PP description which exists in the
World Wide Web. CC/PP descriptions may originate from multiple sources(e.g. hardware vendors, software vendors, etc). A
CC/PP description which is provided by a hardware vendor or a software vendor
SHOULD be addressed by an absoluteURI. A user agent issues a request with
these absoluteURIs in the Profile header instead of sending whole CC/PP
descriptions, which contributes to reducing the amount of transaction. The
syntax of the absoluteURI MUST conform to RFC2396[RFC2396]. An
absoluteURI can unambiguously be distinguished from a profile-diff-name by the
presence of a colon(":") in the Profile
header field-value.
The profile-diff-name in the
Profile header field addresses a CC/PP description in the corresponding
Profile-Diff header within the same request. When the Profile header field
includes a profile-diff-name, the corresponding Profile-Diff header MUST be
included within the same request.
The Profile-Diff header field is a
request-header field, which contains CC/PP description. The Profile-Diff header
field is always used with Profile header in the same request.
All profile information could be
represented by absoluteURIs in the Profile header. In this case, the
Profile-Diff header field does not have to be added to the request. On the
other hand, only one Profile-Diff header can contain all profile information.
In this case, the Profile header includes only the profile-diff-name which
indicates the Profile-Diff header.
The grammar for the Profile-Diff
header field is as follows:
Profile-Diff = profile-diff-field-name ":" profile-desc
profile-diff-field-name = "Profile-Diff-" profile-diff-number
profile-desc = < the CC/PP description based on XML/RDF text format
(any OCTET except CTLs,but including LWS)>
The Profile-Diff header field-name(profile-diff-field-name) consists of the
prefix("Profile-Diff-") and the following profile-diff-number.
The profile-diff-number is the
number which indicates the corresponding profile-diff-name in the Profile
header. Multiple Profile-Diff headers are allowed to appear in the same
request. Therefore the profile-diff-number is introduced for the purpose of
indicating the corresponding profile-diff-name in the Profile header. The
profile-diff-number is generated and corresponds to the prefix of the
profile-diff-name in the Profile header field within the same request. The
profile-diff-number SHOULD be increased by 1 when a Profile-Diff header is
added by a user agent, a gateway, or a proxy.
The Profile-warning header field is
a response-header field, which is used to carry warning information.
When a client issues a request with
the Profile header field to a server, the server inquires of CC/PP repositories
the CC/PP descriptions using the absoluteURIs in the Profile header field.
If any one of the CC/PP repositories is not available, the server might
not obtain the fully enumerated CC/PP descriptions, or the server might
not obtain first-hand or fresh CC/PP descriptions.
The server SHOULD respond to the
client with the Profile-warning header field if any one of the CC/PP
descriptions could not be obtained, or any one of the CC/PP descriptions is
stale.
The grammar for the Profile-warning
header field is as follows:
Profile-warning = profile-warning-field-name ":" 1#warning-value
profile-warning-field-name = "Profile-Warning"
warning-value = warn-code SP warn-target SP warn-text [SP warn-date]
warn-code = 3DIGIT
warn-target = (absoluteURI | host [ ":" port ])
warn-text = quoted-string
warn-date = <"> HTTP-date <">
The definitions of the absoluteURI
and the host are given from RFC2396[RFC2396], and
the definitions of the quoted-string and the HTTP-date are given from HTTP/1.1[HTTP/1.1].
The warn-code
assignes three digits. The "1xx" indicates the status of the
CC/PP description(e.g. it is fresh or stale). The
"2xx" indicates the type of the content adaptation applied to the message(e.g. content selection, content transformation, or
content generation).
The warn-target indicates either
the absoluteURI or the host corresponding to the type of the warn-code. The
warn-target indicates the absoluteURI when the warn-code forms "1xx".
The warn-target indicates the host when the warn-code forms "2xx".
For the request, the ClientData structure is extended to hold the CCPP headers:
The CCPPHeaders Type holds the CC/PP exchange defined header equivalents:
The ProfileDiff Type holds the profile-díff header equivalent.
The MarkupContext is extended to contain the Profile-Warning response
MarkupContext
[O] boolean useCachedMarkup
[O] string mimeType
[O] string markupString
[O] base64Binary markupBinary
[O] string locale
[O] boolean requiresUrlRewriting
[O] CacheControl cacheControl
[O] string preferredTitle
[O] string CCPPProfileWarning
[O] Extension extensions[]
1. Is ClientData only intended for markup generation only? Or should it also apply to performBlockingInteraction (use cases seem to exist)? In that case shouldn’t we move the ClientData structure to the RuntimeContext? Note: MarkupParams are available in pbia, too so principally ClientData is accessible in that phase.
2. If
1. applies also to pbia, should pbia be able to return
the CCPPProfileWarning, too? And if yes, what would the Consumer do with it?
Currently it seems only to be valueable to return with markup.
This section describes a set of
discernable milestones for this design. It is followed by a table that
sets a schedule for these milestones.
|
Milestone |
Proposed Date |
Delivered |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|