ccpp-paper-0001

<HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (Win95; I) [Netscape]">  <TITLE>CC/PP: A user side framework for enhanced content negotiation</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <H1> Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation </H1> Author: <A HREF="mailto:franklin.reynolds@research.nokia.com">Franklin Reynolds, Nokia Research</A> Rewievers and co-authors: Mobile Access Interest Group User Agent Profile Definition group: <A HREF="mailto:hjelm@w3.org">Johan Hjelm, W3C/Ericsson</A>; <A HREF="mailto:sdawkins@nortel.com">Spencer Dawkins, Nortel</A>; <A HREF="mailto:singhal@us.ibm.com">Sandeep Singhal, IBM</A>. Web and TV interest group: <A HREF="mailto:hoscka@w3.org">Philip Hoscka, W3C</A>. <H1> 1. Abstract </H1> In this note we describe a method for using RDF, the Resource Description Format of the W3C, to create a general, yet extensible framework for describing user preferences and device capabilities. This information can be provided by the user to servers and content providers. The servers can use this information describing the user's preferences to customize the service or content provided.  The ability of RDF to reference profile information via URL:s assists in minimising the number of network transactions required to adapt content to a device, while the framework fits well into the current and future protocols being developed a the W3C and the WAP Forum. <H1> 2. Introduction </H1> This document describes the rationale and design of a profile service to describe the capabilities and  preferences of Web enabled applications. These profiles are intended to describe the capabilities of a user agent platform as well as the  preferences of the current user. User agent capabilities and references can be thought of as metadata or properties and descriptions of the user agent hardware and software. A description of the user's capabilities and preferences is necessary but insufficient to provide a general content negotiation solution. A general framework for content negotiation requires a means for describing the meta data or attributes and preferences of the user and his/hers/its agents, the attributes of the content and the rules for adapting content to the capapbilities and preferences of the user. The current mechanisms, such as accept headers and <alt> tags, are somewhat limited. Future services will be more demanding. For example: the content might be authored in multiple languages with different levels of confidence in the translation and the user might be able to understand multiple languages with different levels of proficiency. To complete the negotiation some rule is needed for selecting a version of the document based on weighing the user's proficiency in different languages against the quality of the documents various translations. This proposal focuses on the design of a user agent profile service based on XML/RDF. RDF, the Resource Description Format [<A HREF="#[RDF]">RDF</A>][<A HREF="#[RDF-Schema]">RDF-Schema</A>], was designed by the W3C consortium. RDF was designed to describe the machine understandable properties of web content. In this proposal we explore to use of RDF to describe capabilities and preferences associated with a user and the hardware and software agents used to access the web. We expect the use of a common technology to encode metadata describing both  content and a user's preferences will encourage the adoption of the technology and simplify the use of metadata in the Web. Hopefully, powerful tools for dealing with XML, some of which are already under development, will be available. Some potentially complex negotiation may have to take place between the content or the server of the content and the user of the content. For example: the content might be authored in multiple languages with different levels of confidence in the translation and the user might be able to understand multiple languages with different levels of proficiency. Though we hope that the use of RDF to encode the metadata describing the content and the user's preferences will facilitate the development of solutions to these kinds of complex negotiations, the implementation of appropriate rules for the negotiation is left to application developers. Alternate methods for describing the attributes or meta data of documents already exist. MIME [<A HREF="#[MIME]">MIME</A>] is widely deployed and the IETF Content Negotiation [<A HREF="#CONNEG">CONNEG]</A> working group is exploring possible extentions to MIME as the basis for its content negotiation work. Though this proposal is not directly compatible with the IETF CONNEG proposals currently under development, RDF allows the use of multiple vocabularies. We  expect to be able to use this feature to support the extended MIME dictionary being developed by the CONNEG group. This will provide a means for interoperability.  In addition to the IETF we are particularly concerned about the WAPForum and ETSI. The success of the CC/PP effort will undoubtedly hinge on our ability to cooperate with those organizations. <H2> 2.1 Protocol Considerations </H2> In a wireless network, bandwidth is also managed differently from wireline technologies. Wireless networks have also traditionally been prone to higher latencies than wireline networks, due to the longer setup time for connections. This restriction is disappearing in packet oriented networks, such as CDPD and CDMA, and with packet oriented bearer technologies such as GPRS and EDGE. The bandwidth limitation implies that the volume and number of network transactions should be limited as far as possible. Protocol design is beyond the scope of this group, however, the use of CC/PPs does have some impacts on web protocols and in this section some of those issues are discussed. The design and implementation of HTTP-NG is being actively carried out by another group. In this section we limit our discussion to some of the issues that many need to be considered in HTTPng or similar protocols: <OL> <LI> Profiles can be quite verbose. We need ways to reduce the overhead for networks like the cell phone network. <LI> CC/PPs should be cacheable on gateways/proxies. <LI> Components used to construct CC/PPs, such as vendor default profiles, should be independently cacheable. <LI> Changes to the active profile should be very lightweight. We don't want to have to resend the whole profile to turn off sound. <LI> The protocols must be able to exploit gateways and proxies if they exist. <LI> Though vendors may be able to supply URLs that name default profiles, the client devices  may store this information in case the vendor site  is unreachable for some reason. </OL> <H2> 2.2 Goals of this work </H2> The goal of this work is to: <UL> <LI> Enhance content negotiation speed through a standardized format for user agent profiles <LI> Minimize content negotiation transactions through the use of standardized formats and referencing URLs <LI> Recognize and support the composition of preferences and profiles originating from multiple sources (e.g. hardware vendors, software vendors, users, etc.) <LI> Enable user control over user agent information (e.g. personal preferences, etc.) <LI> Enable the security functions implied in RDF use for content negotiation formats <LI> Enable the use of compact data formats, such as tokenized XML, for content negotiation <LI> Support the presence of multiple network elements (proxies, servers, etc.) between the user agent and the origin server. </UL> The data model for the capability and preferences profile is similar to a table of tables. Each individual table roughly compares to a significant hardware or software component.  The primary goal is to be able to describe the desired table of tables in an unambiguous and inter operable fashion. Secondary goals include general applicability and good performance. <H1> 3. Meta data and profiles </H1> In most documents on 3rd generation networks, scenarios are presented where users will want to assert several preferential factors[<A HREF="#IMT-2000">IMT-2000</A>], such as: <UL> <LI> preferred language <LI> sound on/off <LI> images on/off <LI> privacy preferences (like P3P) <LI> scripting on/off <LI> cookies on/off <LI> etc. </UL> They will also want to assert hardware platform attributes, like: <UL> <LI> vendor <LI> model <LI> class of device {phone, pda, printer, etc.} <LI> screen size <LI> colors <LI> available bandwidth <LI> CPU <LI> memory <LI> input device <LI> secondary storage <LI> speaker <LI> etc. </UL> We also expect them to want to assert software defined variables, such as: <UL> <LI> application brand and version <LI> level of HTML support <LI> supported XML vocabularies <LI> Level of CSS support <LI> supported RDF vocabularies <LI> level of WAP support <LI> supported scripting languages(s) <LI> etc. </UL> It is interesting to note that metadata (capabilities and preferences) associated with the device, the software used to access the web and the user of the device could originate from different sources created at different times. The hardware vendor might have profile information available for its products, the software vendor might supply a default profile, and the user's preferences might apply across multiple applications (preferred language) or change during a session (sound on/off). On the other hand, we don't want this to get out of hand. If it is too complex people won't use it and if it too slow people won't use it. The challenge is to provide an efficient mechanism for communicating the profiles for constrained devices, such as smart phones, using slow networks, such as GSM SMS. <H2> 4. Composite Capability/Preferences Profiles (CC/PP) </H2> The CC/PP proposal describes an interoperable encoding for capabilities and preferences of user agents, specifically web browsers. The proposal is also intended to support applications other than browsers, including email, calendars, etc. Support  for peripherals like printers and fax machines will require other types of attributes such as  type of printer, location, Postscript support, color, etc. We believe an XML/RDF based approach would be suitable. However, metadata descriptions of devices like printers or fax machines may use a different scheme. Every reasonable effort will be made to provide interoperability other important proposals. The data model for a CC/PP is a table of tables. In the simplest form each table in the CC/PP is just a collection of RDF statements with simple, atomic properties. One can think of these tables as being constructed from default settings, persistent local changes and temporary changes. Default settings might be properties defined by the vendor. In the case of hardware the vendor often has a very good idea of the properties of any given model of product. However, the current owner of the product may be able to add options, such as memory or persistent store or additional I/O devices that add new properties or change the values of some original properties. These would be persistent local changes. An example of a temporary change would be turning sound on or off. From the point of view of any particular network transaction the only property or capability information that is important is whatever is "current".  The network transaction does not care about the differences between defaults or persistent local changes, it only cares about the capabilities and preferences that apply to the current network transaction. Because this information may originate from multiple sources and because different parts of the capability profile may be differentially cached, the various components must be explicitly described in the network transaction. It is worth noting that the persistent encoding of profile information and the encoding for the purposes of interoperability (communication) need not be the same.  In this document we consider the use of XML/RDF as the interoperability encoding. Persistent storage of profile information is left to the individual applications.  RDF processing does not implicitly preserve order. Consequently the value of a property cannot be changed by simply having another statement assigning a different value to a property with the same name. Instead of overriding the previous value of the property, you get two properties with the same name and two different values. RDF processing does not guarantee preservation of declaration order so there is no way to use declaration order to define a precedence relation. To get the effect of overriding the properties of a platforms defaults, the platform attributes are aggragated  via a "description block". This makes it possible for an application to define a precedence relation between platform defaults and user specified overrides. <H2> 4.1 Inline example </H2> Consider a simple example of inline encoding for a hypothetical smart phone: <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="hardware platform"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:Vendor="Nokia" /></TT> <TT>        <PRF:Model="2160" /></TT> <TT>        <PRF:Type="PDA" /></TT> <TT>        <PRF:ScreenSize="800x600x24" /></TT> <TT>        <PRF:CPU="PPC" /></TT> <TT>        <PRF:Keyboard="Yes" /></TT> <TT>        <PRF:Speaker="Yes" /></TT> <TT>    </Description></TT> <TT>    <PRF:Memory="32mb" /></TT> <TT></Description></TT> <TT><Description ID="software platform"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:OS="EPOC1.0" /></TT> <TT>        <PRF:HTMLVersion="4.0" /></TT> <TT>        <PRF:JavaScriptVersion="4.0" /></TT> <TT>        <PRF:WAPVersion="1.0" /></TT> <TT>        <PRF:WMLScriptVersion="1.0" /></TT> <TT>    </Description></TT> <TT>    <PRF:Sound="Off" /></TT> <TT>    <PRF:Images="Off" /></TT> <TT></Description></TT> <TT><Description ID="EpocEmail"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:Version="EpocEmail1.0" /></TT> <TT>        <PRF:HTMLVersion="4.0" /></TT> <TT>    </Description></TT> <TT></Description></TT> <TT><Description ID="EpocCalendar"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:Version="EpocCalendar1.0" /></TT> <TT>        <PRF:HTMLVersion="4.0" /></TT> <TT>    </Description></TT> <TT></Description></TT> <TT><Description ID="user preferences"></TT> <TT>    <PRF:Language="English" /></TT> <TT></Description></TT> This sample profile is a collection of the capabilities and preferences associated with either a user or the hardware platform or a software component. Each collection of capabilities and preferences are organized within a description block. These description blocks may contain subordinate description blocks to describe default attributes or other collections of attributes. One new namespace "PRF" was introduced which contains the vocabulary used for all attributes and preferences. The PRF namespace is intended to provide a well defined collection of attributes of general utility. There is nothing that prevents the use of multiple namespaces. This might be useful to either define experimental or non-standard attributes or to define application specific capabilities and preferences. Delivering all of the CC/PP at one time, inline simplifies some things. If the user has overridden some default property, then there is no reason to send the default - all that is needed is to send the current value for that attribute. In the example above, there is no reason to send the hardware platform's default setting of "Memory=16mb" since the user has upgraded the memory to 32mb. The significance of an attribute is generally limited to the component it is describing. For example, each software application can define a value for a "Version" attribute. This indicates the version of the particular application being described. In general, side effects that extend beyond the bounds of a particular component are not defined in this document. The relationship between components is system and application dependent. For example, if the "Sound" attribute is defined to be "Off" in the hardware platform but "On" for email, is voice mail delivered (audibly) or not? What should happen if "Sound" is "On" at hardware and email but "Off" for Calendar? The major disadvantage of this format is that it is verbose. Some networks are very slow and this would be a moderately expensive way to handle metadata. There are several optimizations possible to help deal network performance issues. <H2> 4.2 Indirect References </H2> Instead of enumerating each set of attributes, a remote 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. This might be very nice if the link between the gateway or the proxy and the client agent was slow and the link between the gateway or proxy and the site named by the remote reference was fast - a typical case when the user agent is a smart phone. Another advantage is the simplification of the development of different vocabularies for hardware vendors and software vendors (assuming this is a good thing). The following example uses indirect references. First the profile provided by the user agent. It refers to default profiles provided by the hardware and software platform vendors: <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="hardware platform"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:HardwareDefaults = "http://www.nokia.com/profiles/2160" /></TT> <TT>    </Description></TT> <TT>    <PRF:Memory="32mb" /></TT> <TT></Description></TT> <TT><Description ID="software platform"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:SoftwarePlatformDefaults = "http://www.symbian.com/epoc/profiles/PDA" /></TT> <TT>    </Description></TT> <TT>    <PRF:Sound="Off" /></TT> <TT>    <PRF:Images="Off" /></TT> <TT></Description></TT> <TT><Description ID="EpocEmail"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:SoftwarePlatformDefaults = "http://www.symbian.com/epoc/profiles/epocemail" /></TT> <TT>    </Description></TT> <TT></Description></TT> <TT><Description ID="EpocCalendar"></TT> <TT>    <Description ID="defaults"></TT> <TT>        <PRF:SoftwarePlatformDefaults = "http://www.symbian.com/epoc/profiles/epoccal" /></TT> <TT>    </Description></TT> <TT></Description></TT> <TT><Description ID="user preferences"></TT> <TT>    <PRF:Language="English" /></TT> <TT></Description></TT> <TT>Next, the profile provided by the hardware vendor.</TT> <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="hardware platform"></TT> <TT>        <PRF:Vendor="Nokia" /></TT> <TT>        <PRF:Model="2160" /></TT> <TT>        <PRF:Type="PDA" /></TT> <TT>        <PRF:ScreenSize="800x600x24" /></TT> <TT>        <PRF:CPU="PPC" /></TT> <TT>        <PRF:Keyboard="Yes" /></TT> <TT>        <PRF:Speaker="Yes" /></TT> <TT>        <PRF:Memory="16mb" /></TT> <TT></Description></TT>   Finally, the profiles provided by the software platform and application vendors. <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="software platform"></TT> <TT>            <PRF:OS="EPOC1.0" /></TT> <TT>            <PRF:HTMLVersion="4.0" /></TT> <TT>            <PRF:JavaScriptVersion="4.0" /></TT> <TT>            <PRF:WAPVersion="1.0" /></TT> <TT>            <PRF:WMLScriptVersion="1.0" /></TT> <TT></Description></TT> <TT>-----------------------------------------------------------------------</TT> <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="EpocEmail"></TT> <TT>        <PRF:Version="EpocEmail1.0" /></TT> <TT>        <PRF:HTMLVersion="4.0" /></TT> <TT></Description></TT> <TT>------------------------------------------------------------------------</TT> <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="EpocCalendar"></TT> <TT>        <PRF:Version="EpocCalendar1.0" /></TT> <TT>        <PRF:HTMLVersion="4.0" /></TT> <TT></Description></TT>   All we did in the second example was group different collections of default attributes together in such a way that they could be named by a URL. Since the hardware and software platform default profiles were independently described using a URL, they can be separately fetched and cached. When an application in the server/gateway/proxy uses RDF to process the CC/PP it may encounter attrributes with default values and user specified values. It is up the application to enforce the rule that user specified attributes over ride default values. RDF does not provide a convenient mechanism for implementing that rule. 4.3 Runtime Changes It is worth noting that the information we are most concerned with is the current profile. Default properties might have some importance, for example, they may be worth caching independently of any particular session or user. However, the key is for the client and the server/gateway/proxy to have a consistent view of the current profile. It is important to be able to add to and modify  attributes associated with the current CC/PP. We need to be able to modify the value of certain attributes, such as turning sound on and off and we need to make persistent changes to reflect things like hardware upgrades. For example, a third party memory upgrade. We need to be able to modify the default profile provided by the vendor. However, we only need to concern ourselves with changes to the current profile. Reflecting changes to preferences or capabilities in persistent storage is out of scope. One solution is to transmit the entire CC/PP with each change. It would replace the previous profile. This is not ideal for slow networks. An alternative is to send only the changes.  Thus if Sound were to be changed from "off" to "on" the only data that would need to be sent would be: <TT><RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT> <TT>   xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"></TT> <TT><Description ID="software platform"></TT> <TT>            <PRF:Sound="On" /></TT> <TT><Description></TT>   <H1> 5. Protocol considerations </H1> When used in the context of a web browsing application, a CC/PP should be associated with a  notion of a current session rather than a user or a node. HTTP and WTP (the WAP session protocol) both define  different session semantics. The client, server and and gateways and proxies may already have their own, well defined notions of what constitutes a connection or a session. Our protocol strategy is to send as little information as possible and if anyone is missing something, they have to ask for it. If there is good reason to believe that someone is going to ask for a profile, the client can elect to send the most efficient form of the profile that makes sense. Consider the following possible interaction between a server and a client. When the Client begins a session it sends a minimal profile using as much indirection as possible.  If the server/gateway/proxy does not have a CC/PP for this session, then it asks for one. When a  profile  is sent the client tries a minimal form, i.e., it uses as much indirection as possible and only names the non default attributes of the profile. The server/gateway/proxy can try to fill in the profile using the indirect HTTP references (which may be independently cached). If any of these fail, a request for additional data can be sent to the user which can reply with a  fully enumerated profile. If the client changes the value of an attribute, such as turning sound off, only that change needs to be sent. It is likely that servers and gateways/proxies will be concerned with different preferences. For example, the server may need to know which language the user prefers and the gateway may have responsibility to trim images to 8 bits of color (to save bandwidth). However, the exact use of profile information by each server/gateway/proxy is hard to predict. Therefore gateways/proxies should forward all profile information to the server. Any requests for profile information that the gateway/proxy cannot satisfy should be forwarded to the client. The ability to compose a profile from sources provided by third parties at run-time exposes the system to a new type of attack. For example, if the URL that named the hardware default platform defaults were to be compromised via an attack on DNS it would be possible to load incorrect profile information. If cached within a server/gateway/proxy this could be a serious denial of service attack. If this is a serious enough problem it may be worth adding digital signatures to the URLs used to refer to profile components. This protocol discussion is not a specific proposal for HTTP or WTP. Its intent is merely to illustrate how the design allows us to exploit the cachability of both the current session state and the default profiles. 6. Summary In this document, we have described a proposal for the use of XML/RDF to describe user preferences and the capabilities of the device and software used to access the Web.  Encodings of hypothetical user profiles  were used to illustrate some of the benefits of RDF. Some of the possible ramifications for Web protocol  design were discussed. 7. References <A NAME="[CONNEG]"></A>[CONNEG] <A HREF="http://www.ietf.org/html.charters/conneg-charter.html">IETF working group on content negotiation</A> <A NAME="[IMT-2000]"></A>[IMT-2000] <A HREF="http://www.imt-2000.com">Ericsson in Wideband Wireless Multimedia</A>. <A NAME="[MIME]"></A>[MIME] <A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2045.txt">RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, Borenstein N., Freed N., 1996/11/27</A> <A NAME="[RDF]"></A>[RDF] <A HREF="http://www.w3.org/TR/WD-rdf-syntax/">Resource Description Framework, (RDF) Model and Syntax Specification. Lassila O., Swick R. W3C Working Draft.</A> <A NAME="[RDF-Schema]"></A>[RDF-Schema] <A HREF="http://www.w3.org/TR/1998/WD-rdf-schema/">Resource Description Framework (RDF) Schema Specification. Brickley, D., Guha, R.V. , Layman, A., W3C Working Draft.</A> </BODY></HTML>