Subject: [Simple] Submission of New Liaison Statement, "OMA LS 0051 Proposing Solution to XCAP Issues"

From: Dean Willis(OMA) <[email-masked]>
Date: Mon, 31 Oct 2005 16:25:03 -0500

Title: OMA LS 0051 Proposing Solution to XCAP Issues
Submission Date: 2005-10-31
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=144 
Please reply by 2005-11-12

From: Dean Willis(OMA) <[email-masked]>
To: IETF SIMPLE Working Group(Robert Sparks <[email-masked]>, Hisham Khartabil <[email-masked]>)
Cc: Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>
[email-masked]
Reponse Contact: Lu Chang <[email-masked]>
Jaekown Oh < [email-masked]>
Technical Contact: Lu Chang <[email-masked]>
Jaekown Oh < [email-masked]>
Purpose: For action 
Body: 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 servers

(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 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 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 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 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
[email-masked]
[email-masked]
Attachment(s):
No document has been attached

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple