NOTE-CCPP-19990727 36.2 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
  <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (WinNT; I) [Netscape]">
  <!-- Created with AOLpress/2.0 -->
  <STYLE type=text/css>
        .example {
        BACKGROUND-COLOR: #f9f5de; BORDER-BOTTOM: 1px solid; BORDER-LEFT: 1px solid; BORDER-RIGHT: 1px solid; BORDER-TOP: 1px solid; COLOR: #5d0091; MARGIN-LEFT: 10%; WIDTH: 65%
        }
        img.W3CIcon {
        BORDER: 0;
        }
</STYLE>
  <TITLE>CC/PP: A user side framework for enhanced content negotiation</TITLE>
  <LINK rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-NOTE">
</HEAD>
<BODY>
<DIV class="head">
  <IMG src="http://www.w3.org/Icons/WWW/w3c_home" ALT ="W3C" class="W3CIcon">
  <H1>
    Composite Capability/Preference Profiles (CC/PP): A user side framework for
    content negotiation
  </H1>
  <H2>
    W3C Note 27 July 1999
  </H2>
  <DL>
    <DT>
      This Version:
    <DD>
      <A HREF="http://www.w3.org/1999/07/NOTE-CCPP-19990727/">http://www.w3.org/TR/1999/NOTE-CCPP-19990727</A>
    <DT>
      Latest Version:
    <DD>
      <A HREF="http://www.w3.org/TR/NOTE-CCPP">http://www.w3.org/TR/NOTE-CCPP</A>
    <DT>
      Previous version:
    <DD>
      <A HREF="http://www.w3.org/TR/1998/NOTE-CCPP-19981130">http://www.w3.org/TR/1998/NOTE-CCPP-19981130</A>
  </DL>
  <DL>
    <DT>
      Editors
    <DD>
      Franklin Reynolds
      <A HREF="mailto:franklin.reynolds@research.nokia.com">franklin.reynolds@research.nokia.com</A>,
      Nokia Research Center
    <DD>
      Johan Hjelm <A HREF="mailto:hjelm@w3.org">hjelm@w3.org</A>, W3C/Ericsson
    <DD>
      Spencer Dawkins <A HREF="mailto:sdawkins@nt.com">sdawkins@nt.com</A>, Nortel
    <DD>
      Sandeep Singhal <A HREF="mailto:singhal@us.ibm.com">singhal@us.ibm.com</A>,
      IBM
  </DL>
  <P>
  <H2>Status of this document</H2>
  <P>
  This document is a work in progress, representing a revision of the working
  draft dated 1998-10-05 incorporating suggestions received in review comments
  and further deliberations of the W3C Mobile Access Interest Group. It also
  incorporates suggestions resulting from reviews by members of the IETF CONNEG
  working group and the WAPForum. It is the first public review draft of this
  document. Publication as a working draft does not imply endorsement by the
  W3C membership.
  <P>
  All RDF code has been <A HREF="http://jigsaw.w3.org:8000/description">validated
  </A>with <A HREF="http://www.w3.org/RDF/Implementations/SiRPAC/">SiRPAC</A>,
  the W3C RDF validator.
  <P>
  The RDF code has been updated on July 26, 1999, to reflect the Resource
  Description Framework (RDF) Model and Syntax Specification Recommendation,
  and the 3&nbsp;March Resource Description Framework (RDF) Schemas Proposed
  Recommendation. Minor updates to the text, reflecting the work that has been
  conducted in the W3C since November 1998, has also been added.
  <P>
  Review comments from the public on this document should be sent to
  <A HREF="mailto:www-mobile@w3.org">www-mobile@w3.org</A> which is an
  automatically
  <A HREF="http://lists.w3.org/Archives/Public/www-mobile/">archived</A> email
  list. Information on how to subscribe to public W3C email lists can be found
  at <A HREF="http://www.w3.org/Mail/Lists">http://www.w3.org/Mail/Request</A>.
  <P>
  <EM>This document is a NOTE made available by the W3 Consortium for discussion
  only. This indicates no endorsement of its content, nor that the Consortium
  has, is, or will be allocating any resources to the issues addressed by this
  NOTE.</EM>
  <P>
  <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">Copyright</A>
  &copy; 1997,1998, 1999 <A HREF="http://www.w3.org">W3C</A>
  (<A HREF="http://www.lcs.mit.edu">MIT</A>,
  <A HREF="http://www.inria.fr/">INRIA</A>,
  <A HREF="http://www.keio.ac.jp/">Keio</A> ), All Rights Reserved. W3C
  <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#LegalDisclaimer">liability</A>,
  <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3CTrademarks">trademark</A>,
  <A HREF="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
  use</A> and
  <A HREF="http://www.w3.org/Consortium/Legal/copyright-software.html">software
  licensing</A> rules apply.
