As we discussed today in the IPP meeting....
This message posted to the CONNEG IETF WG outlines some drafts on
capabilities exchange and negotiation in the context of mobile users.
The intent of the exchange of messages was to coordinate 3WC and IETF
CONNEG activities in this area.
This draft and the work of CONNEG in general might have some bearing on the
"ipp-collection-attr-syntax" drafts.
####################
>From: "Johan Hjelm" <hjelm@w3.org>
>Date: Thu, 8 Oct 1998 09:09:05 +0000
>Subject: Framework for capabilities and user preferences
>To: <ietf-medfree@imc.org>
>Organization: World Wide Web consortium
>Sender: owner-ietf-medfree@imc.org
>
>Dear All,
>please find enclosed a paper we have produced in the mobile access interest
>group of the
>W3C. It is a general framework for expressing user agent preferences in RDF.
>We look forward
>to your views and input.
>
>Johan
>--
>ERICSSONW3CW3CERICSSONW3CERICSSONW3CERICSSONW3CERICSSONW3CERICSS
>ONW3C
>
>
> mailto:hjelm@w3.org - http://www.w3.org/People/W3Cpeople.html#Hjelm
>
>
--=====================_150041==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ccpp-paper.html"
=0A
=0A =0A =0A =0A ==0AAuthor: =0ARewievers and co-authors:=0A =0AMo=
bile Access Interest Group User Agent Profile Definition group:=0A =0AWeb=
and TV interest group: Philip=
Hoscka,=0AW3C.=0A =0AIn this note we=
describe a method for using RDF, the Resource Description=0AFormat of the=
W3C, to create a general, yet extensible framework for describing=0Auser=
preferences and device capabilities. This information can be provided=0Aby=
the user to servers and content providers. The servers can use=
this=0Ainformation describing the user's preferences to customize the=
service or=0Acontent provided. The ability of RDF to reference=
profile information=0Avia URL:s assists in minimising the number of network=
transactions required=0Ato adapt content to a device, while the framework=
fits well into the current=0Aand future protocols being developed a the W3C=
and the WAP Forum.=0A =0A =0AA description of the=
user's capabilities and preferences=0Ais necessary but insufficient to=
provide a general content negotiation solution.=0AA general framework for=
content negotiation requires a means for describing=0Athe meta data or=
attributes and preferences of the user and his/hers/its=0Aagents, the=
attributes of the content and the rules for adapting content=0Ato the=
capapbilities and preferences of the user. The current mechanisms,=0Asuch=
as accept headers and <alt> tags, are somewhat limited.=
Future=0Aservices will be more demanding. For example: the content might be=
authored=0Ain multiple languages with different levels of confidence in the=
translation=0Aand the user might be able to understand multiple languages=
with different=0Alevels of proficiency. To complete the negotiation some=
rule is needed for=0Aselecting a version of the document based on weighing=
the user's proficiency=0Ain different languages against the quality of the=
documents various=0Atranslations.=0A =0ATh=
is proposal focuses on the design of a user agent=0Aprofile service based on=
XML/RDF. RDF, the Resource Description Format=0A[ =0ASome potentially=
complex negotiation may have to take=0Aplace between the content or the=
server of the content and the user of the=0Acontent. For example: the=
content might be authored in multiple languages=0Awith different levels of=
confidence in the translation and the user might=0Abe able to understand=
multiple languages with different levels of proficiency.=0AThough we hope=
that the use of RDF to encode the metadata describing the=0Acontent and the=
user's preferences will facilitate the development of solutions=0Ato these=
kinds of complex negotiations, the implementation of appropriate=0Arules=
for the negotiation is left to application developers.=0A =0A =0AIn a wireless network, bandwidth is=
also managed differently from wireline=0Atechnologies. Wireless networks=
have also traditionally been prone to higher=0Alatencies than wireline=
networks, due to the longer setup time for connections.=0AThis restriction=
is disappearing in packet oriented networks, such as CDPD=0Aand CDMA, and=
with packet oriented bearer technologies such as GPRS and EDGE.=0AThe=
bandwidth limitation implies that the volume and number of=
network=0Atransactions should be limited as far as possible.=0A =0AProtoc=
ol design is beyond the scope of this group, however, the use of CC/PPs=0Ado=
es have some impacts on web protocols and in this section some of=
those=0Aissues are discussed. The design and implementation of HTTP-NG is=
being actively=0Acarried out by another group. In this section we limit our=
discussion to=0Asome of the issues that many need to be considered in=
HTTPng or similar=0Aprotocols:=0A =0AThe goal of this work is to:=0A =0AThe data model for the capability and=
preferences profile is similar to=0Aa table of=
tables. Each individual table roughly=0Acompares to a significant=
hardware or software component. The primary=0Agoal is to be able to=
describe the desired table of tables in an unambiguous=0Aand inter operable=
fashion. Secondary goals include general applicability=0Aand good=
performance.=0A =0AIn most=
documents on 3rd generation networks, scenarios are presented where=0Ausers=
will want to assert several preferential=0Afactors[ =0AThey will=
also want to assert hardware platform attributes, like:=0A =0AWe also expect them to want to assert=
software defined variables, such as:=0A =0A=
It is interesting to note that metadata (capabilities and preferences)=
associated=0Awith the device, the software used to access the web and the=
user of the=0Adevice could originate from different sources created at=
different times.=0AThe hardware vendor might have profile information=
available for its products,=0Athe software vendor might supply a default=
profile, and the user's preferences=0Amight apply across multiple=
applications (preferred language) or change during=0Aa session (sound=
on/off). On the other hand, we don't want this to get out=0Aof hand. If it=
is too complex people won't use it and if it too slow people=0Awon't use=
it. The challenge is to provide an efficient mechanism for=0Acommunicating=
the profiles for constrained devices, such as smart phones,=0Ausing slow=
networks, such as GSM SMS.=0A =0AThe CC/PP=
proposal describes an interoperable encoding for capabilities=
and=0Apreferences of user agents, specifically web browsers.=0A =0AThe data model for a=
CC/PP is a table of tables. In=0Athe simplest form=
each table in the CC/PP is just a collection of RDF statements=0Awith=
simple, atomic properties. One can think of these tables as=
being=0Aconstructed from default settings, persistent local changes and=
temporary=0Achanges. Default settings might be properties defined by the=
vendor. In the=0Acase of hardware the vendor often has a very good idea of=
the properties=0Aof any given model of product. However, the current owner=
of the product=0Amay be able to add options, such as memory or persistent=
store or additional=0AI/O devices that add new properties or change the=
values of some original=0Aproperties. These would be persistent local=
changes. An example of a temporary=0Achange would be turning sound on or=
off.=0A =0AFrom the point of view of any=
particular network=0Atransaction the only property or capability=
information that is important=0Ais whatever is "current". The=
network transaction does not care=0Aabout the differences between defaults=
or persistent local changes, it only=0Acares about the capabilities and=
preferences that apply to the current network=0Atransaction. Because this=
information may originate from multiple sources=0Aand because different=
parts of the capability profile may be differentially=0Acached, the various=
components must be explicitly described in the network=0Atransaction.=0A =
=0AIt is worth noting that the persistent encoding=
of=0Aprofile information and the encoding for the purposes of=
interoperability=0A(communication) need not be the same. In=
this document we consider=0Athe use of XML/RDF as the interoperability=
encoding. Persistent storage of=0Aprofile information is left to the=
individual applications.=0A =0A RDF processing does not implicitly=
preserve order. Consequently=0Athe value of a=
property cannot be changed by simply=0Ahaving another statement assigning a=
different value to a property with the=0Asame name. Instead of=
overriding the previous value of the property,=0Ayou get two properties=
with the same name and two different values. RDF=0Aprocessing does not=
guarantee preservation of declaration order so there=0Ais no way to use=
declaration order to define a precedence relation. To get=0Athe effect of=
overriding the properties of a platforms defaults, the platform=0Aattribute=
s are aggragated via a "description block". This makes it=0Apossible=
for an application to define a precedence=0Arelatio=
n between platform defaults and user specified overrides.=0A =0AConsider a simple example of inline=
encoding for a hypothetical smart phone:=0A =0A<RDF=
xmlns=3D"http://www.w3C.org/TR/WD-rdf-syntax"=
prefix=3D"RDF"=0A =0A<Description=
ID=3D"hardware platform">=0A =0A<Descripti=
on ID=3D"software platform">=0A =0A<Descripti=
on ID=3D"EpocEmail"> =0A =0A =0AThis sample=
profile is a collection of the capabilities and preferences=0Aassociated=
with either a user or the hardware platform or a software component.=0AEach=
collection of capabilities and preferences are organized within=
a=0Adescription block. These description blocks may contain subordinate=
description=0Ablocks to describe default attributes or other collections of=
attributes.=0AOne new namespace "PRF" was=
introduced which contains=0Athe vocabulary used for all attributes and=
preferences. The PRF namespace=0Ais intended to provide a well defined=
collection of attributes of general=0Autility. There is nothing that=
prevents the use of multiple namespaces. This=0Amight be useful to either=
define experimental or non-standard attributes=0Aor to define application=
specific capabilities and preferences.=0A =0ADelivering all of the=
CC/PP at one time, inline simplifies some things. If=0Athe user has=
overridden some default property, then there is no reason to=0Asend the=
default - all that is needed is to send the current value for=
that=0Aattribute. In the example above, there is no reason to send the=
hardware=0Aplatform's default setting of "Memory=3D16mb" since the user has=
upgraded the=0Amemory to 32mb.=0A =0AThe significance of an attribute is=
generally limited to the component it=0Ais describing. For example, each=
software application can define a value=0Afor a "Version" attribute. This=
indicates the version of the particular=0Aapplication being described. In=
general, side effects that extend beyond=0Athe bounds of a particular=
component are not defined in this document. The=0Arelationship between=
components is system and application dependent. For=0Aexample, if the=
"Sound" attribute is defined to be "Off" in the hardware=0Aplatform but=
"On" for email, is voice mail delivered (audibly) or not? What=0Ashould=
happen if "Sound" is "On" at hardware and email but "Off" for=
Calendar?=0A =0AThe major disadvantage of this for =0AInst=
ead of enumerating each set of attributes, a=
remote=0Areference can be used to name a collection of attributes such as=
the hardware=0Aplatform defaults. This has the advantage of enabling=
the separate=0Afetching and caching of functional subsets. This might be=
very nice if the=0Alink between the gateway or the proxy and the client=
agent was slow and the=0Alink between the gateway or proxy and the site=
named by the remote reference=0Awas fast - a typical case when the user=
agent is a smart phone. Another advantage=0Ais the simplification of the=
development of different vocabularies for hardware=0Avendors and software=
vendors (assuming this is a good thing).=0A =0AThe following example uses=
indirect references. First the profile provided=0Aby the user agent. It=
refers to default profiles provided by the hardware=0Aand software platform=
vendors:=0A =0A<RDF xmlns=3D"http://www.w3C.org/TR/WD-rdf-syntax"=
prefix=3D"RDF"=0A =0A<Description=
ID=3D"hardware platform">=0A =0A<Descripti=
on ID=3D"software platform">=0A =0A<Descripti=
on ID=3D"EpocEmail"> =0A =0A =0ANext, the=
profile provided by the hardware vendor.=0A =0A<RDF=
xmlns=3D"http://www.w3C.org/TR/WD-rdf-syntax"=
prefix=3D"RDF"=0A =0A<Description=
ID=3D"hardware=
platform">=0A =0AFinally, the profiles provided by the software=
platform and application vendors.=0A =0A<RDF=
xmlns=3D"http://www.w3C.org/TR/WD-rdf-syntax"=
prefix=3D"RDF"=0A =0A<Description=
ID=3D"software=
platform">=0A =0A-------------=
----------------------------------------------------------=0A =0A<Description=
ID=3D"EpocEmail">=0A =0A--------------------------=
----------------------------------------------=0A =0AAll we did in the second example was group=
different collections of default=0Aattributes together in such a way that=
they could be named by a=0AURL. Since the hardware=
and software platform default=0Aprofiles were independently described using=
a URL, they can be separately=0Afetched and cached. When an application in=
the server/gateway/proxy uses=0ARDF to process the CC/PP it may encounter=
attrributes with default values=0Aand user specified values. It is up the=
application to enforce the rule that=0Auser specified attributes over ride=
default values. RDF does not provide=0Aa convenient mechanism for=
implementing that rule.=0A =0A4.3 Runtime=
Changes=0A =0AIt is worth noting that the information we are=
most concerned with is the=0Acurrent profile. Default properties=
might have some importance, for=0Aexample, they may be worth caching=
independently of any particular session=0Aor user. However, the key is for=
the client and the server/gateway/proxy=0Ato have a consistent view of the=
current profile.=0A =0AIt is important to be able to add to and=
modify attributes associated=0Awith the current CC/PP. We need to be=
able to modify=0Athe value of certain attributes,=
such as turning sound on and off and we=0Aneed to make persistent changes=
to reflect things like hardware upgrades.=0AFor example, a third party=
memory upgrade. We need to be able to modify the=0Adefault profile provided=
by the vendor. However, we only need to concern=0Aourselves with=
changes to the current profile. Reflecting changes to preferences=0Aor=
capabilities in persistent storage is out of scope.=0A =0AOne solu =0A<RDF=
xmlns=3D"http://www.w3C.org/TR/WD-rdf-syntax"=
prefix=3D"RDF"=0A =0A<Description=
ID=3D"software=
platform">=0A =0AWhen used in the=
context of a web browsing application,=0Aa CC/PP should be associated with=
a notion of a current session rather=0Athan a user or a node. HTTP=
and WTP (the WAP session protocol) both define =0Adifferent session=
semantics. The client, server and and gateways and proxies=0Amay already=
have their own, well defined notions of what constitutes a connection=0Aor=
a session. Our protocol strategy is to send as little information as=
possible=0Aand if anyone is missing something, they have to ask for it. If=
there is=0Agood reason to believe that someone is going to ask for a=
profile, the client=0Acan elect to send the most efficient form of the=
profile that makes=0Asense.=0A =0AConsider the following possible=
interaction between a server and a client.=0AWhen the Client begins a=
session it sends a minimal profile using as much=0Aindirection as=
possible. If the server/gateway/proxy does not have=0Aa CC/PP for=
this session, then it asks for one. When=0Aa =
profile is sent the client tries a minimal form, i.e., it uses=0Aas=
much indirection as possible and only names the non default attributes=0Aof=
the profile. The server/gateway/proxy can try to fill in the=
profile=0Ausing the indirect HTTP references (which may be independently=
cached). If=0Aany of these fail, a request for additional data can be sent=
to the user=0Awhich can reply with a fully enumerated profile. If the=
client changes=0Athe value of an attribute, such as turning sound off, only=
that change needs=0Ato be sent.=0A =0AIt is likely that servers and=
gateways/proxies will be concerned with different=0Apreferences. For=
example, the server may need to know which language the=0Auser prefers and=
the gateway may have responsibility to trim images to 8=0Abits of color (to=
save bandwidth). However, the exact use of profile information=0Aby each=
server/gateway/proxy is hard to predict. Therefore gateways/proxies=0Ashoul=
d forward all profile information to the server. Any requests for=
profile=0Ainformation that the gateway/proxy cannot satisfy should be=
forwarded to=0Athe client.=0A =0AThe ability to compose a profile from=
sources provided by third parties at=0Arun-time exposes the system to a new=
type of attack. For example, if the=0AURL that named the hardware default=
platform defaults were to be compromised=0Avia an attack on DNS it would be=
possible to load incorrect profile information.=0AIf cached within a=
server/gateway/proxy this could be a serious denial of=0Aservice attack. If=
this is a serious enough problem it may be worth adding=0Adigital=
signatures to the URLs used to refer to profile components.=0A =0AThis=
protocol discussion is not a specific proposal for HTTP or WTP. Its=0Ainten=
t is merely to illustrate how the design allows us to exploit=
the=0Acachability of both the current session state and the default=
profiles.=0A =0A6. Summary=0A =0AIn this=
document, we have described a proposal for the use of XML/RDF to=0Adescribe=
user preferences and the capabilities of the device and software=0Aused to=
access the Web. Encodings of hypothetical user profiles =0Awere=
used to illustrate some of the benefits of RDF. Some of the=
possible=0Aramifications for Web protocol design were=
discussed.=0A =0A7. References=0A =0A =0A =0A[MIME]=0A =0A=
[RDF]=0A =0A[RDF-Schema]=0A
=0A 1. Abstract=0A
=0A=0A 2. Introduction=0A
=0A=0A 2.1 Protocol=
Considerations=0A
=0A=0A
=0A=0A 2.2 Goals of this=
work=0A
=0A=0A
=0A=0A 3. Meta data and profiles=0A
=0A=0A
=0A=0A
=0A=0A
=0A=0A 4. Composite=
Capability/Preferences Profiles (CC/PP)=0A
=0A=0A =
4.1 Inline example=0A
=0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A =
<Description=
ID=3D"defaults">=0A
=0A &=
nbsp; <PRF:Vendor=3D"Nokia"=0A/>=
=0A =
<PRF:Model=3D"2160"=0A/>=
=0A <PRF:Type=3D"PDA"=
/>=0A
=0A =
<PRF:ScreenSize=3D"800x600x24"=0A/>=
=0A <PRF:CPU=3D"PPC"=
/>=0A
=0A =
<PRF:Keyboard=3D"Yes"=0A/>=
=0A =
<PRF:Speaker=3D"Yes"=0A/>
=0A =
</Description>=0A
=0A =
<PRF:Memory=3D"32mb"=
/>=0A
=0A</Description>=0A
=0A =
<Description=
ID=3D"defaults">=0A
=0A &=
nbsp; <PRF:OS=3D"EPOC1.0"=0A/>=
=0A =
<PRF:HTMLVersion=3D"4.0"=0A/>=
=0A =
<PRF:JavaScriptVersion=3D"4.0"=0A/>=
=0A =
<PRF:WAPVersion=3D"1.0"=0A/>=
=0A =
<PRF:WMLScriptVersion=3D"1.0"=0A/>
=0A =
</Description>=0A
=0A =
<PRF:Sound=3D"Off" />=0A
=0A =
<PRF:Images=3D"Off"=
/>=0A
=0A</Description>=0A
=0A <Description=
ID=3D"defaults">=0A
=0A &=
nbsp; <PRF:Version=3D"EpocEmail1.0"=0A/>=
=0A =
<PRF:HTMLVersion=3D"4.0"=0A/>
=0A =
</Description>=0A
=0A</Description>=0A
=0A =
<Description=
ID=3D"defaults">=0A
=0A &=
nbsp;=0A<PRF:Version=3D"EpocCalendar1.0"=
/>=0A
=0A =
<PRF:HTMLVersion=3D"4.0"=0A/>
=0A =
</Description>=0A
=0A</Description>=0A
=0A =
<PRF:Language=3D"English"=
/>=0A
=0A</Description>=0A=0A 4.2 Indirect References=0A
=0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A =
<Description=
ID=3D"defaults">=0A
=0A &=
nbsp; <PRF:HardwareDefaults =3D=0A"http://www.nokia.com/profiles/2160"=
/>
=0A =
</Description>=0A
=0A =
<PRF:Memory=3D"32mb"=
/>=0A
=0A</Description>=0A
=0A =
<Description=
ID=3D"defaults">=0A
=0A &=
nbsp;=0A<PRF:SoftwarePlatformDefaults =3D=
"http://www.symbian.com/epoc/profiles/PDA"=0A/>=
=0A =
</Description>=0A
=0A =
<PRF:Sound=3D"Off" />=0A
=0A =
<PRF:Images=3D"Off"=
/>=0A
=0A</Description>=0A
=0A <Description=
ID=3D"defaults">=0A
=0A &=
nbsp;=0A<PRF:SoftwarePlatformDefaults=
=3D=0A"http://www.symbian.com/epoc/profiles/epocemail"=
/>=0A
=0A =
</Description>=0A
=0A</Description>=0A
=0A =
<Description=
ID=3D"defaults">=0A
=0A &=
nbsp;=0A<PRF:SoftwarePlatformDefaults =3D=
"http://www.symbian.com/epoc/profiles/epoccal"=0A/>=
=0A =
</Description>=0A
=0A</Description>=0A
=0A =
<PRF:Language=3D"English"=
/>=0A
=0A</Description>=0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A =
<PRF:Vendor=3D"Nokia"=0A/>=
=0A =
<PRF:Model=3D"2160"=0A/>=
=0A <PRF:Type=3D"PDA"=
/>=0A
=0A =
<PRF:ScreenSize=3D"800x600x24"=0A/>=
=0A <PRF:CPU=3D"PPC"=
/>=0A
=0A =
<PRF:Keyboard=3D"Yes"=0A/>=
=0A =
<PRF:Speaker=3D"Yes"=0A/>=
=0A =
<PRF:Memory=3D"16mb"=0A/>
=0A</Description>=
=0A =0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A &=
nbsp; =0A<PRF:OS=3D"EPOC1.0"=
/>=0A
=0A &nb=
sp; =0A<PRF:HTMLVersion=3D"4.0"=
/>=0A
=0A &nb=
sp; =0A<PRF:JavaScriptVersion=3D"4.0"=
/>=0A
=0A &nb=
sp; =0A<PRF:WAPVersion=3D"1.0"=
/>=0A
=0A &nb=
sp; =0A<PRF:WMLScriptVersion=3D"1.0"=
/>=0A
=0A</Description>=0A
=0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A =
<PRF:Version=3D"EpocEmail1.0"=0A/>=
=0A =
<PRF:HTMLVersion=3D"4.0"=0A/>=
=0A</Description>=0A
=0A<RDF=
xmlns=3D"http://www.w3C.org/TR/WD-rdf-syntax"=
prefix=3D"RDF"=0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A<Description=
ID=3D"EpocCalendar">=0A
=0A &nb=
sp; =0A<PRF:Version=3D"EpocCalendar1.0"=
/>=0A
=0A =
<PRF:HTMLVersion=3D"4.0"=0A/>
=0A</Description>
=0A =0A
=0A =0Axmlns:PRF=3D"http://www.w3C=
.org/TR/WD-profile-vocabulary">=0A
=0A &=
nbsp; =0A<PRF:Sound=3D"On" />=
=0A<Description>
=0A =0A=0A 5. Protocol=
considerations=0A
=0A