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

From: Scott Lawrence <[email-masked]>
Date: Thu, 25 Sep 2003 11:04:51 -0400

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

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

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.

====

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

[1] HTTP Specification Errata http://purl.org/NET/http-errata

-- 
Scott Lawrence        
  Pingtel Corp.   

deprecated addresses: <[email-masked]> <[email-masked]>

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