</DIV>
  <H2>
    Table of Contents
  </H2>
  <P>
  <A HREF="#Abstract">Abstract</A>
  <P>
  <A HREF="#1">1. Introduction</A>
  <P>
  <A HREF="#11">1.1 Wireless networks</A>
  <P>
  <A HREF="#12">1.2 Goals of this work</A>
  <P>
  <A HREF="#2">2. Metadata and profiles</A>
  <P>
  <A HREF="#3">3. Composite Capability/Preferences Profiles (CC/PP)</A>
  <P>
  <A HREF="#31">3.1 Inline example</A>
  <P>
  <A HREF="#32">3.2 Indirect references</A>
  <P>
  <A HREF="#33">3.3 Runtime changes</A>
  <P>
  <A HREF="#4">4. Protocol considerations</A>
  <P>
  <A HREF="#5">5. Summary</A>
  <P>
  <A HREF="#References">References</A>
  <H2>
    <A NAME="Abstract">Abstract</A>
  </H2>
  <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. The ability of RDF to reference profile information via
  URLs assists in minimizing 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.
  <H2>
    <A NAME="1">1. Introduction</A>
  </H2>
  <P>
  This document describes the rationale and design of a profile service to
  describe the capabilities and preferences of Web enabled applications. A
  Composite Capability/Preference Profile (CC/PP) is a collection of the
  capabilities and preferences associated with user and the agents used by
  the user to access the World Wide Web. These user agents include the hardware
  platform, system software and applications used by the user. User agent
  capabilities and references can be thought of as metadata or properties and
  descriptions of the user agent hardware and software.
  <P>
  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 capabilities
  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.
  <P>
  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. There is a specification that describes how to encode
  RDF using XML. 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 and RDF, some
  of which are already under development, will be available.
  <P>
  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.
  <P>
  Alternate methods for describing the attributes or meta data of documents
  are under investigation by other organizations such as the IETF Content
  Negotiation [<A HREF="#CONNEG">CONNEG</A>] working group. Though this proposal
  is not directly compatible with the IETF CONNEG proposals currently under
  development, RDF allows the use of multiple vocabularies. Hopefully, this
  will provide a means for interoperability, at least at the level of attribute
  vocabularies. The CONNEG working group is also developing a media feature
  matching algebra. Efforts are underway to insure that the CONNEG algebra
  and RDF are complementary technologies. 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.
  <H3>
    <A NAME="11">1.1 Wireless Networks</A>
  </H3>
  <P>
  Compared to the typical wireline data networks available to corporate desktop
  users, wireless networks are more expensive, provide less bandwidth, with
  higher latency and less reliability. SMS data service on GSM networks provides
  22 bytes (!) per second to a typical mobile host. The situation is rapidly
  changing. Emerging packet oriented, cellular networks, such as CDPD and CDMA,
  and with packet oriented bearer technologies such as GPRS and EDGE are providing
  higher bandwidth and lower latency. Within the next decade we should see
  the deployment of "third generation" cellular networks that provide low latency
  and megabit bandwidth to mobile hosts.
  <P>
  But today's wireless networks are slow and tomorrow's wireless networks will
  be slow compared to tomorrow's wireline networks. Protocols designed for
  wireline networks without regard for the limitations of wireless networks
  often exhibit undesirable behavior when deployed on wireless networks.
  <P>
  CC/PPs 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. Protocol design is beyond the scope of this group,
  however, the use of CC/PPs does have some impact 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:
  <DL>
    <DT>
      Profiles can be quite verbose.
    <DD>
      We need ways to reduce the overhead for low bandwidth networks like the cell
      phone network.
    <DT>
      CC/PPs should be cacheable on gateways/proxies.
    <DT>
      Components used to construct CC/PPs, such as vendor default profiles, should
      be independently cacheable.
    <DT>
      Changes to the active profile should be very lightweight.
    <DD>
      We don't want to have to resend the whole profile to turn off sound.
    <DT>
      The protocols must be able to exploit gateways and proxies if they exist.
    <DT>
      Though vendors may be able to supply URLs that name default profiles, the
      client devices may store this information in case the vendor site&nbsp; is
      unreachable for some reason.
  </DL>
  <H3>
    <A NAME="12">1.2 Goals of this work</A>
  </H3>
  <P>
  The goal of this work is to:
  <DL>
    <DT>
      Enhance content negotiation speed through a standardized format for user
      agent profiles.
    <DT>
      Minimize content negotiation transactions through the use of standardized
      formats and referencing URLs.
    <DT>
      Recognize and support the composition of preferences and profiles originating
      from multiple sources (e.g. hardware vendors, software vendors, users, etc.).
    <DT>
      Enable user control over user agent information (e.g. personal preferences,
      etc.).
    <DT>
      Enable the use of compact data formats, such as tokenized XML
      [<A HREF="#[TokenXML]">TokenXML</A>], for content negotiation.
    <DT>
      Support the presence of multiple network elements (proxies, servers, etc.)
      between the user agent and the origin server.
  </DL>
  <P>
  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.
  <H2>
    <A NAME="2">2. Metadata and profiles</A>
  </H2>
  <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>]. Also, mechanisms for this exist
  [<A HREF="#[Agent-attrib]">Agent-attrib</A>]. The preferences are such as:
  <DL>
    <DT>
      preferred language
    <DT>
      sound on/off
    <DT>
      images on/off
    <DT>
      privacy preferences (like P3P)
    <DT>
      scripting on/off
    <DT>
      cookies on/off
    <DT>
      etc.
  </DL>
  <P>
  They will also want to assert hardware platform attributes, like:
  <DL>
    <DT>
      vendor
    <DT>
      model
    <DT>
      class of device {phone, pda, printer, etc.}
    <DT>
      screen size
    <DT>
      colors
    <DT>
      available bandwidth
    <DT>
      CPU
    <DT>
      memory
    <DT>
      input device
    <DT>
      secondary storage
    <DT>
      loudspeaker
    <DT>
      etc.
  </DL>
  <P>
  We also expect them to want to assert software defined variables, such as:
  <DL>
    <DT>
      application brand and version
    <DT>
      level of HTML support
    <DT>
      supported XML vocabularies
    <DT>
      Level of CSS support
    <DT>
      supported RDF vocabularies
    <DT>
      level of WAP support
    <DT>
      supported scripting languages(s)
    <DT>
      etc.
  </DL>
  <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). 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>
    <A NAME="3">3. Composite Capability/Preferences Profiles (CC/PP)</A>
  </H2>
  <P>
  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.
  <P>
  The basic data model for a CC/PP is a collection of tables. Though RDF makes
  modeling a wide range of data structures possible, it is unlikely that this
  flexibility will used in the creation of complex data models for profiles.
  In the simplest form each table in the CC/PP is a collection of RDF statements
  with simple, atomic properties. These tables may be constructed from default
  settings, persistent local changes or temporary changes made by a user. One
  extension to the simple table of properties data model is the notion of a
  separate, subordinate collection of default properties. Default settings
  might be properties defined by the vendor. In the case of hardware the vendor
  often has a very good idea of the physical 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>
  The profile is associated with the current network session or transaction.
  Each major component may have a collection of attributes or preferences.
  Examples of major components are the hardware platform upon which all the
  software is executing, the software platform upon which all the applications
  are hosted and each of the applications. This following is a simplified example
  of the sort of data expected to be encoded in these profiles.
  <P>
  <B>Hardware Platform</B>
  <P>
  Memory = 64mb
  <P>
  CPU = PPC
  <P>
  Screen = 640*400*8
  <P>
  BlueTooth = Yes
  <P>
  <B>Software Platform</B>
  <P>
  OS version = 1.0
  <P>
  HTML version = 4.0
  <P>
  WML version = 1.0
  <P>
  Sound = ON
  <P>
  Images = Yes
  <P>
  <B>Email</B>
  <P>
  Language = English
  <P>
  ...
  <P>
  Some collections of properties and property values may be common to a particular
  component. For example: a specific model of a smart phone may come with a
  specific CPU, screen size and amount of memory by default. Gathering these
  "default" properties together as a distinct RDF resource makes it possible
  to independently retrieve and cache those properties. A collection of "default"
  properties is not mandatory, but it may improve network performance, especially
  the performance of relatively slow wireless networks.
  <P>
  Any RDF graph consists of nodes, arcs and leafs. Nodes are resources, arcs
  are properties and leafs are property values. An RDF graph based on the previous
  example that includes "Default" properties for each major component is relatively
  straightforward.
  <P>
  <IMG HEIGHT=432 WIDTH=528 SRC="CCPP-WD-IMG.gif" ALT="">
  <P>
  The introduction of "Defaults" makes the graph of each major component more
  of a simple tree than a table. In this example the major components are
  associated with the current network session. In this case, the network session
  is serving as the root of a tree that includes the trees of each major component.
  RDF was originally intended to describe metadata associated with documents
  or other objects that can be named via a URI. The closest thing to a "document"
  associated with a CC/PP is the current network session.
  <P>
  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.
  <P>
  The CC/PP is the encoding of profile information that needs to be shared
  between a client and a server, gateway or proxy. 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.
  <H3>
    <A NAME="31">3.1 Inline example</A>
  </H3>
  <P>
  Consider a more realistic example of inline encoding of a CC/PP for a
  hypothetical smart phone. This is an example of the type of information a
  phone might provide to a gateway/proxy/server. Note that we do not explicitly
  name the "current network session". Instead, the profiles of each major component
  is collected in a "Bag". This is probably not necessary since the document
  in question, the network session, is unlikely to contain additional RDF.
  <PRE>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:prf="http://www.w3.org/TR/WD-profile-vocabulary#"&gt;
&nbsp;&lt;rdf:Description about="HardwarePlatform"&gt;
&nbsp; &nbsp;&lt;prf:Defaults
&nbsp; &nbsp; Vendor="Nokia"
&nbsp; &nbsp; Model="2160"
&nbsp; &nbsp; Type="PDA"
&nbsp; &nbsp; ScreenSize="800x600x24"
&nbsp; &nbsp; CPU="PPC"
&nbsp; &nbsp; Keyboard="Yes"
&nbsp; &nbsp; Memory="16mB"
&nbsp; &nbsp; Bluetooth="YES"
&nbsp; &nbsp; Speaker="Yes" /&gt;
&nbsp; &lt;prf:Modifications
&nbsp; &nbsp; Memory="32mB" /&gt;
&nbsp;&lt;/rdf:Description&gt;
&nbsp;&lt;rdf:Description about="SoftwarePlatform"&gt;
&nbsp; &lt;prf:Defaults
&nbsp; &nbsp;OS="EPOC1.0"
&nbsp; &nbsp;HTMLVersion="4.0"
&nbsp; &nbsp;JavaScriptVersion="4.0"
&nbsp; &nbsp;WAPVersion="1.0"
&nbsp; &nbsp;WMLScript="1.0" /&gt;
&nbsp; &lt;prf:Modifications
&nbsp; &nbsp;Sound="Off"
&nbsp; &nbsp;Images="Off" /&gt;
&nbsp;&lt;/rdf:Description&gt;
&nbsp;&lt;rdf:Description about="EpocEmail1.0"&gt;
&nbsp; &nbsp;&lt;prf:Defaults
&nbsp; &nbsp;HTMLVersion="4.0" /&gt;
&nbsp;&lt;/rdf:Description&gt;
&nbsp; &lt;rdf:Description about="EpocCalendar1.0"&gt;
&nbsp; &lt;prf:Defaults
&nbsp; &nbsp;HTMLVersion="4.0" /&gt;
&nbsp;&lt;/rdf:Description&gt;
&nbsp; &lt;rdf:Description about="UserPreferences"&gt;
&nbsp;&lt;prf:Defaults
&nbsp; &nbsp; &nbsp; &nbsp; Language="English"/&gt;
&nbsp;&lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;

