Subject: Notes on call from today ...

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Nov 2005 13:29:23 -0800

Things I think agreed on

Where not clear, will use XML Namespace instead of Namespace

on bug 9 - explain allow vendor extension using URL that vendor owns
  token based strings are ok defined in RFC

on bug 39 - use DAV:foo

on bug 11 - need to tell server implementers there are problems with
recursive xml and DOS attacks and they need to consider what to do. MAY
return 400 class error with explanation with what is wrong. MAY just close
connection.

on bug 15 - Cullen need to send question to list

on bug 37 - add back in forward reference to 14 (and perhaps 15)

on bug 43 - Move to using "not wellformed"

on bug 10 - proposal

Go with text based on idea
> 1) On the property element itself: [possible namespace name], [local name],
> [children] of type element or character, plus [attributes] named
> "xml:lang" present on the element itself or it's closest ancestor
> 
> 2) On all children of the property element: [possible namespace name], [local
> name], [attributes] and [children] of type element or character.

add text that points out clients can not count on preservation o comments,
processing instruction

On the topic of namespace, we not going to require that you preserver them
today (because many servers done) but say that future version of spec
probably will require this and server SHOULD do it. Clients SHOULD NOT
assume that servers do it.

Bug 45 - Cache-ability is effected by what we choose here.
Go with.... The client SHOULD not send it unless an standards track
specification requires it. Any specification that requires it need to
carefully consider the cache ability issue if what it is suggesting.

Bug 46 - First sentence or two of 12.2 is unclear. Main point is implementer
knows what get a relative URL, and the answer is that it relative to request
URL. Perhaps ref the the draft on URI handling. Need to loose the term
"single scope". If destination header in the request, then MAY be better to
use absolute instead of any relative. Julian to propose text.

Bug 47 - Will add back in and Lisa will try to clarify. Clients don't have
to implement this.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Nov 2005 14:31:14 +0100

Hi,

two more things.

1) Next call is *tomorrow*, Friday, 9am Pacific time (2005-11-25T17:00Z).

2) We also talked about issue 13 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13>):

I'd like to clarify that yes, I also do prefer resources that support 
strong ETags, and do that upon PUT. I also realize that a huge class of 
clients will have trouble synchronizing when a server behaves differently.

On the other hand, WebDAV is *not* a remote file system protocol. This 
is important!

There is a big spectrum of Web servers that may have WebDAV support, and 
those that effectively can be used as a file system replacement
are only a subset. Baking new requirements into the base spec that would 
make other servers non-compliant is IMHO an extremely bad idea.

For example, vendors (Software AG, Oracle?) have implemented (or may be 
implementing) WebDAV on top of XML-based stores. These stores may 
support strong ETags, but not guarantee octet-for-octet equivalence 
between those things you PUT, and those you'll GET later. This is OK in 
HTTP, and it currently is in WebDAV. Do we really want to make it 
impossible to run WebDAV on top of these stores???

So what I would propose is to

a) agree on a certain set of server features that those clients expect 
(strong ETag on PUT, octet-for-octet identity of representations, ...), then

b) define a profile for WebDAV that covers this, and a simple way for 
clients to discover whether any given resource supports this.

IMHO this definition should go into a separate document. This will also 
  reduce the amount of open issues on RFC2518bis for now.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 24 Nov 2005 13:20:21 -0500

I agree with this proposal.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Nov 2005 12:40:10 -0800

So the usual IETF thought pattern around profiles is say we have might have
profile A and B. Are their clients that want both? Are there reasons a
server would only support one? How will this negation and if a server only
does A and a client wants B, what will the interoperation be like?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Nov 2005 21:51:41 +0100

Cullen Jennings wrote:
> 
> So the usual IETF thought pattern around profiles is say we have might 
> have profile A and B. Are their clients that want both? Are there 
> reasons a server would only support one? How will this negation and if a 
> server only does A and a client wants B, what will the interoperation be 
> like?

Let's call that profile "filestore".

