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

Submission date 2005-10-31
From OMA (Dean Willis)
To IETF SIMPLE Working Group (Robert Sparks, Hisham Khartabil)
Cc Ted 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

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

OMA PAG kindly requests IETF informing us the result of their

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 servers

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

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
   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
   inserted.  If the target selector is defined by a by-name or
   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
   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 NameorAny.

ï‚Ÿ	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

ï‚Ÿ	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 attributes.

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

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