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

From: "Hyttfors, Per" <[email-masked]>
Date: Wed, 10 Aug 2005 13:32:50 +0200

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
<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
<mailto: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
<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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Aug 2005 20:57:41 -0400

inline.

Hyttfors, Per wrote:

> independent of the namespaces prefixes used in the document on the server.
>  

The client doesn't need the whole document; it just needs the portion of 
the document above the element that has been fetched, in order to know 
the namespace bindings that are in scope for the element that is being 
fetched.

I'm assuming that you have in mind an application where the client 
doesn't normally store the whole document, for example a cell phone 
where I want to retrieve portions of my buddy list one buddy at a time.

As such, one solution is to fetch the whole document at startup, get the 
namespace bindings and etag, and dump the document. Then, subsequent 
GETs are conditional against the etag, and so the client can get the 
information it needs and use the cached namespace bindings.

This is clearly not optimal since it requires a full document get just 
to obtain the namespace bindings. However, it works with the current spec.

Some other thoughts are:

1. an xcap extension that allowed to specifically query for the 
namespace bindings in scope for a particular element

2. change xcap so that what is returned is an xml fragment that includes 
additional information on the namespace bindings in scope

3. have the xcap server return xml data using the namespace bindings in 
scope for the request URI. This requires the server to modify the xml 
data before sending it to the client

> http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html the 
> XDM client has to always send the xmlns declaration with the XML 

Yeah, this is another good point. This is the PUT eqiuvalent of the GET 
problem you describe above. Here its easier though; if the client 
doesn't know the namespace bindings because it doesn't have the full 
document, it should include the bindings in the fragment itself.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 17 Aug 2005 11:03:39 +0300

> data before sending it to the client
I suppose this question has come from OMA people. An XPath way of doing
this could be GET ....~~/root/namespace::*, i.e. namespace axis could be
used to request all the in-scope namespaces of some element. An XCAP
extension should then describe this BNF extension as well as the payload
format.

br,
Jari

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Aug 2005 18:36:24 -0500

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 
> 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 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....
>  
>  
> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Aug 2005 20:18:13 -0400

I am apparently missing something in how this all will get used.
I understand how to use XCAP without additional namespaces.
I know how to use XCAP when the usage defines a set of namespaces and 
namespace prefixes that will be used in the document.
I understand that things will be somewhat difficult when new extensions are 
added to the document definitions, but I think those work fine.

I do not imagine that users will ever define either namespaces or namespace 
prefixes.  They don't know or understand such things.  Hence it is the 
software that is providing the service that is create the namespace 
references and assigning them prefixes.   I understand that XML allows one 
to use any old prefix, reuse prefixes, and all sorts of other things.  If 
the document does that, the XCAP client will need to know those things.

Or, in other words, in very messy situations a client will need to fetch 
and analyze all sorts of information.

But why would the software have that occur with a buddy list?  Are we 
really assuming that there are multiple extensions and that different 
clients will pick different quasi-random names for these extensions?  And 
then we will actually expect another client to be able to figure out what 
is really going on?  When even human beings have trouble sorting that sort 
of context out?

I presume I am missing some good reason for this mess.  I would appreciate 
an explanation.  In the absence of clear and urgent need, I would tend to 
conclude that this can be dealt with by an extension at a later date.

Or, to put it in different terms:
lets get the simple case out, and then figure out if the corner case 
actually matters.
Particularly since it is clear that we can add extensions that will cope.

Yours,
Joel M. Halpern

At 07:36 PM 8/18/2005, Dean Willis wrote:

>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.
>
>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:
>
>protocol in a manner inconsistent with its design requirements, and help 
>OMA PoC come up with a workaround.
>
>>to know all the namespace prefix bindings in the server document prio the 
>>fetch of an element.
>>
>>XCAP fragment body is sent between server and client when performing XCAP 
>>operations. Not being an fcs document with the fragment context 
>>response to the client. Hence the only way to know all the prefixes is to 
>>have done a fetch of the whole document.
>>
>>Bill decides to get the service information for uri sip:[email-masked]
>>
>>    GET
>>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..
>>
>>Bill creates an element in the resource-lists document (Section 7.4).  In 
>>particular, he creates a list with an entry:
>>
>>    PUT
>>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) 
>>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.

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 19 Aug 2005 09:51:55 +0300

ext Dean Willis wrote:

> problem either with XCAP or with a usage of XCAP as proposed by OMA PoC.
>
> 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 would prefer this path (and also fix some nits regarding whitespace 
nodes,  ambiguity with positional constraints and some typos)

> 2) Obsolete the current XCAP spec and produce a new one.
I'll hope this can be avoided.

> 3) Define an extension to XCAP to fix the problem.

A simple extension to the base XCAP spec can solve this e.g. 
<http://www.ietf.org/mail-archive/web/simple/current/msg05710.html>. 
Certainly there could be some other needs e.g. search with XQuery, but 
this problem is imo fairly easily solved. We had some similar dispute 
when there was the last minute change of the r-uri regarding namespaces. 
Then it was decided that elements in the body use the same prefixes than 
the patched document.

Another case is that if it is not necessary for the client to use 
exactly the same prefixes, only the namespace uris have to match (within 
the body). This model is used in xml-patch-ops because it makes the 
implementation easier for the client.

> 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.
>
This is in principle true. However, I'll admit that beside this case, 
the patching model is somewhat challenging to implement.

br,
Jari