Subject: RE: [Simple] A proposal for fixing the xcap schema problem and relatedissues

From: [email-masked]
Date: Fri, 14 Oct 2005 10:46:19 +0300

Hi,

I support the idea of pulling XCAP out of the RFC ed's queue and fixing the problems identified below. It would be important not expand the discussion to any more new features, though. Those should be done as separate extensions.

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 08 October, 2005 08:19
> To: Simple WG
> Subject: [Simple] A proposal for fixing the xcap schema problem and
> relatedissues
> 
> 
> Folks,
> 
> There was some debate about a month back about a problem 
> identified in 
> XCAP regarding namespace handling, coming out of some experiences in 
> OMA. The specific mail that reported this problem can be found here:
> 
> http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html
> 
> The quick summary is that, for implementations that don't 
> normally store 
> the entire XML document locally on the client, a GET or PUT of a 
> fragment of the document is problematic, since the in-scope namespace 
> bindings for that fragment won't be known. This makes it 
> impossible to 
> interpret the results of a GET, or to formulate the namespace 
> prefixes 
> in the content of the PUT so the resulting document is valid.
> 
> Several options were proposed, including OMA-specific fixes, revising 
> xcap, or defining some extensions. I'd like to make a 
> concrete proposal 
> on how to move forward here.
> 
> Firstly, I think this problem needs to be addressed in IETF, 
> and needs 
> to be fixed in a way that is not specific to the OMA use 
> cases. It has 
> been an objective of xcap from its start that it be possible 
> to perform 
> manipulations on a document without the full document cached. Section 
> 5.10 of the -07 xcap draft talks about schema design guidelines that 
> allow for xcap to work without having the document cached, 
> for example. 
> The problem reported by Per Hyttfors will affect any usage for which 
> non-caching operation is needed, and will make any such usage 
> cumbersome 
> if not impossible. As such, it is not OMA specific, and I 
> consider it a 
> bug in the specification.
> 
> For this reason, my proposal is to ask IESG to remove xcap from the 
> rfc-editor queue, so that I can issue an update to the draft 
> that fixes 
> this problem.
> 
> My proposal to fix the problem is to follow the 
> recommendation made by Jari:
> 
> http://www.ietf.org/mail-archive/web/simple/current/msg05710.html
> 
> I would update the grammar of the node selector to allow for 
> namespace::*. Such a selector would select the namespace bindings in 
> scope for the element in question. xcap would define a format for 
> encoding those namespace bindings; basically, an xml fragment 
> body with 
> one element, the local name of the element in question, with 
> xmlns and 
> xmlns: attributes for each of the namespaces in scope, including the 
> default.
> 
> For example, consider this document:
> 
>     <?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:marketing at example.com">
>        <a:list name="marketing">
>          <a:entry uri="sip:joe at example.com"/>
>          <a:entry uri="sip:sudhir at example.com"/>
>        </a:list>
>        <packages>
>          <package>presence</package>
>        </packages>
>      </service>
>     </rls-services>
> 
> The following query:
> 
> GET 
> http://xcap-root.com/rls-services/users/joe/~~/rls-services/se
> rvice/namespaces::*
> 
> would return:
> 
>     <service 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"/>
> 
> 
> This fixes the problem by allowing the client to get the in-scope 
> bindings, and cache them, so they can be used to interpret subsequent 
> GETs, and then used to create the namespace prefixes for elements in 
> subsequent PUTs. Of course, the client needs to be sure that 
> the cached 
> namespace bindings havent changed prior to the PUT; the mechanisms in 
> section 7.10 of XCAP apply here as normal.
> 
> I did investigate a few other solutions to the problem. In 
> particular, I 
> looked to see if the XML fragment interchange:
> 
> http://www.w3.org/TR/xml-fragment
> 
> could be used as a solution. The idea is that you could GET 
> an element, 
> and if you specify the MIME type for a "fragment with context 
> format" in 
> the Accept header, the server could return the element along with its 
> context instead. Turns out, the XML format defined in the TR 
> above only 
> defines the fragment CONTEXT; there is no w3c-defined mechanism to 
> convey an element along with its context. As such, we'd have 
> to define 
> it ourselves. I'd rather not do that, since its something 
> better suited 
> for w3c to do. I'd also rather stick with xpath-based 
> approaches, rather 
> than introduce yet another new piece of XML technology for 
> this one problem.
> 
> Several other problems have been reported with the xcap specification 
> since its approval, and I would propose that these also be addressed 
> while I am revising the document. Specifically:
> 
> 
> 1. XCAP currently doesn't allow extensibility for the node-selector 
> itself. This means that, as currently defined, we couldn't 
> even formally 
> define the above fix as an extension, even if we wanted to. Other 
> possible node-selector extensions, such as:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-mult
> iple-00.txt
> 
> would also not be formally possible as extensions.
> 
> This is relatively easy to fix; it requires the grammar for 
> node-selector to add points of extensibility, and for some text to 
> indicate that servers reject, with a 404, expressions they don't 
> understand. Extensions to xcap that define a new node-selector would 
> define an extension name for themselves. A client can then discover 
> support for this new extension using the xcap-caps document 
> as currently 
> defined.
> 
> 2. Jari has reported some areas of underspecification around 
> insertions. 
> In particular, how insertions are done relative to whitespace and 
> comments. The proposal would be to add some text that 
> specifies that in 
> these cases, element insertions happen before whitespaces or comments.
> 
> 3. XCAPs usage of directory structures between the username 
> and the ~~ 
> is very underspecified, and some interop problems have been reported. 
> The lack of an ability to create sub-directories further complicates 
> this. I'd propose to fix this by making it a responsibility of the 
> application usage to define a well-known convention for constructing 
> this component of the document selector, and recommend that no 
> sub-directories be used at all. Rather, just documents right in the 
> user's home directory. Furthermore, for application usages 
> with just a 
> single document, that this document be called "index".
> 
> 4. A couple of nits have been reported, the worst of which are some 
> extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
> these too.
> 
> 
> 
> I would propose we limit the changes to xcap to these five items (the 
> main problem plus the four above), and no more.
> 
> I don't know if the scope of changes here require a re-do of 
> both WGLC 
> and IETF last call, and/or re-do of approval from IESG. I would hope 
> not, but this is something we need to discuss with Ted.
> 
> If the working group agrees with this direction, I will commit to a 
> revision of xcap with these changes prior to the non-00 deadline for 
> Vancouver. As such, please reply with comments ASAP, since time is 
> running out (October 24!).
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 03:09:51 -0400

Yes, I think from the responses there is consensus on this. I want to be 
clear I do NOT think we should add a text() selector. If someone wants 
that, please write up an I-D. Its a trivial extension, but its a feature 
enhancement and not a bug fix, and thus should be out of scope.

-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