This profile would be a true subset of WebDAV. A server such as Slide 
(to take a real-world example) might want to advertise "filestore" on 
some resources (such as in a FS backend), but not others (such as a 
Tamino XML database).

A client that would absolutely need the features defined as part of the 
"filestore" would simply refuse to interop with some of the resources on 
the server.

IMHO that would still be far better than to forbid servers to implement 
useful WebDAV stuff on resources like these (because that's what a MUST 
or even a SHOULD requirement would essentially mean).

We also should keep in mind that we're in HTTP's area here, because 
we're talking about PUT. We simply can't overrule HTTP here. We *can* 
define a way for servers to advertise that their PUT support fulfills 
certain requirement, so that clients can find out.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Nov 2005 09:22:07 -0800

I have heard that this is wanted for applications other than a  file system.
Right now I was sort of looking for examples of applications that did not
want to use this.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Nov 2005 10:04:55 +0100

> Right now I was sort of looking for examples of applications that did not

I think in this case the question needs to be rephrased: what would 
these clients prefer?

1) keeping the spec as is, meaning that there aren't any guarantees 
about this behaviour

2) changing the spec to mandate this, leading

2a) to some servers claiming to support this, but failing to do so 
(non-compliant implementations), or

2b) to some servers stopping to support WebDAV altogether.

I'd also like to point out again that there is a class of resources that 
simply can't support strong ETags (for instance, WebDAV interfaces to 
XML-Infoset-based databases). Thinking of this, even the SHOULD that we 
have somewhere else in the spec is a very bad decision, and everybody 
should understand that this makes it impossible to maintain WebDAV 
interfaces to certain classes of resources (this is likely to be raised 
during IETF last call, so we better make sure the problem is understood).

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 27 Nov 2005 05:32:34 -0800

Some people have been advocating a profile approach. I am simply trying to
figure out if there are a large contingent of applications for both
profiles. I have heard many applications (much more than just file system)
that would not be impacted by no strong ETags so I am convinced that group
is large, what I am looking for is what are the applications in the other
group that don't care if they get back a weak or strong ETag?

Let me a related questions to client implementers? On the phone call the
other day, knowledgeable server implementers seemed to imply that the right
solution for clients that got bag a weak ETag but needed a strong one was to
poll the server until they got back a strong one. Does any client do that?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 27 Nov 2005 16:59:54 +0100

> group that don't care if they get back a weak or strong ETag?

First of all, I'm not aware of any widely deployed WebDAV clients that 
currently *require* strong ETags, because they wouldn't work with many 
servers. If somebody disagrees here, please provide details.

Furthermore, it seems to me that many still underestimate what requiring 
strong ETags means. Let's see what RFC2616 says...:

'A "strong entity tag" MAY be shared by two entities of a resource only 
if they are equivalent by octet equality.'

(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.11>)

That means that requiring strong ETags rules out *any* kind of server 
that actually doesn't store content binary. Some examples are:

- XML based databases with WebDAV interfaces (Tamino, Oracle?)

- Severs specializing in / optimizing for specific content types (Atom, ICS)

In particular I'm surprised to hear that implementors of CalDAV clients 
expect the servers to provide strong ETags for calendar entries. A 
calendar server that has a ICS store has basically the following options:

- store the binary representation sent with PUT for every entry 
(expensive), or

- do not return an ETag at all after PUT, because the ETag returnen upon 
GET will depend on what the server's default binary representation of 
the calendar object will be (and that's unlikely the same as sent by 
arbitrary clients)

On the other hand, a server that implements RFC2616/RFC2518 would just 
use weak ETags, allowing to reformat the content as long the semantics 
stay the same.

> poll the server until they got back a strong one. Does any client do that?

I would be surprised, because there's no guarantee that this will 
actually work (a server may decide to use weak ETags all the time).

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 27 Nov 2005 14:17:27 -0800

This is all fine but I think I am still far behind you. You keep pointing
out it is impossible to implement but I'm actually  interested in who might
not need it? How can I make my question any more clear that I am not asking
about if current servers implement it or not? I'm just trying to figure out
the practicalities of number of types of application in each camp.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2005 08:27:13 +0100

> the practicalities of number of types of application in each camp.

Well. I thought that was clear from the fact that today you can't rely 
on it. Thus, none of the general purpose WebDAV clients I know of 
(Webfolders, Xythos, MacOSX) seems to need it (implementors, please 
speak up if I'm incorrect here).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 28 Nov 2005 15:10:29 -0800

On Nov 27, 2005, at 7:59 AM, Julian Reschke wrote:
>
> In particular I'm surprised to hear that implementors of CalDAV 
> clients expect the servers to provide strong ETags for calendar 
> entries. A calendar server that has a ICS store has basically the 
> following options:
>
> - do not return an ETag at all after PUT, because the ETag returnen 
> upon GET will depend on what the server's default binary 
> representation of the calendar object will be (and that's unlikely the 
> same as sent by arbitrary clients)

Another option is for the server to store the calendar data in some 
internal format (e.g. nodes) and have a consistent way of constructing 
the entity from that.  As long as the server has an algorithm that 
generates the same bytes each time from the underlying data, it can use 
the same ETag.

It also doesn't matter what format the client sends the event in: the 
ETag refers to the octets the server sends, not to the octets the 
client sends.

It also doesn't matter if the client can request variants: for example, 
a server can keep one ETag around for the iCalendar version of the 
event, and a separate ETag for the xCalendar version of the event if it 
can generate two formats (both consistently).  Both ETags would have to 
change if the event data actually changed, of course.

> use weak ETags, allowing to reformat the content as long the semantics 

How do weak ETags solve this?  What can a client really rely on if the 
weak ETag is the same, or different?  Do you believe a client could 
rely on weak ETags to do synchronization?  Wouldn't we need 
restrictions on what changes could be allowed before the weak ETag had 
to change in order to use weak ETags?

I haven't seen weak ETags be useful to clients except in two cases:
  - possibly for a client doing GET only (not an authoring client, and 
so it doesn't care about obtaining exact copy to author from)
  - a client that has inside information about what a server does -- 
e.g. a client with a coding dependency on the behavior of Apache which 
is to switch from a weak ETag to a strong one.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Nov 2005 10:24:27 +0100

> generates the same bytes each time from the underlying data, it can use 

That's exactly what I just said. But the problem here is that if the 
server does that, it can't return an ETag upon PUT. As far as I can 
tell, returning a strong ETag in the response to PUT signals that the 
server has stored the message body binary, and that the ETag applies to 
that content (not the internally rewritten content the client may see on 
the next GET request).

> ETag refers to the octets the server sends, not to the octets the client 
> sends.

How do you know that? RFC2616 in fact doesn't define at all what an ETag 
in a response to PUT means 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.19>):

"The ETag response-header field provides the current value of the entity 
tag for the requested variant."

Note that PUT doesn't request any representation/variant, thus the text 
doesn't even apply. I guess that's another reason why RFC2518bis MUST 
NOT make any statements about ETags in PUT responses. This really needs 
to be coordinated with the base spec.

> change if the event data actually changed, of course.

That may be true, although "common wisdom" (i.e. afair Roy's) is that 
resources that are content-negotiated better not be authorable.

> weak ETag is the same, or different?  Do you believe a client could rely 
> on weak ETags to do synchronization?  Wouldn't we need restrictions on 

Yes, I would think so.

> what changes could be allowed before the weak ETag had to change in 
> order to use weak ETags?

<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.11>:

"A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two 
entities of a resource only if the entities are equivalent and could be 
substituted for each other with no significant change in semantics. A 
weak entity tag can only be used for weak comparison."

>  - possibly for a client doing GET only (not an authoring client, and so 
> it doesn't care about obtaining exact copy to author from)
>  - a client that has inside information about what a server does -- e.g. 
> a client with a coding dependency on the behavior of Apache which is to 
> switch from a weak ETag to a strong one.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Nov 2005 21:07:29 +0100

Lisa Dusseault wrote:
> I hadn't thought that a client could use weak etags at all for 
> authoring.  I had started from considering the cases of a JPG or a 
> Photoshop file or a Word document.  What does a weak ETag mean for those 
> documents?  If I edit a Word document on a WebDAV server and all I do is 
> fix a couple inconsistent fonts and a space or two, one might think that 
> the weak ETag need not change -- but I would not find the system very 
> usable if these changes were lost on a subsequent update.

Of course it's not always simple to define what "semantically 
equivalent" means. For instance, if a server would take the Word 
document and remove all implementation artefacts (for which there are 
cleanup tools nowadays), I'd call that "semantically equivalent", and a 
useful feature.

Servers like these exist, and making the revision of WebDAV inherently 
incompatible with them IMHO is an extremely bad idea. Fortunately, I'm 
pretty confident that the community wouldn't let us get away with that.

It seems that you have a very specific authoring scenario in mind, which 
you'd like to be simpler to support in a client. How about summarizing 
the *precise* requirements first, then think about the right technical 
approach, and only then discuss a way what to do in the spec? Yes, 
that's more work to do then simply stating "Strong ETags are now 
required", but it's the better approach nevertheless.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 29 Nov 2005 11:49:55 -0800

I hadn't thought that a client could use weak etags at all for 
authoring.  I had started from considering the cases of a JPG or a 
Photoshop file or a Word document.  What does a weak ETag mean for 
those documents?  If I edit a Word document on a WebDAV server and all 
I do is fix a couple inconsistent fonts and a space or two, one might 
think that the weak ETag need not change -- but I would not find the 
system very usable if these changes were lost on a subsequent update.

Lisa

On Nov 29, 2005, at 11:09 AM, Wilfredo Sánchez Vega wrote:

>   Agreed.  If you can only guarantee semantic equivalence and not 
> byte-for-byte equivalence between GETs, you have to must weak etags 
> according to HTTP/1.1.
>
>   A weak etag, as per rfc2616, should sufficient for CalDAV and 
> accurately reflects what's going on in the server if it is generating 
> the iCalendar dynamically.  I don't see why a client can't use that to 
> do sync just fine.  All you care about is whether the etag changes, 
> not whether it's strong or weak, unless you actually need 
> byte-for-byte replication, but I don't know why you would.
>
> 	-wsv
>
>
> On Nov 29, 2005, at 1:24 AM, Julian Reschke wrote:
>
>>>> On the other hand, a server that implements RFC2616/RFC2518 would 
>>>> just use weak ETags, allowing to reformat the content as long the 
>>>> semantics stay the same.
>>> How do weak ETags solve this?  What can a client really rely on if 
>>> the weak ETag is the same, or different?  Do you believe a client 
>>> could rely on weak ETags to do synchronization?  Wouldn't we need 
>>> restrictions on
>>
>> Yes, I would think so.
>>
>> "A "weak entity tag," indicated by the "W/" prefix, MAY be shared by 
>> two entities of a resource only if the entities are equivalent and 
>> could be substituted for each other with no significant change in 
>> semantics. A weak entity tag can only be used for weak comparison."
>

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 29 Nov 2005 13:12:04 -0800

On Nov 29, 2005, at 11:49 AM, Lisa Dusseault wrote:

> those documents?  If I edit a Word document on a WebDAV server and  
> all I do is fix a couple inconsistent fonts and a space or two, one  
> might think that the weak ETag need not change -- but I would not  
> find the system very usable if these changes were lost on a  
> subsequent update.

   As Julian said, the meaning of semantically equivalent is  
important.  The XML rewriting debate with respect to properties we've  
been having is an example of why it's important to define, and  
presumably a similar debate could be had as to whether such rewriting  
of a XML resource body would lend itself to a weak etag match.

   In the case of CalDAV, the iCalendar spec would be the authority  
on semantic equivalence.  If iCalendar says that the order of  
iCalendar properties and subcomponents is semantically meaningful,  
then they need to be preserved.  (Presumably the iCalendar parsers,  
storage, and generators you use would know this and preserve the  
order.)  If not, then for the purposes of iCalendar, changes in order  
are semantically equivalent, and we could probably agree that for  
CalDAV such changed in a <calendar-data> element are equivalent by  
extension.

   It should be noted that we've already agreed that normalizing out  
newlines in iCalendar data within XML is OK, and that variation would  
be semantically equivalent as well as any variations considered  
equivalent in iCalendar.

   CalDAV should probably be explicit about both of these equivalence  
measures as they related to etags.

	-wsv

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 29 Nov 2005 13:28:53 -0800

On Nov 29, 2005, at 12:07 PM, Julian Reschke wrote:

>
> It seems that you have a very specific authoring scenario in mind, 
> which you'd like to be simpler to support in a client. How about 
> summarizing the *precise* requirements first, then think about the 
> right technical approach, and only then discuss a way what to do in 
> the spec? Yes, that's more work to do then simply stating "Strong 
> ETags are now required", but it's the better approach nevertheless.
>
>

First, before discussing the precise requirements I have in mind, I'd 
like to remind you that the "Strong ETags" proposal didn't come from me 
alone, I'm not the only one with requirements.  After the 2002 interop 
where this was first discussed, we had a bunch of list discussion about 
this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov 
28. You were the one who pointed out that solving the problem we were 
discussing required strong ETags, not weak ETags.

The requirements:
  - Clients must be able to interoperate against different server 
implementations with great consistency.  That means that there should 
be very few cases where clients need to determine what the server 
implementation is or what features it supports, or how, before choosing 
between alternative code paths.
  - Clients must be able to be confident, when doing a PUT, that they 
are not overwriting another client's change -- that means that there 
must be some way to compare the state of the resource to the state when 
it was last retrieved.
  - Specifically, this must work for images, HTML pages, office 
documents, etc -- without requiring any different behavior on the part 
of a client.  It would be nice if the server didn't have to care what 
kind of resource it had, as well.
  - It must be possible to write a generic library or remote file 
system, such as WebDAV FS, Xythos WFC or Adobe's library -- one which 
communicates with the WebDAV server on behalf of an application such as 
Word or Photoshop, without requiring overly heavy integration between 
the application and the library.
  - Clients must be able to keep an offline store with content that's 
fairly reliably consistent with what's on the server.  (One problem to 
solve here is for the client to know whether it needs to download a 
resource after a PUT)

I generated these rather off-the-cuff, but I believe that's a good 
start at least.

Lisa

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 29 Nov 2005 14:17:22 -0800

OK, this is a good list.

On Nov 29, 2005, at 1:28 PM, Lisa Dusseault wrote:

> implementations with great consistency.  That means that there  
> should be very few cases where clients need to determine what the  
> server implementation is or what features it supports, or how,  
> before choosing between alternative code paths.

   Semantic equivalence requires an agreement on the meaningful  
features of a resource's content, and presumably not any knowledge of  
the server.  It is of come concern, though, that the former is  
difficult (all servers and clients need to agree on equivalence) and  
that difficultly may cause the latter.

>  - Clients must be able to be confident, when doing a PUT, that  
> they are not overwriting another client's change -- that means that  
> there must be some way to compare the state of the resource to the  
> state when it was last retrieved.

   Weak ETags should be sufficient here, though the behavior might be  
different.  Weak ETags imply that the server knows something about  
semantic equivalence, and the server is telling you that the document  
hasn't meaningfully changed.  If overwriting the other client's  
change is bad, that's presumably because the other client's change  
was meaningful.  So the problem remains in defining what's a  
meaningful change in the context of that resource.

> documents, etc -- without requiring any different behavior on the  
> part of a client.  It would be nice if the server didn't have to  
> care what kind of resource it had, as well.

   Right, and we're OK with how it works with strong etags.  With  
weak etags, if the server knows nothing about the semantics of the  
resource, it shouldn't be issuing a weak etag to you (because that  
would imply that it does know).  If the server does send you a weak  
etag, you know that the server thinks they are equivalent.  Again,  
this means you have to trust the server to actually know.  Clients  
don't generate etags, so the reverse isn't required.

> system, such as WebDAV FS, Xythos WFC or Adobe's library -- one  
> which communicates with the WebDAV server on behalf of an  
> application such as Word or Photoshop, without requiring overly  
> heavy integration between the application and the library.

   In filesystems, the last writer simply wins, and stomping another  
client's change is OK.  Some apps do check if a file changed before  
saving, and they typically use last-modified timestamps for that; I  
don't know any filesystems with an equivalent to ETag.  Perhaps  
that's a bad example.

   But the prior counterpoint stands.  The server is the arbitrator  
here.  If the server says the document didn't meaningfully change,  
then the client should be able to rely on that.

   What I think we need is an example scenario where I GET a  
document, the weak etag didn't change, so I PUT it back on save, but  
in the mean time the document change in a manner that the server  
deemed semantically equivalent, and that's somehow a problem for me.

>  - Clients must be able to keep an offline store with content  
> that's fairly reliably consistent with what's on the server.  (One  
> problem to solve here is for the client to know whether it needs to  
> download a resource after a PUT)

   Same argument.  Server tells you it hasn't changed in a way that  
you care about.

   It may have changed in a way that you don't care about.  Assuming  
it did, why do you need to update your local copy, given that you  
don't care?

   That is, what's a scenario in which the semantics did not change,  
but the client needs to reload the document anyway or should refuse/ 
hesitate to do a PUT?

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Nov 2005 11:53:12 +0100

> this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov 

I guess it would be good if people would just re-read what was discussed 
back then (Dan: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0119.html>, 
myself replying: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0141.html>).

If there was consensus back then, it was for:

1) ETags are good. Strong ETags are better. Optimally, PUT returns a 
strong Etag.

2) Server support for ETags must be consistent (that is, DAV:getetag and 
ETag response header should agree)

Re 1) I don't think there's any disagreement here. The question is how 
to achieve it. Putting SHOULD- or MUST-level requirements into the spec 
without understanding why servers may not be doing it already is IMHO 
the wrong approach.

Re 2) Of course. If that needs clarification in the spec, let's do it.

> discussing required strong ETags, not weak ETags.

What I pointed out was that the requirement you want to make makes 
Apache/mod_dav non-compliant, as it returns weak ETags upon PUT.

> implementations with great consistency.  That means that there should be 
> very few cases where clients need to determine what the server 

Yes. It's good when this is the case. On the other hand, it's also good 
when servers can support WebDAV for a wide range of resource types, not 
just filesystem-like stores.

>  - Clients must be able to be confident, when doing a PUT, that they are 
> not overwriting another client's change -- that means that there must be 
> some way to compare the state of the resource to the state when it was 
> last retrieved.

ETags do that. If a server doesn't support ETags, the client always can 
refuse to update.

On the other hand, as Wilfredo just pointed out, filesystems do not have 
ETags either, and people just live with that (last update wins). So yes, 
it's nice if you can avoid it, but it's unclear why it needs to be a 
WebDAV requirement.

> kind of resource it had, as well.

So are you now requiring that a WebDAV server can store any type of 
binary content? What if it's a WebDAV connector on top of an XML database?

>  - It must be possible to write a generic library or remote file system, 
> such as WebDAV FS, Xythos WFC or Adobe's library -- one which 

It's hard to judge what that actually means protocol-wise.

> solve here is for the client to know whether it needs to download a 

As far as I can tell, the recent discussion on the HTTP mailing list 
shows that ETags do not help with that.

> I generated these rather off-the-cuff, but I believe that's a good start 
> at least.

Best regards, Julian