Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jun 2006 13:02:17 +0200

I noticed that the ID tracker now has a comment from the authors (see 
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=52124>), 
which I'd like to comment over here...:

> 	Author's response to Last Call comments on ETags
> 
> 1) Best common practice in WebDAV
> 
> Currently very few, if any at all, WebDAV servers change the content of resource data during a PUT request. Most WebDAV servers do return an ETag on PUT. Thus clients have come to rely on the presence of the ETag to effectively mean that the resource data was stored unchanged and that the ETag can be used in subsequent GET requests etc. This justifies our statement that servers SHOULD return an ETag in a response when the data has not changed.

I have my doubts that this statement is based on actual testing. In 
particular it seems to me that making claims about "most" servers isn't 
useful here; servers that do rewrite content do exist, but they are 
certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs 
which implement WebDAV as a "dumb" store (in that they don't support 
special semantics on specific content types). But that doesn't mean that 
being incompatible with that class of servers (being fully compliant to 
RFC2616 and RFC2518) is acceptable.

That being said, I just tested:

- Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT

- Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT

- Xythos WFS (on www.sharemation.com): ETag returned

- SAP Netweaver KM: ETag returned although content may be rewritten

It seems to me that this shows that the statement above is misleading.

> Now we have CalDAV servers where the resource data MAY be changed. Therefore to be compatible with existing client behavior a server MUST NOT send the ETag in a PUT response when the data changes, otherwise clients will misinterpret it. This justifies our 'MUST NOT' statement.

It would be helpful if you could provide an example of a *shipping* 
client that breaks if an ETag is returned upon PUT although content was 
rewritten.

> 2) Restricted behavior
> 
> The ETag behavior we are talking about is restricted solely to calendar object resources being stored in calendar collections - i.e. it is very specific to CalDAV. This is not 'redefining' HTTP behavior by rather extending it for this one specific application need.

But it's still an HTTP and WebDAV resource. A CalDAV server that also 
happens to be a generic WebDAV server may need to make this a special 
case then. And this may be hard to do should there be another 
HTTP/WebDAV related specification making an incompatible requirement.

As a matter of fact, in February the IESG has decided to solve that very 
problem in a separate activity (see draft-whitehead-http-etag-00), 
independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the 
revision of WebDAV) delegates resolution of the question to that very 
spec, instead of coming up with it's own. This is what CalDAV should 
also be doing.

> 3) Future conflicts
> 
> One of Julian's arguments is that our requirement will "risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter)". Since we have been careful to require only behavior that already exists in deployed WebDAV servers, CalDAV adds no further incompatibility. If future work to better define the meaning of ETag on PUT ever happens, it will need to take into account the deployed base, and the subset of CalDAV servers will simply happen to be a consistently behaving subset. We believe that our requirements improve the interoperability of CalDAV, without making the future/potential incompatibility problem any worse than it already is.

See notes above. The behavior required by CalDAV is *not* what current 
servers do. At least not the majority.

> 4) Need/usefulness
> 
> In addition to the authors' evaluation of the usefulness of this feature for keeping an offline calendar correct, there have been other requests for predictable behavior w.r.t. PUT and ETags and calendar resources. This was one of the first feature requests from client implementors, including Dan Mosedale and Grant Baillie.

I totally agree that clients may be interested in finding out whether 
content was rewritten. The solution to this is to either put more energy 
into draft-whitehead-http-etag-00, or to have a CalDAV-specific solution 
  that by design wouldn't interfere with what we define in other specs 
later, as outlined in 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html>. 
  I'd really like to here why the solution suggested back then isn't 
sufficient for CalDAV.

Best regards, Julian

---

From: Peter Dambier <[email-masked]>
Date: Thu, 15 Jun 2006 12:00:14 +0000

