Liaison statement
OMA LS 0051 (PAG) Proposing Solution to XCAP Issues

State Posted
Posted Date 2005-10-31
From Group OMA
From Contact Dean Willis
To Group simple
To Contacts Robert Sparks
Hisham Khartabil
CcTed Hardie
Scott Hollenbeck
Response Contact Lu Chang
Jaekown Oh
Technical Contact Lu Chang
Jaekown Oh
Purpose For action
Deadline 2005-11-12 Action Taken
Attachments OMA-LS_0051-Proposing-Solution-to-XCAP-Issues-20051018-A.doc
1       Overview

We are seeking your help in resolving the following issues OMA PAG encounters
while implementing XCAP: namespace binding and element insertion.

OMA PAG kindly requests that IETF investigate the presented problems and
proposed solutions in a timely manner so that these issues can be quickly
resolved and XDM Specifications can be stabilized and ready for certification.

OMA PAG kindly requests IETF informing us the result of their investigation.

2       Issue 1: Namespace Binding

2.1     Problem Statement

During OMA POC and XDM IOP, the following problems were reported:

(G1) Namespace (NS) binding for XML fragments sent between XDM clients and

(G2) XML documents in XDM servers cluttered with local namespace declarations

In OMA PAG internal discussions, it is noted that considering the nature of
scarce radio resources in wireless domain, it is essential that an XCAP
transaction should be accomplished without multiple queries and all XCAP
queries are constructed in such a way so as to minimize their lengths. As a
result, the following optimization goal should also be considered:

(G3) Optimize XCAP queries, i.e. minimizing query length and reducing needs to
have additional transactions prior to a GET or PUT

3       Issue 2: Element Insertion

3.1     Problem Statement

It is identified that there is difficulty in current XCAP to insert elements in
a sequence.

XCAP-07 Section 8.2.3 says,

“….If the PUT request is for an element, the server inserts the content
   of the request body as a new child element of the parent element
   selected in Section 8.2.1.  The insertion is done such that, the
   request URI, when evaluated, would now point to the element which was
   inserted.  If the target selector is defined by a by-name or by-attr
   production (in other words, there is no position indicated) the
   server MUST insert the element after any other siblings.  If a
   position is indicated, the server MUST insert the element so that it
   is the position-th element amongst all siblings whose name matches
   NameorAny. “

This text is not clear in that;

ï‚Ÿ     The meaning of 'siblings' in element by-name or by-attribute case is
confusing. It could be interpreted either as all elements under the same parent
element, or as elements under the same parent element whose name matches

ï‚Ÿ     It is not described how to insert an element when there is no sibling
whose name matches NameorAny. The above ambiguities cause the following
problems for schema validation:

ï‚Ÿ     When the element insertion request is made, the element can be inserted
either after the siblings whose name matches NameorAny or after the siblings
under the same parent elements.

ï‚Ÿ     When the element insertion request is made against the instance
document that does not contain sibling with same NameorAny, the XCAP Server
behaviour is undefined. This problem applies to any element with or without

As described in section 7.4 in XCAP-07, it is noted that the positional
insertion can ease the above-mentioned problems. However, it is still
problematic if there is no existing element with same NameorAny.

Other Consideration and Recommendation:

Another issue is the unique identification those element without attribute yet
with multiple occurance.

Although it is recommended to design schema such that an element should have
attribute for unique element identification, there could exist scenarios that
elements are defined without such attribute. An example of such case is the
previous common-policy-04 schema design where multiple occurrence of <id>
element without any attribute was allowed under <identity> element. The latest
common-policy-05 schema has revised this but, it seems such scenarios could
still happen in the future.

4       Requested Action(s)

•     OMA PAG WG kindly asks IETF(SIMPLE) to consider the presented problems.
 OMA PAG would appreciate IETF informing us the course of action in regarding
to these problems.

The OMA PAG would like to thank IETF (SIMPLE) for their consideration and
response to this request and we look forward to future opportunities to work
together. Kind regards,

Lu Chang, Ph.D.
Jaekwon Oh

On behalf of OMA PAG