Re: Forward: [Moderator Action] UAPROF issues

Unfortunately, the CC/PP working group was not originally chartered to do
protocol work. We intend to submit a new charter allowing us to do so, and your
comments are most helpful in that regard.

Regarding the matching of attributes, we did leave that out of the
specification, the numbers of values for the properties you mention would in
principle be ifinite, and the literals can only be matched on a "exist/not
exist" basis. The metrics for the numeric entities are not metrics, but
literals, since RDF does not have data types other than strings (again, in
principle). It seems to me that some of your issues stem from thinking about
RDF in an XML-schemalike way, and that is not currently possible. The work in
the RDF Core working group may make some of that thinking workable, however.
But this may be my personal impression.

Matching has worked fine in several implementations, but you can not do it in
the way I believe you think. We have also intentionally not discussed matching
in the CC/PP specification, since this would be based on heuristics in the
implementation.

Johan

Kazuhiro Kitagawa wrote:

> Subject: [Moderator Action] UAPROF issues
> Date: Wed, 29 Aug 2001 05:57:22 -0400 (EDT)
> From: "Andreas Schade/Zurich/IBM" <san@zurich.ibm.com>
> To: WAP-UAPROF@MAIL.WAPFORUM.ORG, www-mobile@w3.org
> CC: "Carl Binding/Zurich/IBM" <cbd@zurich.ibm.com>,
>      "Reto Hermann/Zurich/IBM" <rhe@zurich.ibm.com>
>
> 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

--
++++++++++++++++++++++++++++++++++++
  Johan Hjelm, Senior Specialist
     Ericsson Research Japan

  Read more about my recent book
http://www.wireless-information.net
************************************