Julian Reschke wrote:
>> Currently very few, if any at all, WebDAV servers change the content 
>> of resource data during a PUT request. Most WebDAV servers do return 
>> an ETag on PUT. Thus clients have come to rely on the presence of the 
>> ETag to effectively mean that the resource data was stored unchanged 
>> and that the ETag can be used in subsequent GET requests etc. This 
>> justifies our statement that servers SHOULD return an ETag in a 
>> response when the data has not changed.
> 

I am one user of webdavs://mediacenter.gmx.net/

I dont know how many subscribers they serve but they are one of the biggest
ISPs in germany. They belong to United Internet, 1und1, GMX and Schlund.

I dont know what they use but I guess Appache and Linux.

They do change content.

I am running Konqueror on Linux and I can both move and copy documents using
drag and drop. I can delete or rename using the mouse and I can edit and
write back using the browsers builtin editor.

I cannot see ETag flag from my userinterface. But my browser shows me
the before and after. So normally I can see if anything has changed.

>> Now we have CalDAV servers where the resource data MAY be changed. 
>> Therefore to be compatible with existing client behavior a server MUST 
>> NOT send the ETag in a PUT response when the data changes, otherwise 
>> clients will misinterpret it. This justifies our 'MUST NOT' statement.
> 
> 
>> The ETag behavior we are talking about is restricted solely to 
>> calendar object resources being stored in calendar collections - i.e. 
>> it is very specific to CalDAV. This is not 'redefining' HTTP behavior 
>> by rather extending it for this one specific application need.
> 
> 
>> One of Julian's arguments is that our requirement will "risk making 
>> CalDAV incompatible with other specs extending HTTP (or HTTP itself, 
>> for that matter)". Since we have been careful to require only behavior 
>> that already exists in deployed WebDAV servers, CalDAV adds no further 
>> incompatibility. If future work to better define the meaning of ETag 
>> on PUT ever happens, it will need to take into account the deployed 
>> base, and the subset of CalDAV servers will simply happen to be a 
>> consistently behaving subset. We believe that our requirements improve 
>> the interoperability of CalDAV, without making the future/potential 
>> incompatibility problem any worse than it already is.
> 
> 
>> In addition to the authors' evaluation of the usefulness of this 
>> feature for keeping an offline calendar correct, there have been other 
>> requests for predictable behavior w.r.t. PUT and ETags and calendar 
>> resources. This was one of the first feature requests from client 
>> implementors, including Dan Mosedale and Grant Baillie.
> 
> 

Kind regards
Peter and Karin Dambier

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 15 Jun 2006 09:32:51 -0700

I agree with Julian.

   As we've mentioned before, Apache returns a weak ETag on PUT,  
which turns into a strong ETag sometime later.  If clients rely on  
being able to use that ETag on a GET later, they won't work with  
Apache, and IIRC, Apache is pretty popular.

   The ETag requirements in the draft are what many clients authors  
might *like* to be the common case, but it is most certainly not so  
today.

   Additionally, the draft doesn't just say that servers SHOULD  
return an ETag in a response when the data has not changed, but also  
that they MUST NOT do so if the data did change.  It's not entirely  
clear that this is the direction things will go, and any MUST  
requirements which conflict with whatever we do come up with later  
will be a real headache.

	-wsv

On Jun 15, 2006, at 4:02 AM, Julian Reschke wrote:

> I noticed that the ID tracker now has a comment from the authors  
> (see <https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_comment&id=52124>), which I'd like to comment over  
> here...:
>
>> Currently very few, if any at all, WebDAV servers change the  
>> content of resource data during a PUT request. Most WebDAV servers  
>> do return an ETag on PUT. Thus clients have come to rely on the  
>> presence of the ETag to effectively mean that the resource data  
>> was stored unchanged and that the ETag can be used in subsequent  
>> GET requests etc. This justifies our statement that servers SHOULD  
>> return an ETag in a response when the data has not changed.
>
> particular it seems to me that making claims about "most" servers  
> isn't useful here; servers that do rewrite content do exist, but  
> they are certainly outnumbered *installation-wise* by IIS and  
> Apache/moddav/fs which implement WebDAV as a "dumb" store (in that  
> they don't support special semantics on specific content types).  
> But that doesn't mean that being incompatible with that class of  
> servers (being fully compliant to RFC2616 and RFC2518) is acceptable.
>
>> Therefore to be compatible with existing client behavior a server  
>> MUST NOT send the ETag in a PUT response when the data changes,  
>> otherwise clients will misinterpret it. This justifies our 'MUST  
>> NOT' statement.
>
> client that breaks if an ETag is returned upon PUT although content  
> was rewritten.
>
>> 2) Restricted behavior
>> calendar object resources being stored in calendar collections -  
>> i.e. it is very specific to CalDAV. This is not 'redefining' HTTP  
>> behavior by rather extending it for this one specific application  
>> need.
>
> But it's still an HTTP and WebDAV resource. A CalDAV server that  
> also happens to be a generic WebDAV server may need to make this a  
> special case then. And this may be hard to do should there be  
> another HTTP/WebDAV related specification making an incompatible  
> requirement.
>
> As a matter of fact, in February the IESG has decided to solve that  
> very problem in a separate activity (see draft-whitehead-http- 
> etag-00), independently of WebDAV and CalDAV. And, indeed,  
> RFC2518bis (the revision of WebDAV) delegates resolution of the  
> question to that very spec, instead of coming up with it's own.  
> This is what CalDAV should also be doing.
>
>> 3) Future conflicts
>> One of Julian's arguments is that our requirement will "risk  
>> making CalDAV incompatible with other specs extending HTTP (or  
>> HTTP itself, for that matter)". Since we have been careful to  
>> require only behavior that already exists in deployed WebDAV  
>> servers, CalDAV adds no further incompatibility. If future work to  
>> better define the meaning of ETag on PUT ever happens, it will  
>> need to take into account the deployed base, and the subset of  
>> CalDAV servers will simply happen to be a consistently behaving  
>> subset. We believe that our requirements improve the  
>> interoperability of CalDAV, without making the future/potential  
> See notes above. The behavior required by CalDAV is *not* what  
> current servers do. At least not the majority.
>
>> 4) Need/usefulness
>> feature for keeping an offline calendar correct, there have been  
>> other requests for predictable behavior w.r.t. PUT and ETags and  
>> calendar resources. This was one of the first feature requests  
>> from client implementors, including Dan Mosedale and Grant Baillie.
>
> I totally agree that clients may be interested in finding out  
> whether content was rewritten. The solution to this is to either  
> put more energy into draft-whitehead-http-etag-00, or to have a  
> CalDAV-specific solution  that by design wouldn't interfere with  
> what we define in other specs later, as outlined in <http:// 
> lists.osafoundation.org/pipermail/ietf-caldav/2006-April/ 
> 000787.html>.  I'd really like to here why the solution suggested  
> back then isn't sufficient for CalDAV.
>
>
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 19 Jun 2006 12:32:53 -0700

> might *like* to be the common case, but it is most certainly not so  

It's worse than that; many client authors *assumed* that to be the  
case, and implemented and deployed their clients assuming that if the  
client receives a strong ETag in response to a PUT, it has no further  
work to do to synchronize that resource.  So the deployed base says  
that *is* the case today.  I don't feel our document makes this  
situation any worse than the deployed base of clients already does.

Lisa

> return an ETag in a response when the data has not changed, but  
> also that they MUST NOT do so if the data did change.  It's not  
> entirely clear that this is the direction things will go, and any  
> MUST requirements which conflict with whatever we do come up with  
> later will be a real headache.
>
> 	-wsv
>
>
>>> content of resource data during a PUT request. Most WebDAV  
>>> servers do return an ETag on PUT. Thus clients have come to rely  
>>> on the presence of the ETag to effectively mean that the resource  
>>> data was stored unchanged and that the ETag can be used in  
>>> subsequent GET requests etc. This justifies our statement that  
>>> servers SHOULD return an ETag in a response when the data has not  
>>> changed.
>>
>> I have my doubts that this statement is based on actual testing.  
>> In particular it seems to me that making claims about "most"  
>> servers isn't useful here; servers that do rewrite content do  
>> exist, but they are certainly outnumbered *installation-wise* by  
>> IIS and Apache/moddav/fs which implement WebDAV as a "dumb" store  
>> (in that they don't support special semantics on specific content  
>> types). But that doesn't mean that being incompatible with that  
>> class of servers (being fully compliant to RFC2616 and RFC2518) is  
>> acceptable.
>>
>>> Now we have CalDAV servers where the resource data MAY be  
>>> changed. Therefore to be compatible with existing client behavior  
>>> a server MUST NOT send the ETag in a PUT response when the data  
>>> changes, otherwise clients will misinterpret it. This justifies  
>>> our 'MUST NOT' statement.
>>
>> It would be helpful if you could provide an example of a  
>> *shipping* client that breaks if an ETag is returned upon PUT  
>> although content was rewritten.
>>
>>> 2) Restricted behavior
>> As a matter of fact, in February the IESG has decided to solve  
>> that very problem in a separate activity (see draft-whitehead-http- 
>>> servers, CalDAV adds no further incompatibility. If future work  
>>> to better define the meaning of ETag on PUT ever happens, it will

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jun 2006 21:41:17 +0200

Lisa Dusseault schrieb:
>>   As we've mentioned before, Apache returns a weak ETag on PUT, which 
>> turns into a strong ETag sometime later.  If clients rely on being 
>> able to use that ETag on a GET later, they won't work with Apache, and 
>> IIRC, Apache is pretty popular.
>>
> It's worse than that; many client authors *assumed* that to be the case, 
> and implemented and deployed their clients assuming that if the client 
> receives a strong ETag in response to a PUT, it has no further work to 
> do to synchronize that resource.  So the deployed base says that *is* 
> the case today.  I don't feel our document makes this situation any 
> worse than the deployed base of clients already does.
> 
> Lisa

Again: do you have any evidence of *shipping* clients making that 
assumption?

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 19 Jun 2006 12:58:28 -0700

Sure, OK, so some clients are broken today because they make some  
assumptions that are only valid on some server implementations.

   We know we need a solution; I just don't agree that CalDAV is the  
right place to specify it.  I do understand how it's convenient.

	-wsv

On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote:

> case, and implemented and deployed their clients assuming that if  
> the client receives a strong ETag in response to a PUT, it has no  
> further work to do to synchronize that resource.  So the deployed  
> base says that *is* the case today.  I don't feel our document  
> makes this situation any worse than the deployed base of clients  
> already does.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Jun 2006 08:11:47 -0700

Xythos WFC and Chandler (the Zanshin library that does WebDAV in  
python) behave this way and make the assumption I describe.  How else  
would you expect a caching or synching client to behave after doing a  
PUT, when the implementors of those clients were pretty sure that  
WebDAV servers stored the content without mucking with it?

Your turn now:  do you have an example of a general-purpose (e.g.  
file sharing, site synch)  shipping client that handles ETags and  
caches or synchronizes content, which does a full GET of the content  
immediately after PUT even if it receives a strong ETag?

Even if there are such clients, the behavior we describe avoids nasty  
errors on both such clients and clients like WFC.  It's the  
conservative choice.

Lisa

On Jun 19, 2006, at 12:41 PM, Julian Reschke wrote:

>>> which turns into a strong ETag sometime later.  If clients rely  
>>> on being able to use that ETag on a GET later, they won't work  
>>> with Apache, and IIRC, Apache is pretty popular.
>>>
>>>   The ETag requirements in the draft are what many clients  
>>> authors might *like* to be the common case, but it is most  
>>> certainly not so today.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Jun 2006 08:13:44 -0700

Wilfredo, does it make a difference that CalDAV specifies special  
ETag behavior only on Calendar Component resource items (not for all  
HTTP resources)?

lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Jun 2006 18:56:44 +0200

Lisa Dusseault schrieb:
> 
> Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) 
> behave this way and make the assumption I describe.  How else would you 
> expect a caching or synching client to behave after doing a PUT, when 
> the implementors of those clients were pretty sure that WebDAV servers 
> stored the content without mucking with it?

