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

Re: Some thoughts on XCAP's resource architecture

From: Jamie Lokier <jamie@shareable.org>
Date: Thu, 25 Nov 2004 00:20:50 +0000
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>
Message-ID: <20041125002050.GA5730@mail.shareable.org>

Julian Reschke wrote:
> >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.
> Putting the selector into the query part doesn't change anything it all. 
> That would be merely a change in syntax with almost no impact in 
> implementations (possibly except working around implementation problems 
> in intermediaries).

No, actually there is an important reason why XCAP should be changed
to be after the query part.

Clearly, generic origin XCAP servers should not have to analyse and
transform the text of XML document - they should simply know how to
select portions of it based on the XCAP selector.

With the "/~~/" syntax, think about what happens when an XCAP resource
is fetched by non-XCAP aware software that is given an XCAP URL.  For
example, a web browser told to view a subtree of some XML document.

That is one of the most useful reasons why XCAP is operating using
HTTP URLs, after all.

Relative URLs appearing in the text of the subtree will be resolved by
the browser including components of the selector.

This is fine when the selector path represents other accessible
resources.  For example, when a selector is used to access resources
in a filesystem-like hierarchy, but in this case, why use XCAP at all?

However, imagine a browser is told to view some limited portion of an
XHTML document (or any other document format), which contains links to
other resources on the same server.  In this case, the URL is used to
restrict the view of the document to a portion of it.

When XCAP is used in this way, almost certainly you want URLs in the
text of the restricted view to resolve relative to the path _before_
the selector - the selector itself should not count in relative URL

To fix this, thereby making XCAP more widely useful, why not use "??":

     - "??" seems likely to be unambiguous in practice

     - it's valid, and RFC1808 path resolvers will do the right thing

     - it can be appended to any existing path including those which
       already have a "?" query part, so select sub-resources of
       all existing resources

"??" would allow a generic XCAP server module to be written which
would serve a restricted view of _any_ resource that the server
already serves, automatically maintaining correct relative URLs in the
resource whatever its syntax.

For example, such a module could be written for Apache, and it would
automatically add a facility for fetching any resource that Apache is
able to serve now, but restricting the response to a portion of it -
while keeping those relative URLs working.

With the "/~~/" syntax, XCAP has the flaw (a big flaw IMHO) that a
generic XCAP module for restricting views cannot be written: such a
module would have to know how to transform relative URLs appearing in
the body, and that implies document-type-specific parsers.

To whom do I write to be sure this issue is properly considered?

-- Jamie
Received on Thursday, 25 November 2004 00:20:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC