Subject: RE: [Simple] XCAP and its problem with Namespaces caused by usingonly the XML fragment body.

From: "Hyttfors, Per" <[email-masked]>
Date: Thu, 25 Aug 2005 19:00:36 +0200

I hope that many with me agree that the best alternative is to solve this XCAP issue within the IETF.

As I wrote in my response to Rosenberg, W3C has dealt with this problem years ago and has come up with both XML fragment context specification and canonicalization. They are working standards and there has to be several implementations already using this.

But you are right, as your suggestions on workarounds show, this problem could probably be avoided by OMA PoC with some changes in the current OMA specifications, some more dramatic than others. I would personally like to see that a client is able to fetch a part of a document without having to do multiple requests, or having to maintain one more document, with all the problems this could cause. The suggested solution A and B allows for this, but there is a trade-off as it limits or complicates extensibility in future versions and the possibility to use proprietary extensions etc.

/Per 

>-----Original Message-----
>From: Zisimopoulos, Haris, VF-Group 
>[mailto:[email-masked]] 
>Sent: fredag den 19 augusti 2005 11:04
>To: Dean Willis; Simple WG
>Cc: Kelvin Porter; Hyttfors, Per
>Subject: RE: [Simple] XCAP and its problem with Namespaces 
>caused by usingonly the XML fragment body.
>
>From my point of view I don't think things are as dramatic for 
>the usage of XCAP for PoC . 
>
>OMA uses XCAP to manipulate different types of documents:
>- Presence Lists (using only the IETF namespace)
>- Presence Authorisation rules (using the IETF namespace+OMA 
>extensions due to the fact that there is a number of OMA 
>defined presence elements)
>- PoC conference policy documents (using OMA namespaces only)
>- PoC user access documents (using OMA namespaces only)
>- PoC directory (using namespaces only)
>
>An OMA compliant PoC client needs to support all these 
>namespaces (OMA and IETF defined). Therefore is a number of 
>different approaches that could be used as workarounds for PoC:
> 
>A) Wrap all the namespaces per application usage in one single 
>OMA defined namespace
>B) Standardise the prefixes (I think there is a small change 
>that is necessary for this to work)
>C) Create a document (similar to xcap-caps) per each XCAP 
>server to fetch the namespace/prefix bindings
>
>I understand that all these are not flexible enough and do not 
>make XCAP a "generic" XML manipulation protocol that can 
>handle any kind of namespaces, without the client's prior 
>knowledge (but I don't think this was the initial requirement, 
>as I understand it).
>
>My vote therefore would be: stick with what we have right now 
>(maybe there are couple of small changes that need to be done 
>particularly in section 6.4 and some similar changes in the 
>OMA specs to make some of the workarounds to be possible) and 
>do the extensions in a separate track.
>
>Best regards,
>Haris
>
>Haris Zisimopoulos
>Group Research & Development - UK
>Vodafone Group Services Ltd
>E-mail: [email-masked] 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Dean Willis
>Sent: 19 August 2005 00:36
>To: Simple WG
>Cc: Kelvin Porter; Hyttfors,Per
>Subject: Re: [Simple] XCAP and its problem with Namespaces 
>caused by usingonly the XML fragment body.
>
>
>I'm thinking that this message documents a relatively 
>significant problem either with XCAP or with a usage of XCAP 
>as proposed by OMA PoC.
>
>XCAP is currently in the RFC Editor's Queue, and consequently 
>somewhat hard to change, but some changes could perhaps be 
>made by an IESG "note to the RFC editor" if needed (and 
>approved by the IESG).
>
>I'd like to see some discussion of the severity of this 
>problem and what should be done about it -- preferability Very 
>Soon, as OMA is meeting next week.
>
>Possibilities I see:
>
>1) Fix the XCAP spec before publication.
>
>2) Obsolete the current XCAP spec and produce a new one.
>
>3) Define an extension to XCAP to fix the problem.
>
>4) Decide it's not really an XCAP problem, because OMA PoC is 
>using the protocol in a manner inconsistent with its design 
>requirements, and help OMA PoC come up with a workaround.
>
>5) Something entirely different.
>
>Thanks!
>
>--
>Dean WIllis
>as IETF liaison to OMA
>
>On Aug 10, 2005, at 6:32 AM, Hyttfors, Per wrote:
>
>> Hello,
>>  
>> As I see it there is a major problem with retrieving elements in an 
>> XML document using XCAP. The problem has to do with that the XDM 
>> clients has to know all the namespace prefix bindings in the server 
>> document prio the fetch of an element.
>>  
>> The problem is that the current XCAP specification only 
>mandates that 
>> a XCAP fragment body is sent between server and client when 
>performing 
>> XCAP operations. Not being an fcs document with the fragment context 
>> specification leads to problems now when the XCAP URL has been made 
>> independent of the namespaces prefixes used in the document on the 
>> server.
>>  
>> The XML data returned in the 200 OK answer on a fetch of an element 
>> will contain the exact content of that element in the XML 
>document on 
>> the server. If this element or any child elements use namespace 
>> prefixes declared earlier in the document they will not be 
>included in 
>> the response to the client. Hence the only way to know all the 
>> prefixes is to have done a fetch of the whole document.
>>
>> Just to clarify the problem I have made these examples (inspiration 
>> from the XCAP specification..)
>>  
>> Bill has not fetched the whole server document, and it looks 
>like this:
>>  
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <service uri="sip:[email-masked]">
>>       <a:list name="marketing">
>>         <a:entry uri="sip:[email-masked]"/>
>>         <a:entry uri="sip:[email-masked]"/>
>>       </a:list>
>>       <packages>
>>         <package>presence</package>
>>       </packages>
>>     </service>
>>    </rls-services>
>>  
>>
>> Bill decides to get the service information for uri 
>> sip:[email-masked]
>>  
>>    GET
>>    /rls-services/users/bill/index/~~/rls-services/
>>    service%5b@uri=%22sip:[email-masked]%5d
>>     HTTP/1.1
>>  
>>    and the server responds:
>>  
>>    HTTP/1.1 200 OK
>>    Etag: "ad88"
>>    Content-Type:application/xcap-el+xml
>>  
>>     <service uri="sip:[email-masked]">
>>       <a:list name="marketing">
>>         <a:entry uri="sip:[email-masked]"/>
>>         <a:entry uri="sip:[email-masked]"/>
>>       </a:list>
>>       <packages>
>>         <package>presence</package>
>>       </packages>
>>     </service>
>>  
>> Bill is now confused as he has no idea what namespace the tags that 
>> are using the namespace prefix a: belongs to, so he has to fetch the 
>> whole document to find out....
>>  
>>  
>> Also as disscussed earlier: 
>> 
>http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html the 
>> XDM client has to always send the xmlns declaration with the XML 
>> elements that are sent in a PUT in order to be sure that it 
>will be a 
>> valid part of the complete XML document on the server..
>>  
>> This would be a situation where the client would have a 
>problem if the 
>> xmlns declaration is missing in the XML fragment body:
>>
>> The server document looks like this:
>>  
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <a:resource-lists xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <a:list name="close-friends">
>>      <a:display-name>Close Friends</a:display-name>
>>      <a:entry uri="sip:[email-masked]">
>>       <a:display-name>Joe Smith</a:display-name>
>>      </a:entry>
>>     </a:list>
>>    </a:resource-lists>
>>  
>> Bill creates an element in the resource-lists document 
>(Section 7.4). 
>> In particular, he creates a list with an entry:
>>
>>    PUT
>>    /services/resource-lists/users/bill/fr.xml
>>    /~~/resource-lists/list%5b@name=%22friends%22%5d HTTP/1.1
>>    Content-Type:application/xcap-el+xml
>>    Host: xcap.example.com
>>
>>  
>>    <list name="friends">
>>      <entry uri="sip:[email-masked]">
>>        <display-name>Bob Jones</display-name>
>>      </entry>
>>    </list>
>>  
>> Bill will cry as the validation of the document after the 
>tentatively 
>> insertion will fail as this will produce a invalid XML document..
>>  
>>  
>>
>> /Per
>>  
>> Per Hyttfors
>> ___________________________________________________________
>> Development Engineer - Messaging Application Development 
>Sony Ericsson 
>> Mobile Communications AB
>> SE-221 88 Lund, Sweden
>> +46 46 2126534
>> [email-masked] (MSN/E-mail) 
>> ___________________________________________________________
>>
>> The information in this email, and attachment(s) thereto, is 
>strictly 
>> confidential and may be legally privileged. It is intended 
>solely for 
>> the named recipient(s), and access to this e-mail, or any
>> attachment(s) thereto, by anyone else is unauthorized. Violations 
>> hereof may result in legal actions. Any attachment(s) to this e-mail 
>> has been checked for viruses, but please rely on your own 
>> virus-checker and procedures. If you contact us by e-mail, we will 
>> store your name and address to facilitate communications in 
>the matter 
>> concerned. If you do not consent to us storing your name and address 
>> for above stated purpose, please notify the sender promptly. 
>Also, if 
>> you are not the intended recipient please inform the sender by 
>> replying to this transmission, and delete the e-mail, its 
>> attachment(s), and any copies of it without, disclosing it.
>>  _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/simple
>
>
>_______________________________________________
>Simple mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/simple
>

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

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 26 Aug 2005 15:33:07 +0300

>But you are right, as your suggestions on workarounds show, this problem could probably be avoided by OMA PoC with some changes in the current OMA specifications, some more dramatic than others. I w…
Per, if I have understood correctly, you might be satisfied with Accept: 
application/xcap-el-efb+xml where the body would be expressed with the 
exclusive xml canonical format ? If so, why don't you (or someone) write 
an XCAP extension i-d about it ? I.e. imo this looks more like a new 
feature than a bug. Secondly, besides some added complexity there's also 
added verbosity involved with this approach. So imo both models could be 
allowed.
br,
Jari