W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

Re: [Simple] Some thoughts on XCAP's resource architecture

From: KAWAGUTI Ginga <g.kawaguti@ntt.com>
Date: Sun, 28 Nov 2004 01:27:36 +0000
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>
Message-ID: <20041128012722.GA49273%ginga@ginganet.org>




In Sun, Nov 21, 2004 at 06:58:47PM -0800,
Lisa Dusseault <lisa@osafoundation.org> wrote:
> Based on the mailing list on the traffic, it appears that  XCAP is 
> supposed to be an extension or profile of HTTP, rather than just a 
> protocol that mimics the HTTP interaction style, and that as such it is 
> intended to be compatible with other extensions of HTTP.  I'm concerned 
> that the current architecture of XCAP makes this difficult.  In 
> particular the XCAP resource ontology and the URL addressing style that 
> goes with it shifts the HTTP design along two major axes:

..snip..

> So, what to do? It doesn't seem to me that XCAP is going to go back to 
> the drawing board (or needs to), but it would be sufficient for most of 
> the above concerns to simply make the definition of "resource" stay 
> with the root XML documents that XCAP deals with.  The existing 
> extensions to HTTP work a lot better on that size resource.  Part of 
> this change involves putting the XPATH-like part of the XCAP URL out of 
> the path part of the URL.  It could go in a header or even in the URL 
> after the query delimiter (the question mark).  There is a theoretical 
> problem with using query parameters on HTTP URLs in PUT requests if 
> write-through caches don't know how to handle those, but there aren't a 
> lot of write-through caches and overall it's a smaller problem and less 
> work to deal with.

I agree with this in general.
Also, there might be some other anxiety, which is encoding.

XCAP's target document is usually written in UTF-8(it's XML),
so XCAP requires Xpath stuff(utf-8) into URL part, which is usually
considered as US-ASCII.
There are ways to encode utf-8 string into URL part, but
I don't think there's any unique, robust and common way for doing it.

If that argument was in body part(header might also be recepted),
this consideration is much less problem, because there are ways to
declare encodings, and usual gateways/clients are aware of them.

(People who lives in us-ascii world, or even iso-8859-* world,
 might not realize what these problems are...)
-- 
Office:  NTT Communications Innovative IP Architecture Center 1PT 1P
Address: KAWAGUTI Ginga <g.kawaguti@ntt.com>
Phone:   voice=+81-3-6800-3032; fax=+81-3-5388-0550
Received on Sunday, 28 November 2004 08:45:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:36 GMT