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]">
  <!-- Created with AOLpress/2.0 -->
  <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>
<P>
Author: <A HREF="mailto:franklin.reynolds@research.nokia.com">Franklin Reynolds,
Nokia Research</A>
<P>
Rewievers and co-authors:
<P>
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>.
<P>
Web and TV interest group: <A HREF="mailto:hoscka@w3.org">Philip Hoscka,
W3C</A>.
<H1>
  1. Abstract
</H1>
<P>
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.&nbsp; 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>
<P>
<FONT COLOR="#000000">This document describes the rationale and design of
a profile service to describe the capabilities and&nbsp; preferences of Web
enabled applications. These profiles are intended to describe the capabilities
of a user agent platform as well as the&nbsp; 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.</FONT>
<P>
<FONT COLOR="#000000">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 &lt;alt&gt; 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.</FONT>
<P>
<FONT COLOR="#000000">This proposal focuses on the design of a user agent
profile service based on XML/RDF. RDF, the Resource Description Format
</FONT>[<A HREF="#[RDF]">RDF</A>][<A HREF="#[RDF-Schema]">RDF-Schema</A>]<FONT
    COLOR="#000000">, 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&nbsp; 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.</FONT><FONT COLOR="#000000"></FONT>
<P>
<FONT COLOR="#000000">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.</FONT>
<P>
<FONT COLOR="#000000">Alternate methods for describing the attributes or
meta data of documents already exist. MIME
</FONT>[<A HREF="#[MIME]">MIME</A>] is widely deployed and
<FONT COLOR="#000000">the IETF Content Negotiation
[</FONT><A HREF="#CONNEG"><FONT COLOR="#FFFF00">CONNEG</FONT><FONT COLOR="#000000">]</FONT></A>
working group is exploring possible extentions to MIME as the basis for its
content negotiation work. <FONT COLOR="#000000">Though this proposal is not
directly compatible with the IETF CONNEG proposals currently under development,
RDF allows the use of multiple vocabularies. We&nbsp; 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.&nbsp;
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.</FONT>
<H2>
  <FONT SIZE=+2>2.1 Protocol Considerations</FONT>
</H2>
<P>
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.
<P>
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>
    <FONT COLOR="#000000">Profiles can be quite verbose. We need ways to reduce
    the overhead for networks like the cell phone network.</FONT>
  <LI>
    <FONT COLOR="#000000">CC/PPs should be cacheable on gateways/proxies.</FONT>
  <LI>
    <FONT COLOR="#000000">Components used to construct CC/PPs, such as vendor
    default profiles, should be independently cacheable.</FONT>
  <LI>
    <FONT COLOR="#000000">Changes to the active profile should be very lightweight.
    We don't want to have to resend the whole profile to turn off sound.</FONT>
  <LI>
    <FONT COLOR="#000000">The protocols must be able to exploit gateways and
    proxies if they exist.</FONT>
  <LI>
    <FONT COLOR="#000000">Though vendors may be able to supply URLs that name
    default profiles, the client devices&nbsp; may store this information in
    case the vendor site&nbsp; is unreachable for some reason.</FONT>
</OL>
<H2>
  <FONT SIZE=+2>2.2 Goals of this work</FONT>
</H2>
<P>
The goal of this work is to:
<UL>
  <LI>
    <FONT COLOR="#000000">Enhance content negotiation speed through a standardized
    format for user agent profiles</FONT>
  <LI>
    <FONT COLOR="#000000">Minimize content negotiation transactions through the
    use of standardized formats</FONT> 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>
    <FONT COLOR="#000000">Enable user control over user agent information (e.g.
    personal preferences, etc.)</FONT>
  <LI>
    <FONT COLOR="#000000">Enable the security functions implied in RDF use for
    content negotiation formats</FONT>
  <LI>
    <FONT COLOR="#000000">Enable the use of compact data formats, such as tokenized
    XML, for content negotiation</FONT>
  <LI>
    <FONT COLOR="#000000">Support the presence of multiple network elements (proxies,
    servers, etc.) between the user agent and the origin server.</FONT>
</UL>
<P>
The data model for the capability and preferences profile is similar to
<FONT COLOR="#000000">a table of tables. Each i</FONT>ndividual table roughly
compares to a significant hardware or software component.&nbsp; 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>
<P>
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>
<P>
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>
<P>
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>
<P>
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>
  <FONT SIZE=+3>4. Composite Capability/Preferences Profiles (CC/PP)</FONT>
</H2>
<P>
The CC/PP proposal describes an interoperable encoding for capabilities and
preferences of user agents, specifically web browsers.
<FONT COLOR="#000000">The proposal is also intended to support applications
other than browsers, including email, calendars, etc. Support&nbsp; for
peripherals like printers and fax machines will require other types of attributes
such as&nbsp; ty</FONT>pe of printer, location, Postscript support, color,
etc. We believe an XML/RDF based approach would be suitable.
Howev<FONT COLOR="#000000">er, metadata descriptions of devices like printers
or fax machines may use a different scheme.</FONT> Every reasonable effort
will be made to provide interoperability other important proposals.
<P>
The data model for a CC/PP is a table of t<FONT COLOR="#000000">ables. In
the simplest form each table in the CC/PP is just a collection of RDF statements
with simple, atomic properties.</FONT> 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.
<P>
<FONT COLOR="#000000">From the point of view of any particular network
transaction the only property or capability information that is important
is whatever is "current".</FONT>&nbsp; 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.
<P>
It is worth not<FONT COLOR="#000000">ing that the persistent encoding of
profile information and the encoding for the purposes of interoperability
(communication) need not be the same.</FONT>&nbsp; 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.
<P>
&nbsp;RDF processing does not implicitly preserve order. Consequently
th<FONT COLOR="#000000">e value of a property cannot be changed by simply
having another statement assigning a different value to a property with the
same name. </FONT>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&nbsp; via a "description block". This makes it
possible for an application to <FONT COLOR="#000000">define a precedence
relation between platform defaults and user specified overrides.</FONT>
<H2>
  4.1 Inline example