Chandler is not released and obviously operating based on what the 
CalDAV spec currently says.

Regarding the Xythos client: I just did some tests, and as far as I can 
tell the behavior is the same independantly of whether the server 
returns an ETag in PUT: the client always assumes that content was not 
rewritten, and in the absence of an ETag uses the Last-Modified date to 
check. So it seems that it doesn't handle content-rewriting servers at 
all, right? (one needs to manually purge the cache to get the actual 
content).

> Your turn now:  do you have an example of a general-purpose (e.g. file 
> sharing, site synch)  shipping client that handles ETags and caches or 
> synchronizes content, which does a full GET of the content immediately 
> after PUT even if it receives a strong ETag?

No. And I don't think it necessarily needs to, unless it assumes that it 
can use the ETag in subsequent GET/Byte-Range operations.

> errors on both such clients and clients like WFC.  It's the conservative 
> choice.

Well, it's a broken choice. There are servers that rewrite content and 
still return ETags upon PUT, and HTTP allows them do that.

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 20 Jun 2006 10:27:39 -0700

Not really, no.

   HTTP defines ETag.  An HTTP server should be able to use the same  
ETag logic on all HTTP resources, and not treat ETags for calendar  
resources differently than others.  Not all users of ETags are going  
to be aware that calendar resources are special.

   My concern is that if there is *any* inconsistency between the  
general solution when it comes and CalDAV's, that an implementor may  
have to choose between being compliant with CalDAV or the more  
general ETag spec, or may have to continue to implement special  
semantics on calendar resources for purposes which are better served  
by the other spec.

   I realize that "the other spec" doesn't exist today, and that this  
is a total drag.  Can't we take your one paragraph and put it into  
its own document?  I don't know IETF process very well, so I don't  
know what the next steps should be, but as an implementor, I'm  
uncomfortable with the prospect of dealing with two independently  
written specifications for the same behavior.

	-wsv

On Jun 20, 2006, at 8:13 AM, Lisa Dusseault wrote:

> ETag behavior only on Calendar Component resource items (not for  
> all HTTP resources)?

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Jun 2006 16:55:52 -0700

On Jun 20, 2006, at 9:56 AM, Julian Reschke wrote:

>> python) behave this way and make the assumption I describe.  How  
>> else would you expect a caching or synching client to behave after  
>> doing a PUT, when the implementors of those clients were pretty  
>> sure that WebDAV servers stored the content without mucking with it?
>
> Regarding the Xythos client: I just did some tests, and as far as I  
> can tell the behavior is the same independantly of whether the  
> server returns an ETag in PUT: the client always assumes that  
> content was not rewritten, and in the absence of an ETag uses the  
> Last-Modified date to check. So it seems that it doesn't handle  
> content-rewriting servers at all, right? (one needs to manually  
> purge the cache to get the actual content).

My assertion was that if a strong ETag is returned, Xythos WFC  
assumes that what it PUT was what the server stored, and it seems you  
agree.  You found that if a Last-Modified is returned instead, WFC  
makes the same assumption -- naturally, they're very similar.

You're probably quite right about the general case, that existing  
WebDAV clients don't handle content-rewriting servers at all.  What's  
the best thing a content-rewriting server can do in this situation?   
I would hope that if a client receives neither an ETag nor a Last- 
Modified in a PUT response, then the next time it synchronizes and  
sees an ETag that it's never seen before, the client downloads the  
resource.  This allows the content to eventually get synchronized  
although perhaps not as fast as would be ideal.

