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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Dec 2004 19:52:36 -0500

Thoughts inline.

Lisa Dusseault wrote:

> During the DC IETF, I expressed some reservations about XCAP to Ted and 
> Jonathan. Jonathan asked me to send a message to the SIMPLE list with my 
> comments, so here it is...
> 
> 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.

It is not an extension, it is a usage or profile. That is, an xcap 
server is a compliant HTTP server. What we are doing is defining how to 
map HTTP URLS to a set of resources that constitute the components of an 
http document. The nature of those resources has an impact on how you 
might want to cache them and handle their etags, and that is described 
in xcap.

   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:
> 
> 1) Resource granularity
> 2) Dependency between resource
> 
> The first shift is in size and number of resources.  Because the path 
> part of the URL allows for XML node selection, there are many more 
> resources for a given volume of content material.  This affects us in a 
> number of ways.
> 
> 1a) HTTP intermediaries and scaling: caches aren't designed to cache 
> huge numbers of tiny resources.  It would probably be wise to disable 
> caching on XCAP responses.

This is described in section 9 of xcap, which more or less says that you 
will want to disable caching for dynamic resources - ones frequently 
written by clients or otherwise. However, there are application usages 
where the data is primarily read-only. In that case, its reasonable to 
allow caching of those resources.

As such, there is an interaction with xcap and caching, but not because 
the resources are small - because they may be dynamic. This is an issue 
for any http resource.

> 
> 1b) HTTP servers aren't designed for that many small resources.  There's 
> a certain amount of overhead to maintaining the metadata (at a minimum, 
> the ETag) for so many small resources.  An HTTP server might have to be 
> rearchitected to do a scalable job of supporting XCAP, which increases 
> the XCAP implementation costs in the long run.

This is a possibly an implementation issue, certainly not a protocol 
one. As Joe pointed out in this thread, http itself says nothing of the 
typical size of resources, and lots of them are these tiny little 
things. In any case, I might expect xcap implementations to use database 
backing stores, but its an implementation choice and ymmv.

> 
> 1c) Performance: HTTP is designed to batch requests in a certain way 
> based on the granularity assumptions.  Recall that latency is a much 
> bigger problem than bandwidth above a certain (low) bandwidth, and in 
> modern Internet applications it's usually the latency that kills you.  A 
> more granular approach to resources doesn't in itself kill performance 
> but it does if you stay with HTTP's request granularity.  What XCAP is 
> saving in bandwidth it will lose, in many use cases, in latency costs.

I don't follow here. If you want to pipeline requests where you don't 
require conditional puts, go ahead and do so.

> 
> 1d) Extensions to HTTP have also been designed with HTTP's current 
> granularity in mind.  RFC2518, RFC3253, RFC3229, RFC3744 all extend HTTP 
> in useful ways, and they're all written with the assumption that the 
> granularity of resources is pretty much what it is today.  Access 
> control, in particular, has a lot of overhead per resource

Again, I don't think http itself says anything about what the 
granularity of a resource is supposed to be.

> 
> 2)  Dependencies:  HTTP servers are designed such that static resources 
> are handled independently of each other. Their ETag management is 
> stand-alone, the request and response handling and concurrency are 
> designed for that independence.  By contrast, XCAP contemplates a large 
> number of resources which really map to parts of the same underlying 
> file.  As far as I can tell, that introduces dependencies between 
> resources (for example that a PUT to one URL would require the ETag of 
> another URL to change).

Yes, xcap does introduce interdependencies between resources. AFAIK, 
there is nothing in http that says this is disallowed. Indeed, one can 
very well imagine that, in many cases, a change in one resource - 
affected through http directly or through back end applications, will 
affect other resources too.

> 
> 2a) HTTP implementation barriers.  The last HTTP server I developed 
> would have to be rearchitected in several places to handle XCAP's 
> interdependencies, work beyond what you'd expect from adding XCAP 
> support.  Throughout the server, the code uses exact matching of URLs to 
> figure out what to do -- not URL pattern matching. So for example:
>  - The way ETags were generated and stored and changed would have to be 
> thrown out because ETags were generated independently for every resource.
>  - Since resources were independent, write requests for different 
> resources could be handled concurrently with ease, but that would have 
> to change.

The proof is in the implementations; we have a few already, and those 
folks have posted here that they havent seen these problems.

