X-wap-profile

0 views

Skip to first unread message

Abbie Buesing

unread,

Aug 3, 2024, 4:51:43 PM8/3/24

to quimcineraf

UAProf(User agent profile) is an XML document that contains informationabout the features and capabilities of a mobile device. Very oftenthe URL that points to the UAProf document of a mobile device caneither be found in the x-wap-profileheader or the Profileheader, but in some cases it is located in other HTTP headers.Some example x-wap-profileheaders and Profileheaders are provided below:

What do you think about this web page?
It is very helpful.
It is helpful, but some information I wanted is missing.
It is not helpful.
It has broken links.
It has typos / grammatical mistakes.
It has incorrect information.
Others

(Optional) Please provide us more details. For example, suppose you select option 2 above, can you tell us specifically what information is missing? You can also suggest anything that can help us improve this web page.

This document is a very preliminary public Working Draft madeavailable by the World Wide Web Consortium (W3C) for discussiononly. It is intended to become a W3C Note. This indicates noendorsement of its content. This is work in progress, may be updated,replaced, or obsoleted by other documents at any time. A list of current W3C working drafts can be found at

This document is produced by the CC/PP working group (member only) (part of the Device Independence activity). The working group welcomes feedback and discussion,preferably on the public mailing list www-m...@w3.org, althoughcomments may also be sent to the authors.Public comments and their responses can be accessed at -mobile/.

CC/PP data is not in itself personal, i.e. tied to a named user, but since there are a number of ways for the user to be identified as the holder of the profile, e.g. by identity transmision in HTTP parameters, or through recognition of the IP-number or such, there is a need for a suggested privacy method for implementors.

Descriptions of single features in a description of a terminal or the users preferences for how that terminal should be used cannot in themselves be used to infringe on a users privacy. However, when a profile contains a collection of such properties, it can be used to personalize information; the closer the personalization, the bigger risk that the user can be identified from his specific use of the terminal; and the bigger the risk of misuse from a privacy standpoint. There is also a possible risk that a user can be identified as having certain abilities (e.g. if he constantly requests text in double-sized fonts, it is likely that he is hard of seeing), and this may be possible to misuse.

Generally speaking, a user may not want to share some or all of the data in a CC/PP profile, and may wish to have control over who receives that information and when. Origin servers customizing the content should therefore express to the user or user agent regarding their privacy practices with regard to the use of CC/PP data, so that, the user can make a decision on whether or not to share that data with the server.

P3P is a way for an origin server to express the privacy policy it adheres to for the user and/or his terminal. While the match between P3P and CC/PP is not perfect, and while the intent and implementation of the two are different, they can be used together to enhance the privacy protection of the user.

CC/PP is an abbreviation of "Composite Capability/Preference Profiles", and is an extensible format based on RDF [RDF][RDF-Schema] for describing device capabilities and user preferences. In general, user preferences and device capabilities need to be protected from malicious use but there is no trust management framework for CC/PP so far. Without trust management, sensitive information opens to attacks by malicious servers or content providers.

We do not aim to create new technologies in terms of network security, authentication, message validation, personal privacy protection, and cryptography. We intend to employ the existing technologies in terms of trust management while considering how to apply such technologies well fit into the use cases of CC/PP.

This document is a discussion document, containing implementation advice for developers of services based on CC/PP. It demonstrates the interactions between CC/PP and P3P given the current state of implementations. However, since CC/PP only specifies a data structure and not a protocol, this work should be taken as future input to a formal specification, and currently be seen as advice to implementors only.

There is, currently, no CC/PP protocol. There are a number of proposals, but for various reasons, the group is not chartered to develop a protocol. It will do so as soon as possible, but it does require a rechartering. Meanwhile, there are two proposals: The CC/PP Exchange Protocol, and the W-HTTP protocol.

Note that it would be possible to use the "profile" header Mark Baker suggests in draft-baker-xhtml-media-reg-01.txt and draft-baker-xhtml-media-reg-02.txt to reference a CC/PP profile (the mechanism has been demonstrated by Kiniko Yasuda of Keio University).

The CC/PP Exchange Protocol (CCPP-ex) was presented as a W3C Note on June 24, 1999. It uses the HTTP Extension Framework [RFC2396]. The intent was to provide a framework that was both possible to map into HTTP headers, and that can handle defaults as URIs. The idea was to minimize data transfer over the air, a goal that was accomplished, as has been demonstrated by Kiniko Yasuda of Keio University.

CCPP-ex uses two headers, one for the defaults and one for the updates (profile-diff:s), which are separated using MD5 hashes. A third header carries warning information. The protocol is documented in the W3C Note "CC/PP exchange protocol based on HTTP Extension Framework".

The CC/PP framework is a mechanism for describing the capabilities and preferences associated with users and user agents accessing the World Wide Web. Information about user agents includes the hardware platform, system software, applications and user preferences. 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.

There are several optimizations possible to help deal with network performance issues. One strategy is to use a compressed form of XML, and a complementary strategy is to use references (URIs). Instead of enumerating each set of attributes, a reference can be used to name a collection of attributes such as the hardware platform defaults. This has the advantage of enabling the separate fetching and caching of functional subsets. Another problem is to propagate changes to the current CC/PP descriptions to an origin server, a gateway or a proxy. One solution is to transmit the entire CC/PP descriptions with each change. This is not ideal for slow networks. An alternative is to send only the changes.

The CC/PP exchange protocol does not depend on the profile format that it conveys. Therefore another profile format besides the CC/PP description format could be applied to the CC/PP exchange protocol. For example, a user agent issues a request with URIs which address the profile information, and if the user agent changes the value of an attribute, such as turning sound off, only that change is sent together with the URIs. When an origin server receives the request, the origin server inquires of CC/PP repositories the CC/PP descriptions using the list of URIs. Then the origin server creates a tailored content using the fully enumerated CC/PP descriptions. The origin server might not obtain the 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.

A warning mechanism has been introduced for this purpose. It is likely that an origin server, a gateway or a proxy will be concerned with different device capabilities or user preferences. For example, the origin server may have responsibility to select content according to the users preferred language, while the proxy may have responsibility to transform the encoding format of the content. Therefore gateways or proxies might not forward all profile information to an origin server. The CC/PP exchange protocol might convey natural language codes within header field-values. Therefore internationalization issues must be considered. The internationalization policy of the CC/PP exchange protocol is based on RFC2277.

Considering how to maintain a session like RTSP (RFC2326) is worthwhile from the point of view of minimizing transactions (i.e. the session mechanism could permit the client to avoid resending the elements of the CC/PP descriptions that have not changed since the last time the information was transmitted). However a session mechanism would reduce cache efficiency, and requires maintaining states between a user agent and an origin server. An extension declaration is used to indicate that an extension has been applied to a message and possibly to reserve a part of the header namespace identified by a header field prefix.

The HTTP Extension Framework introduces two types of extension declaration strength: mandatory and optional, and two types of extension declaration scope: hop-by-hop and end-to-end. Which type of the extension declaration strengths and/or which type of the extension declaration scopes should be used depends on what the user agent needs to do.

The strength of the extension declaration should be mandatory if the user agent needs to obtain an error response when a server(an origin server, a gateway or a proxy) does not comply with the CC/PP exchange protocol.