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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Oct 2005 01:21:53 -0400

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