> 
> 2b) How interdependencies work within existing HTTP extensions: For one, 
> somebody would have to write a specification for how the existing access 
> control standard (RFC 3744) might work with XCAP.  Since XCAP can have 
> two different URLs that point to the same underlying piece of data, what 
> does it mean to apply certain access control settings to either or both 
> of those URLs?

Its a good question, but not one new to this application. Certainly 
other http applications may require a client to obtain multiple locks in 
order to make a change across several resources that they require to 
affect. Same would be true here.

> 
> I haven't examined every feature of HTTP and its extensions to see how 
> well it deals with interdependencies, but that's a sampling.
> 
> 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 think that the PUT issue is a small detail, but there is a much more 
fundamental problem with what you are proposing.

The whole idea of xcap is that you can PUT a section of the xml document 
to the server, and that this made sense because the resource you were 
PUTting to *was* section of the xml document you want to affect. The URL 
referred to that resource. Thus, it is fundamental that the resources 
that we are manipulating are the various pieces of the overarching xml 
document. Your complaint is not that we are using a query string instead 
of a path separator, but that the *resource* is the document 
sub-components instead of the document itself. As such, changing xcap so 
that the only resource is the document is a fundamental architectural 
change. The fact that a PUT with query parameters might not work is 
symptomatic of the problem with this approach, and I suspect there are 
others.

Jamie Lokier wrote:
> Lisa Dusseault wrote:
> 
>>> If you have multiple changes to make to a 1 MB or smaller document, 
>>> batch them up together if possible, even if it requires uploading the 
>>> whole document afresh.  The current design of XCAP encourages changes 
>>> to be made independently, and each change will require a full 
>>> round-trip (no pipelining possible because you need to wait for the 
>>> server to respond with an ETag each time).
> 
> 
> That seems like a flaw which should be fixed.

I have to disagree with Lisa here, this is not a constraint on xcap. You 
do not have to wait for the etag to send the next request. You only have 
to wait for the etag if you wish your next change to be conditioned on 
the fact that the document hasn't been modified since your last change. 
That's true of http generally, and true here too - its the defining 
purpose of the If-* headers. The various application usages talk about 
ways in whcih the documents are structured so that one doesn't need to 
used conditional PUts'. In that case, feel free to pipeline.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Dec 2004 22:14:39 -0500

Julian Reschke wrote:
> KAWAGUTI Ginga wrote:
> 
>> ...
>> XCAP's target document is usually written in UTF-8(it's XML),
> 
> 
> Unless XCAP says something normative, it could be any encoding. As far 
> as I can tell, the actual decoding doesn't matter at all as long as it 
> is one of the XML required ones (thus UTF-8 or UTF-16).
> 
>> 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.
> 
> 
> No matter what encoding the document uses, XCAP needs to define that 
> mapping (and yes, that mapping needs to be based on UTF-8).

This is a good point; I've gotten a private comment about this as well. 
I think the simplest thing is to normatively state that all XML 
documents managed by XCAP have to be utf-8 encoded. In terms of a 
mapping from UTF-8 strings into a URI, can you clarify why this is hard? 
Isn't it just a matter of escape-coding the octet sequence associated 
with non-ascii characters (I admit this is not my area of expertise and 
I likely am missing something here).

-Jonathan R.

---

From: "Kawaguti Ginga" <[email-masked]>
Date: Mon, 06 Dec 2004 11:07:11 +0900

In Sat, Dec 04, 2004 at 10:44:41AM +0100,
Julian Reschke <[email-masked]> wrote:
> That may be a bad choice if lots of your data is in characters that need 
> multi-byte sequences, in which case UTF-16 may be more efficient. I 
> think XCAP should simply stick with what XML requires (which is UTF-8 
> and UTF-16, nothing more).

I agree that "hard-assumption of UTF-8 usage" is a bad choice.
UTF-8 is only a DEFAULT encoding for XML standard.
Yes it is recommended to use UTF-8, but there are many other XML documents
based on other encodings (not only UTF-16, but many more).

If XCAP is intended to be very specific protocol only for
some limited XML documents, then "all documents are UTF-8(and/or UTF-16)" 
assumption might work, but it's a bad idea for general protocol design.

There are many ways to specify encodings in a XCAP-only-way,
like appending "http://.../...?encoding=utf-8?...",
but they're not HTTP-standard way.

