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

Re: Some thoughts on XCAP's resource architecture

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 24 Nov 2004 23:00:38 +0100
Message-ID: <41A50486.2080708@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Alex Rousskov <rousskov@measurement-factory.com>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>

Lisa Dusseault wrote:
> We're actually on the same page about granularity.  HTTP does not 
> *define* a specific granularity, as you said (and as others have pointed 
> out, many HTTP implementations are capable of handling a very small 
> granularity).  However since HTTP is one of the most widely deployed 
> protocol systems we have, where browsers and intermediaries interact 
> with a wide variety of servers and not just one host server, the 
> practice matters as well as the definition.  And the extensions that 
> have been written to HTTP most definitely assume a larger granularity.
> I thought of another way to describe the resource granularity problem.  
> When we say that something is "An HTTP Resource", here's what we imply 
> (particularly for static, authorable resources):
> A resource can be queried for the current Entity Tag if the server 
> supports ETags.
> A resource has its own last-modified timestamp, and supports the 
> If-Modified-Since and If-Unmodified conditional headers.
> A resource has a Content-Type and a Content-Length, and may have an 
> entity Digest (Content-MD5)
> A resource may be cacheable.

Nit: it's not the resource that has etags and such, it's the resource's 
variants. The assumption that each resource has only a single variant in 
general is incorrect.

 > ...

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 24 November 2004 22:01:27 UTC

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