</PRE>
  <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.
  <P>
  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.
  <P>
  Delivering all of the CC/PP at one time, inline makes some simplifications
  possible. 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.
  <P>
  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. One strategy is compressed form of XML
  [<A HREF="#[TokenXML]">TokenXML</A>] and a complementary strategy is to use
  indirect references.
  <H3>
    <A NAME="32">3.2 Indirect References</A>
  </H3>
  <P>
  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).
  <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>-----------------------------------</TT> <BR>
  <PRE>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:prf="http://www.w3.org/TR/WD-profile-vocabulary#"&gt;
  &lt;rdf:Description about="HardwarePlatform"&gt;
      &lt;prf:Defaults&gt;
            &lt;rdf:li resource="http://www.nokia.com/profiles/2160"/&gt;
      &lt;/prf:Defaults&gt;
       &lt;prf:Modifications
            Memory="32mB"/&gt;
   &lt;/rdf:Description&gt;
   &lt;rdf:Description about="SoftwarePlatform"&gt;
     &lt;prf:Defaults&gt;
            &lt;rdf:li resource="http://www.symbian.com/profiles/pda"/&gt;
     &lt;/prf:Defaults&gt;
     &lt;prf:Modifications
            Sound="Off"
            Images="Off" /&gt;
   &lt;/rdf:Description&gt;
   &lt;rdf:Description about="EpocEmail"&gt;