And something more, URL string size limitation.
"% encoded" UTF-8 string might suffer even more on this restriction.

Julian's previous mail:
> > 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.
> 
> Don't understand. How are you sending the document selector inside the 
> request body for PUT?

For generic HTTP PUT, there's no way, as denoted in your comment.
My consideration was to use something like SOAP envelope.
It shouldn't be "PUT" anymore, and it should be used over
some original rule anyway.

Regards,
Ginga Kawaguti

-- 
Office:  NTT Communications Innovative IP Architecture Center 1PT 1P
Address: KAWAGUTI Ginga <[email-masked]>
Phone:   voice=+81-3-6800-3032; fax=+81-3-5388-0550

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Dec 2004 10:44:41 +0100

> I likely am missing something here).

This isn't hard, one just needs to define it.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Dec 2004 14:00:40 +0100

Jonathan Rosenberg wrote:
>> support.  Throughout the server, the code uses exact matching of URLs 
>> to figure out what to do -- not URL pattern matching. So for example:
>>  - The way ETags were generated and stored and changed would have to 
>> be thrown out because ETags were generated independently for every 
>> resource.

And anyway (already pointed out earlier), an HTTP server that supports 
WebDAV namespace operations already can't handle etags on a per-resource 
basis. That approach simply doesn't work.

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 5 Dec 2004 17:20:43 +0000

> the resources are small - because they may be dynamic. This is an issue 

xcap resources may overlap, and that means they share content.  This
content has to be duplicated in the HTTP caching model, and that is a
sense where some usages don't scale optimally.

It would be hard to design a caching model which did scale optimally.

> used conditional PUts'. In that case, feel free to pipeline.

In other words, you can only batch a group of small updates when you
want to apply them unconditionally.

The usual way to update a resource where data should never be lost or
the update is logically an atomic data-dependent operation is to do
them conditionally, using If-* headers.

This works fine in HTTP for updating a single resource.

It also works fine in HTTP for updating parts of a resource, when
using the not yet standardised PATCH operation.

But with XCAP, when a group of small updates is to be applied
conditionally, then a round trip time will be incurred between each
small update.

This is very slow for many small updates.  Combining the updates to
simply write a large portion of a resource does not scale if it's a
very large resource and only small, sparse updates are required
(e.g. when updating an entry an an XML database).

The suggested workaround is to restructure the XML documents so that
updates are done unconditionally.

In other words, things like XML databases would be wrapped in some
kind of "front end" such that the view seen through XCAP doesn't
correspond directly with the tree structure of the underlying data
resource.  A transformed view allows unconditional PUTs to be
translated to atomic logical operations on the underlying data resource.

This seems to me to defeat much of the point of XCAP, which is to
remove the need for application-specific APIs for accessing and
updating data resource parts.

It is not hard to think up solutions which allow updates of many small
parts of an XCAP as one effective operation.

Because atomic updates are useful, it would make sense to do compound
updates in a single HTTP operation.  Merely finding a way to pipeline
the updates would _not_ be adequate.

The obvious methods are to define a compound update PUT form,
e.g. using multipart/something, or to propose an extension to XCAP
which uses PATCH.

It would be generally useful to have a PATCH format which is good for
updating parts of XML documents, but that is probably best left as
another engineering problem.

Meanwhile, a multipart/something PUT form would be quite easy to
define, and it could be an optional but recommended feature.

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 09:14:18 +0100

> UTF-8 is only a DEFAULT encoding for XML standard.

...it is one of two required encoding...

> based on other encodings (not only UTF-16, but many more).

No, it's not in any way "more" recommended than UTF-16.

> assumption might work, but it's a bad idea for general protocol design.

You need to make this assumption for full portability. These are the 
only encodings a conforming XML parser has to understand.

> but they're not HTTP-standard way.

Why would you want to do that? Anyway: if you really need to, you can 
use the Accept-Charset request header 
(<http://greenbytes.de/tech/webdav/rfc2616.html#header.accept-charset>).

> "% encoded" UTF-8 string might suffer even more on this restriction.

Even more than what? What alternative are you proposing?

> some original rule anyway.

But then we're not talking about an HTTP *application* anymore, but only 
about tunneling *through* HTTP.

Best regards, Julian