W3C home > Mailing lists > Public > www-mobile@w3.org > August 2001

Forward: [Moderator Action] UAPROF issues

From: Kazuhiro Kitagawa <kaz@w3.org>
Date: Thu, 30 Aug 2001 14:43:23 +0900
Message-ID: <nn6u1yqm7b8.wl@toro.w3.mag.keio.ac.jp.w3.mag.keio.ac.jp>
To: www-mobile@w3.org

attached mail follows:


Folks,

We have identified a set of problems and open issues with UAPROF
and in particular with its transport mechanism. We believe these
issues must be addressed as soon as possible to make UAPROF (and
in general CCPP-based) implementations feasible in the near
future.

As the identified points should concern both UAPROF and CCPP this
mail is sent to the mailing lists of both standardization bodies.

Kind regards,
Andreas Schade
IBM Research Division
Zurich Research Laboratory
CH-8803 Rueschlikon
SWITZERLAND


Issues with specification of "User Agent Profile Transport"
===========================================================

This document summarizes open issues and ambiguities related to
the UAPROF transport mechanism is its present form. Its purpose
is to create broader awareness of these problems in order to turn
UAPROF and related documents into a set of sound specifications
that can actually serve as a standard.

The issues identified in this document are divided into three groups
and relate to the transport mechanism in general, to the W-HTTP
specification, and to profile matching. The syntactic and semantic
ambiguities allowed by XML namespaces, RDF syntax, and CC-PP semantics
should be eliminated by the UAProf specification by restricting
respectively narrowing the usage of these underlying mechanisms.

The below comments apply to the UAProf document WAP-248 WAG UAProf
(May 30, 2001) and the currently known versions of XML, XML
Namespaces, RDF model & syntax specification, CC-PP, HTTP Extension
Framework, CC-PP exchange protocol based on HTTP Extension Framework.

A. Confusion regarding the transport syntax
+++++++++++++++++++++++++++++++++++++++++++

(as seen on the www-mobile@w3.org reflector from cafe_babe@hotmail.com)

The transport syntax used by the WAP gateway [or HTTP proxy] towards
the origin server defines what an enhancing proxy or origin server
needs to be able to understand if it wants to exploit UAProf
information. The specification remains ambiguous regarding which
mechanism is used by the WAP gateway, as illustrated by the following
citations:

Section 9 introductory paragraphs:

"... A WAP gateway MAY use CC/PPex over HTTPex, but it is not
recommended. ..."

"..., however, when the WAP gateway converts a WSP request into an
HTTP request it MUST use the transport specified in section 9.1. ..."
(which is W-HTTP)

Section 9.2.3.3. Header Translation between CC/PP-WSP and HTTP:

"The WAP gateway MUST forward WSP requests as HTTP 1.1 requests
[WAE]. In forwarding the request, the gateway MUST forward all
CC/PP-WSP headers (defined in Section 9.2.2 and resolved at the
gateway according to the rules of Section 9.2.3.2) as CC/PP-HTTP
headers (defined in [CCPPEx]) according to these rules: ..."

The second citation suggests the use of W-HTTP whereas the third
mandates the use of CC/PP-HTTP headers as defined in CCPPEx. When
using CCPPEx, respectively HTTPExt it is unclear whether uniquely
defined header field names (such as "profile", "profile-diff") are to
be used or whether namespaces with header extensions are to be used
(i.e. "profile-99", "profile-diff-99"). Although processing software
can be engineered to deal with all of the above header identification
schemes (i.e. distinct reserved "x-wap-...", HTTPExt with uniquely
defined header field names, HTTPExt with header extensions) it appears
as an overkill.

B. Specification of W-HTTP incomplete
+++++++++++++++++++++++++++++++++++++

The specification is incomplete or at least remains obscure regarding
both syntactical and semantical details.

Section 9.1 introductory paragraph:

"... The defined mechanism provides a functional equivalent for the
CC/PP exchange protocol [CCPPex] but the definition of the syntax and
semantics of the transport remains in this specification. ..."

This suggests that the specification of W-HTTP is NOT based on CC/PP
exchange protocol specification, but rather is self-contained. This
leaves open a number of issues:

B.1. Computation of MD5 digest
------------------------------

The XML document containing the profile subset is carried in the
field-body of a HTTP/1.1 header field "x-wap-profile-diff: 1; <?xml
.../>". This field-body can be "folded" onto multiple lines and
HTTP/1.1 proxies such as a caching proxy is free to modify this
"folding" regarding the usage of linear-white-space without changing
the semantics of the field value. Unless special care is taken, such
modifications will break the MD5 digest value.  While CCPPex at least
mentions the need for a canonical representation of the XML document,
the present specification does not address this problem at all. It
does remain unclear, how the MD5 digest is to be computed and how
linear-white-space is to be treated in this computation.

The specification requires a canonical format for XML documents
embedded in HTTP headers. This canonical format MUST not be based on a
DOM based scheme (such as DOMHASH [RFC2803]) to avoid forcing proxies
to process the HTTP header values into DOM data structures.

B.2. Syntax and resolution of profile subsets
---------------------------------------------

The "x-wap-profile" header can contain a set of URIs and profile diff
references. Each URI is supposed to identify a profile fragment that
is to be augmented by a set of profile diffs, and the resulting
profile information must be constructed by resolving the URI's and
applying the modifications specified in the "x-wap-profile-diff"
headers to the retrieved profile fragments. Unfortunately, the
standard is imprecise in its description of this process and fails to
address the following questions:

1. What exactly is the profile document that is obtained when resolving
   a "x-wap-profile" URI? Is it a profile containing a collection of
   components or rather a single component of a particular type? (If it is
   a single component, does it start with the rdf:Description or with a
   prf:component tag?)

   We also suggest requiring typing information to be MANDATORY within
   CC-PP components, generally labelled "prf:component" (Evidently, we
   also want to require the unique and pervasive usage of XML
   namespace tags "prf" and "rdf" to identify the CC-PP respectively
   UAProf namespaces!) Furthermore, the position of the "rdf:type"
   element within the "prf:component" element should be fixed
   (i.e. always the first child element).

2. Regardless of what the answer to question 1 is, further problems arise
   if a component of some type occurs more than once. The standard does
   not say explicitly if such a situation can occur or not. If so, how does
   the profile resolution process work? Does it ignore all components of
   a particular type if a component description of this type has already
been
   processed, or does it collate the property values by applying the
resolution
   policies. The latter seems(!) to be the intended case since the
resolution
   policy is not used at all when actual and default values are of a
component
   are merged.

3. In the case of collating property values specified in multiple component
   fragments, what is the resulting component id? Can all these component
   fragments contain default references, and if so, how are they processed?
   Does the resolution process observe only the first default reference
   and discard all others, or does it try to collate and merge default
   property values using the resolution policies? And last but not least,
   can defaults references be nested, i.e. can a component contain a
default
   URI which refers to a component which in turn contains a default
reference?

4. What exactly is the syntax of the XML part in a "profile-diff-desc"
   contained in the value of an "x-wap-profile-diff" header? This is
   similar to question 1 for the "x-wap-profile hader". Is it a profile
   fragment possibly containing multiple components or just a single
   component fragment?

5. Regardless of question 4, can diff fragments contain default references?
   If so, how are they applied to profiles? Does the resoultion process
    (a1) merge actual property values and defaults of the original profile,
    (b1) merge actual property values and defaults of the diff profile, and
    (c1) finally merge the results of step (a1) and (b1) observing the
         resolution policies?
   Or does it rather
    (a2) merge the defaults of the original and the defaults of the diff
         fragment (observing the resolution policies),
    (b2) merge the actual values of the original and of the diff fragment
         (observing the resolution policies), and
    (c2) finally merge the results of step (a2) and (b2)?

It is believed that the present specification leaves the implementor
too many options leading to non-predictable results. Furthermore, the
syntactic ambiguities of RDF as well as the potenial abuse of XML
namespaces (which can be redefined within different XML element
scopes) makes automated processing of UAProf information overly
complex without providing augmented capabilities.

B.3. Use of "x-wap-profile-warning" header
------------------------------------------

Imagine a situation where a request passes through some intermediate
enhancing proxy prior to reaching the origin server. The origin server
supports UAProf and selects or generates the content returned in the
response adding the appropriate warning-code (201 or 202) in the
"x-wap-profile-warning" header field. The intermediate proxy also
supports UAProf and transcodes parts of the content assembled by the
origin server, which requires him to set the warning-code to 203. Will
the proxy add a second x-wap-profile-warning header? If not, what is
the value that the mobile client will see?

C. Profile Matching
+++++++++++++++++++

Profile matching is one usage of UAProf advocated in the context of
WAP Push, where the push initiator can require a certain profile to be
satisfied by the target device. Note however that the behaviour of the
push-proxy gateway remains underspecified as profile matching is
currently not defined, nor is the behaviour of a PPG in case of
profile mis-matching addressed.


1. Is the set of allowed values for all properties infinite? For example,
   is an arbitrary literal a correct value for a property of the type
   literal)? Or are there some properties with the constraint that a
   valid value must be an element of a subset of all values matching the
   property type. For example, can numeric properties have only values of
   a certain range? Is there a finite set of values for properties of type
   literal/dimension?

2. Many property values are literals. The specification merely names
   examples for these literals rather than providing a final enumeration
   of possible values with attached semantics.

   Examples:

   "HardwarePlatform/Keyboard"

   How should an origin server be able to use such attributes., if one
   profile describes a keyboard as "101" and the other one describes it
   as "AT keyboard" and yet another one as "ATKEYBOARD". I.e. the
   spelling rules for literal values are insufficiently precise for
   literal value matching (CC-PP, UAProf deficiencies)

   "SoftwarePlatform/VideoInputEncoder"

   How about "MPEG-1" versus "MPEG_1" versus "MPEG 1" versus "MPEG1"
   versus your favorite choice of spelling? The same for "H.261",
   "MPEG-4", "H.263", etc.?

   What about punctuation rules, white space handling and case
   sentitivity? The "culprits" reside in the CC/PP and UAProf specs.
   The solution appears to be exhaustive enumeration of the various
   legal literal values or precise lexical rules for literal tokens.

   The list of examples can easily be extended with the following
   attributes: BluetoothProfile, CPU, Model, AudioInputEncoder,
   JavaPlatform, JVMVersion, OSName, OSVendor, RecipientAppAgent,
   CurrentBearerService, BrowserName.

3. What is the metrics to be used when matching property values of type
   Dimension (PixelAspectRatio, ScreenSize, ScreenSizeChar)?


In summary, we note that the UAProf specification, based on diverse
other, often ambiguous, standards does currently not lend itself for
efficient and concise implementation. In particular, we have
high-lighted issues of transport syntax, profile syntax and
resolution, and profile matching. The noticeable hesitation within the
WAP Forum regarding actual usage of UAProf leads us to the belief that
remedy is required. Mandating UAProf within the m-services framework
yields the impression of an ill-thought usage of immature technology.

Authors:
Binding Carl (cbd@zurich.ibm.com)
Hermann Reto (rhe@zurich.ibm.com)
Schade Andreas (san@zurich.ibm.com)
IBM Research Division
Zurich Research Laboratory
CH-8803 Rueschlikon
SWITZERLAND
Received on Thursday, 30 August 2001 01:44:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 13:00:00 GMT