&nbsp;&nbsp;  &nbsp;&lt;prf:Defaults&gt;
            &lt;rdf:li resource="http://www.symbian.com/epoc/profiles/epocemail" /&gt;
     &lt;/prf:Defaults&gt;
   &lt;/rdf:Description&gt;
&nbsp;  &lt;rdf:Description about="EpocCalendar"&gt;
&nbsp;&nbsp;&nbsp;  &lt;prf:Defaults&gt;
           &lt;rdf:li resource="http://www.symbian.com/epoc/profiles/epoccal"/&gt;
     &lt;/prf:Defaults&gt;
   &lt;/rdf:Description&gt;
&nbsp;  &lt;rdf:Description about="UserPreferences"&gt;
    &lt;prf:Defaults
     Language="English" /&gt;
&lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;
</PRE>
  <P>
  -----------------------------------------------------
  <P>
  Next, the profile provided by the hardware vendor.
  <P>
  ----------------------------------------------------- <BR>
  <PRE>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"&gt;
&lt;rdf:Description
Vendor="Nokia"
Model="2160"
Type="PDA"
ScreenSize="800x600x24"
CPU="PPC"
Keyboard="Yes"
Memory="16mB"
Bluetooth="YES"
Speaker="Yes" /&gt;
&lt;/rdf:RDF&gt;
</PRE>
  <P>
  -----------------------------------------------------
  <P>
  Finally, the profiles provided by the software platform and application vendors.
  <P>
  ----------------------------------------------------- <BR>
  <PRE>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"&gt;
&lt;rdf:Description
OS="EPOC1.0"
HTMLVersion="4.0"
JavaScriptVersion="4.0"
WAPVersion="1.0"
WMLScript="1.0" /&gt;
&lt;/rdf:RDF&gt;
<TT>-----------------------------------------------------------------------</TT>
</PRE>
  <PRE>
&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"&gt;
&lt;Description
&nbsp;&nbsp;&nbsp; Version="EpocEmail1.0"
&nbsp;&nbsp;&nbsp; HTMLVersion="4.0" /&gt;
&lt;/rdf:RDF&gt;
</PRE>
  <P>
  <TT>------------------------------------------------------------------------</TT>
  <PRE>
