Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Oct 2003 14:00:11 -0500

Sorry for the late response. I thank you very much for your comments 
on this document; its great to have a real HTTP expert take a look at it.

responses inline.

Scott Lawrence wrote:
> I've started studying the XCAP proposals, and have a first couple of
> suggestions for the framwork draft:
> 
> ====
> 
> In section 4, the Application Usage ID id defined using one of two
> namespaces, an implicit IETF namespace that controls all names not
> prefixed by 'vnd.' and the vendor namespace for all names that do have
> that prefix.  I would suggest a single uniform naming convention,
> already familiar to any Java programmer: invert the order in a DNS
> domain name controlled by the entity defining the usage.  All
> IETF-defined names would be prefixed by 'org.ietf' (and registered
> with IANA); any Pingtel-defined name would be prefixed 'com.pingtel'.

This is an area were there are many different approaches across IETF 
protocols. The proposal in the xcap draft mirrored the rfc2506 media 
feature tag registration procedures.

Anyway, I do think it makes sense to use the java naming convention 
for vendor tags. I would prefer to have a separate ietf namespace, and 
so I kept that.

> 
> I think that the intent in section 5 is that the Node-Selector be
> passed in the HTTP query string component of the URI (though it is not
> phrased that way).  If so, the syntax from the draft:
> 
>    XCAP-URI        = Document-URI ["?" Node-Selector]
> 
> is redundant, since a URI may include a query string (incidentally,
> there is a bug in RFC 2616 with respect to this, which may be where
> this came from - see the errata list [1]).  This syntax actually
> allows http://example.com/foo?query?node-selector, which I'm sure was
> not your intent. 

No. Actually, in the -01 version, I dropped the grammar completely. An 
xcap URI *is* an HTTP URI, so I didnt want to specify a separate 
grammar for it. I merely gave names to the two pieces (the document 
URI and node selector), and said that the node selector is the HTTP 
query string, and the document URI is the rest of the URI.

  I think that a more appropriate mechanism for
> specifying a component would be to pass it as a fragment identifier
> (defined in RFC 2396 [URI Generic Syntax], section 4.1), which is
> appended to (but not a part of) the URI separated by the '#'
> character.  This construction is a URI reference, so the suggested
> syntax would be:
> 
>    XCAP-URI-reference = Document-URI ["#" Node-Selector]
> 
> this is exactly what fragment identifiers are for. 

We discussed this at the interim meeting. The problem is that the 
fragment identifiers are not passed on the wire to the server. They 
are evaluated locally. Here, we want the server to evaluate the 
fragment identifier, and just return that portion of the document. So, 
we kept the query string approach.

It had also been proposed to simply continue to use the "/" hierarchy 
all the way down into the XML document, i.e.:

http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/
   resource-list[@id="assd99"]

where the last two components of the path identify XML elements. I 
didnt like this, since practically speaking, implementations are 
likely going to want to use the filesystem or DB to retrieve a 
specific document, and then use some XML processing to retrieve an 
element or attribute. So, knowing where the breakpoint is in the URI 
is helpful, I think.

> In addition to the
> syntactic problem above, using a query string may interact poorly in
> some HTTP server implementations when the method is not GET.

Really? This is worth testing, I think. We need it with PUT and 
DELETE. Any volunteers to run a few tests on few servers? Should be an 
easy one.

> 
> On the node-selector itself, did you consider using XPointer [2] rather
> than XPath?  I'm still studying these myself, but on first look,
> XPointer (whose purpose is to provide an xml fragment identifier
> syntax) looks sufficient for XCAP and much simpler.

I spent some time looking at xpointer. Here is what I learned.

Xpointer provides a generic framework 
(http://www.w3.org/TR/xptr-framework/) this framework doesnt do more 
than allow different schemes for identifying XML components. Then, it 
defines a few specific schemes. http://www.w3.org/TR/xptr-element/ 
allows for addressing of elements by position. However, it *only* 
allows for order-based addressing, i.e.:

/root-element/2/3/4/3/2

after the element name at the top, each fragment of the path after 
that is an integer that identifies a position in the document. Thats 
not sufficient for us, I dont think. It makes the adressing brittle. 
There is no way to have a way to identify a specific buddy, for 
example, where the reference would remain valid after changes and 
additions have been made to the document. In the xcap usages I have 
designed so far, I have been adding id elements to the schema to 
faciliate very targeted addressing using the element[@att="val"] Xpath 
approach. Using the xptr-element approach means that, for all intents 
and purposes, a client will need to pull the whole doc in order to be 
sure its pointing to the right element for addressing a DELETE or PUT 
to modify it. Given that wireless is our #1 customer for this, I am 
concerned about that.

There is another Xpointer scheme for some kind of namespace mapping 
(http://www.w3.org/TR/xptr-xmlns/). The other xpointer spec, yet 
unfinished, uses xpath and allows for identification of elements 
(http://www.w3.org/TR/xptr-xpointer/). Whats interesting about it, is 
that it is a SUPERSET of Xpath. That is, in addition to all the 
capabilities in Xpath, it adds a few more functions, including some 
range functions that allow for document selection by character position.

So, given that our aim is to use less of Xpath rather than more, and 
given that Xpointer usin Xpath is as yet unfinished, I didnt think it 
was a good match for us.

Instead, in the -01 version I submitted, I defined our own mini-xpath 
that provides just a few ways of addressing elements.

> 
> ====
> 
> The draft suggests using the HTTP conditional request mechanisms based
> on date-time stamps, which were inherited from HTTP/1.0 by HTTP/1.1.
> I would suggest that using the HTTP/1.1 Etag mechanism would be a
> better choice.  A conditional fetch uses an If-None-Match header,
> holding the Etag value returned with the cached version of the
> resource; a conditional PUT, POST, or DELETE uses a If-Match header
> holding the Etag value.  There is some text in 2616 on the use of
> 'weak' etag values - in effect, this can be safely ignored (just don't
> use the explicit weak etag syntax and it all becomes a no-op).  From
> the client side, Etags are used in the same way date-times _should_ be
> used - as opaque strings, but because the server is free to construct
> Etag values in any way that preserves the match/no-match semantics,
> rather than being limited to a particular time-value syntax, Etags
> allow the server freedom to do smarter things internally (the etag
> value could be a unique database key, or a document hash, for
> example).

I'm sold.

The -01 version now makes use of Etags per your suggestion.

Thanks for your comments. I welcome any other thoughts you might have 
on xcap.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Oct 2003 14:00:11 -0500

responses inline.

/root-element/2/3/4/3/2

I'm sold.

Thanks,
Jonathan R.