Subject: RE: [Simple] XCAP namespace conundrum - another approach?

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 24 Oct 2005 18:29:31 -0500

It's probably helpful to have a problem restatement.  I see two sides to the problem:

1. When inserting an XML fragment into a (possibly) unknown context, the client needs to be some way of ensuring that the namespace of the nodes in the fragment are correctly identified.  This should be possible without having a canonical fragment that exhaustively defines all used namespace prefixes.

2. When receiving an XML fragment from a (possibly) unknown context, the client needs some way of identifying the namespace bindings for that fragment so they can make sense of it.

Your proposal is still, in essence, suggesting that namespace prefixes are fixed.  This has already been deemed problematic.  Read the section from Canonical XML on the matter:
	http://www.w3.org/TR/xml-c14n#NoNSPrefixRewriting

I have a couple of possible alternatives that ensure that mapping information is carried with the XML fragment.  All of these have the advantage of requiring only a single request.  My apologies if these have already been discussed.

i. Provide out-of-band indication of namespace prefix mapping.  Similar to the "namespace::*" selector, this would be required on both GET responses and PUT requests.  This doesn't fit into HTTP, so this would require an envelope.
Advantage: The body of the message is a complete (and valid) XML document.
Disadvantage: Processing is required to extract actual content of requested node.  The resource is no longer directly accessible. 

   PUT /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
   Host: xcap.example.com
   Content-Type: application/xcap-env+xml

   <xcap:env xmlns="urn:ietf:params:xml:ns:rls-services"
             xmlns:xcap=""urn:ietf:params:xml:ns:xcap-env">
     <entry uri="sip:[email-masked]">
       <display-name>Bob Jones</display-name>
     </entry>
   </xcap:env>

Also, care needs to be taken that the ns prefix on the envelope doesn't clash with any that are used in the actual content.

ii. Invent a simple notation so that mapping information can be embedded.  Advantage: It's simple and easy to specify, simple to parse as well.
Disadvantage: You can't even pretend that this is XML.

   PUT /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
   Host: xcap.example.com
   Content-Type: application/xcap-el+xml

     <entry {xmlns="urn:ietf:params:xml:ns:rls-services"} uri="sip:[email-masked]">
       <display-name>Bob Jones</display-name>
     </entry>

iii. Use HTTP headers to carry the information.  A "Content-..." header is a pretty good, if rough, fit.
Advantages: looks most like the current incarnation.
Disadvantages: more HTTP header fluff.

   PUT /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
   Host: xcap.example.com
   Content-Type: application/xcap-el+xml
   X-Content-xmlns-Context: xmlns="urn:ietf:params:xml:ns:rls-services"

     <entry uri="sip:[email-masked]">
       <display-name>Bob Jones</display-name>
     </entry>

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
Sent: Monday, 24 October 2005 3:22 PM
To: Simple WG
Subject: [Simple] XCAP namespace conundrum - another approach?

As folks can see from the updated xcap I-D I posted, I've added the fix 
for the namespace discovery problem that was reported. This fix allows a 
client to fetch the namespaces in scope for an element, so that it can 
then construct a valid document fragment for insertion. This is needed 
only when a client doesnt cache the whole document.

Its fair to say that this is still not perfect. Its main drawbacks are:

1. to get the namespace bindings that are actually in use, the client 
has to make up a set of namespace bindings in the xmlns() components of 
the query string in the URI, just to get back the real bindings. Having 
to make up an intermediate set is ugly and inefficient

2. It requires a query to first get the namespace bindings, and then 
another query to PUT an element that uses them. The query to get the 
namespaces can happen just once and then the results cached. Conditional 
PUT would then be done for subsequent operations to make sure nothing 
has changed. However, we have the limitation that conditional PUT only 
works for modifications, not insertions. So, if you want to insert a 
buddy in your buddy list, you'll have to check the etags in the 201 
response to the buddy insertion to make sure you made the addition 
against the right version, and back out if you didnt. Complex.

I have in mind another potential solution, which can be used in addition 
to, or instead of, what is document in the xcap-08.

In my email where I originally propsoed the fix in -08, I had mentioned 
an alternative was to have well-known namespace bindings for namespaces 
used on the server. The problem with that approach is that it limits 
extensibility to new namespaces. Specs would need to be written for each 
one prior to usage by either client or server. Today, a client can use 
elements from new namespaces without the server knowing them, and this 
has been a very desirable feature.

My idea is a variation on this. Instead of using well-known namespace 
bindings, the namespace binding would be computed as a base64-encoded 
crypto-hash on the namespace URI, using sufficient number of bits to 
reduce the collision probability in any particular document to really 
low. Fortunately, you don't need a lot of bits at all. I suspect 32 is 
more than enough, so you'd have a six byte prefix. An applicatoin usage 
could then specify, as part of its non-schema validation constraints, 
that the namespace prefixes be limited in this way. The server would 
then reject documents that are PUT which don't satisfy this constraint.

I'd also then modify matching rules for the request-URI so that the 
namespace bindings in scope when evaluating the URI are the hashed ones 
for all namespace URI in the document itself. When you use these hashed 
prefixes, you wouldn't need to use the xmlns() query components.

You'd also be able to, for example, insert a new buddy into a buddy list 
without caching the document, and with a single operation. No need for 
conditional operations and thus we avoid the problem with conditional 
insertions.

The approach still allows for new elements from new namespaces. The 
server doesnt need to know about the namespace URI ahead of time.

The only drawbacks I can see are:

1. completely falls apart for documents that were created prior to their 
access through xcap. That is why I'm recommending that this be 
enabled/disabled on an app-usage by app-usage basis. You could define an 
app-usage where this wasn't used, in case you had documents that existed 
prior to usage with xcap. Thats why I think we still need whats in 
xcap-08  - for these cases.

2. its still kind of ugly. I think the spirit of XML is that namespace 
prefixes are always a localized choice, and we'd be globally 
constraining them.

3. you might get a collision in the hashes. Fortunately, you would 
usually know this ahead of time since, in most cases, the set of 
namespace URI used for a particular application usage are relatively 
small and known. Thus, when designing a new extension, you could pick a 
namespace URI that you KNOW doesnt conflict with an existing one.

What do folks think of this?

Thanks,
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

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

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Oct 2005 23:56:58 -0400

inline.

Thomson, Martin wrote:

> 1. When inserting an XML fragment into a (possibly) unknown context,
> the client needs to be some way of ensuring that the namespace of the
> nodes in the fragment are correctly identified.  This should be
> possible without having a canonical fragment that exhaustively
> defines all used namespace prefixes.

I'm not sure I understand the last sentence here. If you mean that the 
client shouldn't have to know apriori all of the namespace bindings in 
scope at the point of insertion, then I kind of agree. I think the REAL 
requirement is to be able to do an insertion in this situation with a 
single request.

> 
> 2. When receiving an XML fragment from a (possibly) unknown context,
> the client needs some way of identifying the namespace bindings for
> that fragment so they can make sense of it.

Yes, and again without an additional request.

> 
> Your proposal is still, in essence, suggesting that namespace
> prefixes are fixed.  This has already been deemed problematic.  Read
> the section from Canonical XML on the matter: 

Thanks for the pointer. However, that text is in regard to rewriting of 
a namespace prefix that already exists in a document. I agree this is 
bad since it creates problems of referential integrity. What I am 
proposing is NOT to rewrite, but that the only namespace prefix that is 
allowed in the document in the first place is a specific one, equal to a 
hash of the namespace URI. THus, you would never have the problems 
pointed out in the reference you cite.

> 
> 
> I have a couple of possible alternatives that ensure that mapping
> information is carried with the XML fragment.  All of these have the
> advantage of requiring only a single request.  My apologies if these
> have already been discussed.
> 
> 
> i. Provide out-of-band indication of namespace prefix mapping.
> Similar to the "namespace::*" selector, this would be required on
> both GET responses and PUT requests.  This doesn't fit into HTTP, so
> this would require an envelope. Advantage: The body of the message is
> a complete (and valid) XML document. Disadvantage: Processing is
> required to extract actual content of requested node.  The resource
> is no longer directly accessible.
> 
> PUT
> /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
> HTTP/1.1 Host: xcap.example.com Content-Type:
> application/xcap-env+xml
> 
> xmlns:xcap=""urn:ietf:params:xml:ns:xcap-env"> <entry
> uri="sip:[email-masked]"> <display-name>Bob Jones</display-name> 
> </entry> </xcap:env>
> 
> Also, care needs to be taken that the ns prefix on the envelope
> doesn't clash with any that are used in the actual content.

I don't know how this would help though. THe server presumably unwraps 
the envelope, extracts the <entry> and inserts it. The prolem, though, 
is that the default namesapce within the envelope 
(urn:ietf:params:xml:ns:rls-services) may not match the default 
namespace in scope of the parent of <entry> in the actual document. 
Thus, you have the same problem we have today.

> 
> 
> ii. Invent a simple notation so that mapping information can be
> embedded.  Advantage: It's simple and easy to specify, simple to
> parse as well. Disadvantage: You can't even pretend that this is XML.
> 
> 
> PUT
> /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
> HTTP/1.1 Host: xcap.example.com Content-Type: application/xcap-el+xml
> 
> 
> <entry {xmlns="urn:ietf:params:xml:ns:rls-services"}
> uri="sip:[email-masked]"> <display-name>Bob Jones</display-name> 
> </entry>

As above, I don't see how this helps.

> 
> 
> iii. Use HTTP headers to carry the information.  A "Content-..."
> header is a pretty good, if rough, fit. Advantages: looks most like
> the current incarnation. Disadvantages: more HTTP header fluff.
> 
> PUT
> /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
> HTTP/1.1 Host: xcap.example.com Content-Type: application/xcap-el+xml
> <entry uri="sip:[email-masked]"> <display-name>Bob
> Jones</display-name> </entry>
> 

Same as above. Unless I'm missing something, none of these help. Its not 
a transport problem, its a knowledge problem. The problem is that, the 
client needs KNOWLEDGE of the namespace bindings in scope at a point of 
insertion in order to construct an XML fragment which produces a valid 
document after insertion. AFAICT, there are only two fundamental paths 
to solve this:

1. we provide a way for the client to learn the valid bindings, or
2. we provide a way for the server to rewrite the bindings in the 
request to equal the valid bindings

You've made some good arguments via the spec you site above, on why (2) 
is a bad idea. I also dislike it, since requestin gthe XCAP server to 
rewrite prefixes, will fundamentally break get(put(x)) = x.

So, that leaves us with (1). To solve that, we either need to fix the 
bindings so that they are well known, or provide a way for them to be 
learned. Providing a way for them to be learned in advance of a PUT 
would seem, to me, to require an additional transaction ahead of the 
PUT, thus violating our requirement for a single method. This leaves the 
only choice of making them well-known, and thus my proposal for a hash.

-Jonathan R.