&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"&gt;
&lt;Description
&nbsp;&nbsp;&nbsp; Version="EpocCalendar1.0"
&nbsp;&nbsp;&nbsp; HTMLVersion="4.0" /&gt;
&lt;/rdf:RDF&gt;
</PRE>
  <P>
  <TT>-----------------------------------------------------</TT>
  <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 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.
  <H3>
    <A NAME="33">3.3 Runtime Changes</A>
  </H3>
  <P>
  It is worth noting again 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 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 a memory upgrade. We need to be able to override 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 beyond the scope of this document.
  <P>
  Our problem is to propogate changes to the current CC/PP to the
  server/gateway/proxy. 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:
  <P>
  &lt;?xml version="1.0"?&gt;
  <P>
  &lt;rdf:RDF
  <P>
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  <P>
  xmlns:prf="http://www.w3C.org/TR/WD-profile-vocabulary#"&gt;
  <P>
  &nbsp; &lt;Description about="SoftwarePlatform"
  <P>
  &nbsp;&nbsp;&nbsp; Sound="On" /&gt;
  <P>
  &lt;/rdf:RDF&gt;&nbsp;
  <P>
  Alternatively, the <TT>&lt;Modifications&gt;</TT> element could be used to
  communicate changes.
  <H2>
    <A NAME="4">4. Protocol considerations</A>
  </H2>
  <P>
  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 WSP (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.
  <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. 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.
  <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>
  New versions of HTTP such as HTTPng should be able to support the CC/PP framework
  without difficulty. HTTP 1.0 servers and proxies may not be able to handle
  CC/PPs. Clients need to be able to detect communication with old servers
  and adapt the protocol accordingly. HTTP 1.1, perhaps via the Mandatory/Optional
  Extension Framework should be able to support sessions and profiles. At the
  least, 1.1 proxy servers should pass requests that include CC/PPs on to servers
  in the hope that the servers will understand the requests. New versions of
  1.1 proxies and servers should be able to use CC/PPs.
  <P>
  This protocol discussion is not a specific proposal for HTTP or WSP. 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>
  Since the original writing of this document, a W3C Note has been produced,
  which describes how to use the HTTP 1.1 extension framework to implement
  a mechanism for communicating CC/PP profiles and profile differences. See
  the note, <A HREF="http://www.w3.org/TR/NOTE-CCPPexchange">CC/PP exchange
  protocol based on HTTP Extension Framework</A> <A HREF="# [Ohto]">[Ohto]</A>,
  for more information.
  <H2>
    <A NAME="5">5. Summary</A>
  </H2>
  <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. 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.
  <H2>
    <A NAME="References">References</A>
  </H2>
  <P>
  <A NAME="[Agent-attrib]">[Agent-attrib]</A>
  <A HREF="http://www.w3.org/TR/NOTE-agent-attributes">Client-Specific Web
  Services by Using User Agent Attributes. Tomihisa Kamada, Tomohiko Miyazaki.
  W3C Note.</A>
  <P>
  <A NAME="[CONNEG]">[CONNEG]</A>
  <A HREF="http://www.ietf.org/html.charters/conneg-charter.html">IETF working
  group on content negotiation</A>
  <P>
  <A NAME="[IMT-2000]">[IMT-2000]</A> <A HREF="http://www.imt-2000.com">Ericsson
  in Wideband Wireless Multimedia</A>.
  <P>
  <A NAME="[MIME]">[MIME]</A>
  <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="[Ohto]">[Ohto]
  </A><A HREF="http://www.w3.org/TR/NOTE-CCPPexchange">CC/PP exchange protocol
  based on HTTP Extension Framework</A>
  <P>
  <A NAME="[RDF]">[RDF]</A>
  <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]">[RDF-Schema]</A>
  <A HREF="http://www.w3.org/TR/WD-rdf-schema/">Resource Description Framework
  (RDF) Schema Specification. Brickley, D., Guha, R.V. , Layman, A., W3C Working
  Draft.</A>
  <P>
  <A NAME="[TokenXML]">[TokenXML]</A>
  <A HREF="http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WBXML-19990616.pdf">Binary
  XML Content Format Specification</A>
</BODY></HTML>