But CalDAV clients will have to handle content-rewriting servers at  
least handling events (calendar component resources), because during  
protocol development we heard from a couple server developers that  
they'd need to add custom iCalendar properties to an event as soon as  
it was stored, thus rewriting the content.

lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Jun 2006 16:59:32 -0700

On Jun 20, 2006, at 10:27 AM, Wilfredo Sánchez Vega wrote:

> resources differently than others.  Not all users of ETags are  
> going to be aware that calendar resources are special.
>
> general solution when it comes and CalDAV's, that an implementor  
> may have to choose between being compliant with CalDAV or the more  
> semantics on calendar resources for purposes which are better  
> served by the other spec.
>
>   I realize that "the other spec" doesn't exist today, and that  
> this is a total drag.  Can't we take your one paragraph and put it  
> into its own document?  I don't know IETF process very well, so I  
> don't know what the next steps should be, but as an implementor,  
> I'm uncomfortable with the prospect of dealing with two  
> independently written specifications for the same behavior.

We basically tried that.  What it turned into was this <http:// 
www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> with  
no consensus on the basic model or apparent drive to come to  
consensus.  Got any feedback on that draft?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jun 2006 02:14:31 +0200

Lisa Dusseault schrieb:
> My assertion was that if a strong ETag is returned, Xythos WFC assumes 
> that what it PUT was what the server stored, and it seems you agree.  
> You found that if a Last-Modified is returned instead, WFC makes the 
> same assumption -- naturally, they're very similar.

It seems that the client always assumes that the server does no 
content-rewriting, no matter what it returns. So it's incorrect to 
assume it makes specific assumptions about ETags on PUTs. It doesn't.

> You're probably quite right about the general case, that existing WebDAV 
> clients don't handle content-rewriting servers at all.  What's the best

Several clients handle it well, because they don't have a local content 
cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP 
Netweaver KM.

> thing a content-rewriting server can do in this situation?  I would hope 
> that if a client receives neither an ETag nor a Last-Modified in a PUT 
> response, then the next time it synchronizes and sees an ETag that it's 
> never seen before, the client downloads the resource.  This allows the 
> content to eventually get synchronized although perhaps not as fast as 
> would be ideal.

As there's no guarantee in HTTP about content rewriting not occurring, 
clients should always re-sync (at some point of time). An optimization 
(which happens to be the one I've been proposing several times now) 
would be a way for the server to indicate that content was *not* 
rewritten, avoiding the additional retrieval.

> they'd need to add custom iCalendar properties to an event as soon as it 
> was stored, thus rewriting the content.

Yes. I'm not sure how this is different from the generic case, though.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jun 2006 02:16:09 +0200

Lisa Dusseault schrieb:
>> have to choose between being compliant with CalDAV or the more general 
>> ETag spec, or may have to continue to implement special semantics on 
>> calendar resources for purposes which are better served by the other 
>> spec.
>>
>> is a total drag.  Can't we take your one paragraph and put it into its 
>> own document?  I don't know IETF process very well, so I don't know 
>> what the next steps should be, but as an implementor, I'm 
> We basically tried that.  What it turned into was this 
> <http://www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> 
> with no consensus on the basic model or apparent drive to come to 

It's a shame we didn't make progress on that, but that doesn't 
invalidate the approach taken (making this an issue orthogonal to 
WebDAV, CalDAV or Atom).

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 21 Jun 2006 10:23:20 -0700

Actually, I remember sending a few emails with feedback on this  
and not getting any replies, and then I went on my honeymoon, so it  
wasn't quite on my mind for a while.

   I think that document is the way to go, even if all it ends up  
saying is something similar to what you have in the CalDAV draft.

	-wsv