</H2>
<P>
Consider a simple example of inline encoding for a hypothetical smart phone:
<P>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<P>
<TT>&lt;Description ID="hardware platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Vendor="Nokia"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Model="2160"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Type="PDA" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:ScreenSize="800x600x24"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:CPU="PPC" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Keyboard="Yes"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Speaker="Yes"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Memory="32mb" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="software platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:OS="EPOC1.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:HTMLVersion="4.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:JavaScriptVersion="4.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:WAPVersion="1.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:WMLScriptVersion="1.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Sound="Off" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Images="Off" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="EpocEmail"&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Version="EpocEmail1.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:HTMLVersion="4.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="EpocCalendar"&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:Version="EpocCalendar1.0" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:HTMLVersion="4.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="user preferences"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Language="English" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
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.
O<FONT COLOR="#000000">ne 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.</FONT>
<P>
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.
<P>
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?
<P>
The major disadvantage of this for<FONT COLOR="#000000">mat is that it is
verbose. Some ne</FONT>tworks 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>
<P>
Instead of enumerating each set of attribu<FONT COLOR="#000000">tes, a remote
reference can be used to name a collection of attributes such as the hardware
platform defaults. This has the advantage</FONT> 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).
<P>
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:
<P>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<P>
<TT>&lt;Description ID="hardware platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:HardwareDefaults =
"http://www.nokia.com/profiles/2160" /&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Memory="32mb" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="software platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:SoftwarePlatformDefaults = "http://www.symbian.com/epoc/profiles/PDA"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Sound="Off" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Images="Off" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="EpocEmail"&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:SoftwarePlatformDefaults =
"http://www.symbian.com/epoc/profiles/epocemail" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="EpocCalendar"&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;Description ID="defaults"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:SoftwarePlatformDefaults = "http://www.symbian.com/epoc/profiles/epoccal"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;/Description&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>&lt;Description ID="user preferences"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; &lt;PRF:Language="English" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>Next, the profile provided by the hardware vendor.</TT>
<P>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<P>
<TT>&lt;Description ID="hardware platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Vendor="Nokia"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Model="2160"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Type="PDA" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:ScreenSize="800x600x24"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:CPU="PPC" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Keyboard="Yes"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Speaker="Yes"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Memory="16mb"
/&gt;</TT> <BR>
<TT>&lt;/Description&gt;</TT> <BR>
&nbsp;
<P>
Finally, the profiles provided by the software platform and application vendors.
<P>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<P>
<TT>&lt;Description ID="software platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:OS="EPOC1.0" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:HTMLVersion="4.0" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:JavaScriptVersion="4.0" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:WAPVersion="1.0" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:WMLScriptVersion="1.0" /&gt;</TT>
<BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>-----------------------------------------------------------------------</TT>
<BR>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<P>
<TT>&lt;Description ID="EpocEmail"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:Version="EpocEmail1.0"
/&gt;</TT> <BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:HTMLVersion="4.0"
/&gt;</TT> <BR>
<TT>&lt;/Description&gt;</TT>
<P>
<TT>------------------------------------------------------------------------</TT>
<BR>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<BR>
<TT>&lt;Description ID="EpocCalendar"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:Version="EpocCalendar1.0" /&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;PRF:HTMLVersion="4.0"
/&gt;</TT> <BR>
<TT>&lt;/Description&gt;</TT> <BR>
&nbsp;
<P>
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
UR<FONT COLOR="#000000">L. 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.</FONT>
<P>
<B><FONT SIZE=+2>4.3 Runtime Changes</FONT></B>
<P>
It is worth noting that the information we are most concerned with is the
<B>current</B> 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.
<P>
It is important to be able to add to and modify&nbsp; attributes associated
with the current CC/PP. We need to be <FONT COLOR="#000000">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. How</FONT>ever, 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.
<P>
One solu<FONT COLOR="#000000">tion 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.</FONT>&nbsp; Thus if
Sound were to be changed from "off" to "on" the only data that would need
to be sent would be:
<P>
<TT>&lt;RDF xmlns="http://www.w3C.org/TR/WD-rdf-syntax" prefix="RDF"</TT>
<BR>
<TT>&nbsp;&nbsp;
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary"&gt;</TT>
<P>
<TT>&lt;Description ID="software platform"&gt;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;PRF:Sound="On" /&gt;</TT> <BR>
<TT>&lt;Description&gt;</TT> <BR>
&nbsp;
<H1>
  5. Protocol considerations
</H1>
<P>
<FONT COLOR="#000000">When used in the context of a web browsing application,
a CC/PP should be associated with a&nbsp; notion of a current session rather
than a user or a node. HTTP and WTP (the WAP session protocol) both define&nbsp;
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.</FONT>
<P>
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.&nbsp; If the server/gateway/proxy does not have
a CC/PP for this session, then it asks for one<FONT COLOR="#000000">. When
a&nbsp; profile&nbsp; 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. </FONT>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&nbsp; fully enumerated profile. If the client changes
the value of an attribute, such as turning sound off, only that change needs
to be sent.
<P>
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.
<P>
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.
<P>
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.
<P>
<B><FONT SIZE=+3>6. Summary</FONT></B>
<P>
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.&nbsp; Encodings of hypothetical user profiles&nbsp;
were used to illustrate some of the benefits of RDF. Some of the possible
ramifications for Web protocol&nbsp; design were discussed.
<P>
<B><FONT SIZE=+3>7. References</FONT></B>
<P>
<A NAME="[CONNEG]"></A>[CONNEG]
<A HREF="http://www.ietf.org/html.charters/conneg-charter.html">IETF working
group on content negotiation</A>
<P>
<A NAME="[IMT-2000]"></A>[IMT-2000] <A HREF="http://www.imt-2000.com">Ericsson
in Wideband Wireless Multimedia</A>.
<P>
<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>
<P>
<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>
<P>
<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>