Subject: Re: [Ietf-caldav] supported-calendar-component-set
From: Wilfredo Sánchez Vega <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Date: Wed, 25 Jan 2006 10:59:46 -0800
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Perfect, thanks.

	-wsv

On Jan 24, 2006, at 5:36 PM, Bernard Desruisseaux wrote:

> Wilfredo,
>
> There is a precondition defined for this purpose. See section
> 5.3.2. Creating Calendar Object Resources:
>
>    Additional Preconditions for PUT within calendar collections:
>
> [...]
>
>       (CALDAV:supported-calendar-component): The resource submitted in
>       the PUT request MUST contain a type of calendar component  
> that is
>       supported in the targeted calendar collection; and
>
> Cheers,
> Bernard
>
> Wilfredo Sánchez Vega wrote:
>>   I'm looking at the example section 5.3.1.2 in draft-09 and I'm   
>> wondering what happens if I send the server one of more component   
>> types in the supported-calendar-component-set that the server  
>> doesn't  support.
>>   Should I expect the server to:
>>    1- Include the component in the supported list anyway
>>       ie. is a server required to store any calendar component type?
>>    2- Silently remove the unsupported components from my list.
>>    3- Return an error.  If so:
>>       a- Which status code? NOT_IMPLEMENTED? FORBIDDEN?
>>       b- There's no pre/postcondition element defined for this   
>> condition AFAICT
>>   In the case of this example, say I'm talking to a to-do server   
>> that knows about VTODO but doesn't know about VEVENT.
>>     Thanks,
>>     -wsv
>> _______________________________________________
>> Ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>

Date: Tue, 24 Jan 2006 20:36:36 -0500
From: Bernard Desruisseaux <[email-masked]>
To: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] supported-calendar-component-set
Cc: CalDAV DevList <[email-masked]>

Wilfredo,

There is a precondition defined for this purpose. See section
5.3.2. Creating Calendar Object Resources:

    Additional Preconditions for PUT within calendar collections:

[...]

       (CALDAV:supported-calendar-component): The resource submitted in
       the PUT request MUST contain a type of calendar component that is
       supported in the targeted calendar collection; and

Cheers,
Bernard

Wilfredo Sánchez Vega wrote:
>   I'm looking at the example section 5.3.1.2 in draft-09 and I'm  
> wondering what happens if I send the server one of more component  types 
> in the supported-calendar-component-set that the server doesn't  support.
> 
>   Should I expect the server to:
> 
>    1- Include the component in the supported list anyway
>       ie. is a server required to store any calendar component type?
> 
>    2- Silently remove the unsupported components from my list.
> 
>    3- Return an error.  If so:
>       a- Which status code? NOT_IMPLEMENTED? FORBIDDEN?
>       b- There's no pre/postcondition element defined for this  
> condition AFAICT
> 
>   In the case of this example, say I'm talking to a to-do server  that 
> knows about VTODO but doesn't know about VEVENT.
> 
>     Thanks,
>     -wsv
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

To: CalDAV DevList <[email-masked]>
From: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Date: Tue, 24 Jan 2006 11:16:05 -0800
Subject: [Ietf-caldav] supported-calendar-component-set

   I'm looking at the example section 5.3.1.2 in draft-09 and I'm  
wondering what happens if I send the server one of more component  
types in the supported-calendar-component-set that the server doesn't  
support.

   Should I expect the server to:

    1- Include the component in the supported list anyway
       ie. is a server required to store any calendar component type?

    2- Silently remove the unsupported components from my list.

    3- Return an error.  If so:
       a- Which status code? NOT_IMPLEMENTED? FORBIDDEN?
       b- There's no pre/postcondition element defined for this  
condition AFAICT

   In the case of this example, say I'm talking to a to-do server  
that knows about VTODO but doesn't know about VEVENT.

	Thanks,
	-wsv

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Recurrence exception without master?
Date: Wed, 18 Jan 2006 12:44:25 +0100
To: CalDAV DevList <[email-masked]>

On 18. Jan 2006, at 02:56 Uhr, Jeffrey Harris wrote:
> Here's what I (naively) would like to do.  Take my original
> every Thursday meeting.  No invitations, just a public calendar.  If
> [email-masked] decides she would like to attend only two  
> occurrences
> (by which I mean individual instances of the expanded recurrence
> pattern), I'd like her to be able store a resource that looks like:
>
> BEGIN:VCALENDAR
[entity containing vevents with recurrence-ids but w/o a rrule follows]

> This resource specifies no recurrence pattern.  I realize that's not
> allowed

What I don't understand is why Jenny doesn't update the resource  
containing the rrule? Why do you need to create a _new_ resource just  
containing the exceptions?

[actually I can imagine situations, eg if the public resource is  
write protected, but in this case you would probably need to resort  
to copy the event and keep it in sync by other means, eg iMIP  
messages to the organizer, which should have write access]

> I just think that's too bad. :)

Well, the rational for that is given in the CalDAV spec very much in  
the beginning of the text :-)

> Chandler doesn't yet have a notion of attendees, so it doesn't really
> help to include an exception to the general rule with a different  
> attendee.

I think I begin to understand what you want to do:

a) you have a rrule event as one resource in a public calendar
    collection

b) you want to store the exceptions (with the different attendee) in
    the private calendar collection of 'Jenny' but keep referring the
    public event by using its UID

Honestly I don't think that this makes a lot of sense for various  
reasons. Instead of doing an unnecessary iCalendar hack like:

> X-OSAF-INCLUDE:FALSE

why not just filter on the attendee field? Sounds like it would be  
the same amount of implementation work and is the correct thing to do  
anyway ...

> I'd like to have an interoperable way to suggest that most of a
> recurring event isn't included, without confusing things by using a
> different UID or specifying a different recurrence pattern.

The interoperable way to determine what events to show for a given  
user is to filter on the attendee.
If a user is not really an attendee of the meeting but is "just  
interested" on changes to the record etc, I would still add the user  
as an attendee with the NON-PARTICIPANT role (so it will be  
irrelevant for scheduling, but still be part of iMIP updates and such).

CalDAV doesn't really help you with keeping events consistent  
_across_ collections. The CalDAV rules (like uid<->resource mapping)  
are all focused on a single collection (correct me if I'm wrong ...).
I think if you want to do cross-collection stuff you need to make  
exact copies and keep them in sync (eg by using iMIP, but automatic  
approaches could also be possible [some agent running in Chandler  
which tracks UIDs and merges them on changes]).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Tue, 17 Jan 2006 17:56:44 -0800
From: Jeffrey Harris <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Recurrence exception without master?
Cc: CalDAV DevList <[email-masked]>

Hi Helge,

>> This passage doesn't specifically forbid a RECURRENCE-ID in the absence
>> of a recurrence rule, but it does implicitly forbid having two
>> occurrences with difference RECURRENCE-IDs without having the event that
>> defines the whole recurrence pattern.
> 
> Its a bit difficult to follow you because you use different terminology
> along your description :-) What do you mean by "occurence" here? I guess
> you refer to resources.

Sorry, I should've been more clear.  The iTIP example confused the
issue.  Here's what I (naively) would like to do.  Take my original
every Thursday meeting.  No invitations, just a public calendar.  If
[email-masked] decides she would like to attend only two occurrences
(by which I mean individual instances of the expanded recurrence
pattern), I'd like her to be able store a resource that looks like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 1//EN
BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RECURRENCE-ID:20060119T104500
SEQUENCE:1
DTSTART:20060119T104500
DTEND:20060119T114500
SUMMARY:OSAF Staff Mtg
END:VEVENT
BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RECURRENCE-ID:20060126T104500
SEQUENCE:2
DTSTART:20060126T104500
DTEND:20060126T114500
SUMMARY:OSAF Staff Mtg
END:VEVENT
END:VCALENDAR

This resource specifies no recurrence pattern.  I realize that's not
allowed, I just think that's too bad. :)

Chandler doesn't yet have a notion of attendees, so it doesn't really
help to include an exception to the general rule with a different attendee.

My workaround for dealing with this use case will likely look something
like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 1//EN

BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RRULE:FREQ=WEEKLY
SEQUENCE:0
DTSTART:20040527T104500
DTEND:20040527T114500
SUMMARY:OSAF Staff Mtg
X-OSAF-INCLUDE:FALSE
END:VEVENT

BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RECURRENCE-ID:20060119T104500
SEQUENCE:1
DTSTART:20060119T104500
DTEND:20060119T114500
SUMMARY:OSAF Staff Mtg
X-OSAF-INCLUDE:TRUE
END:VEVENT

BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RECURRENCE-ID:20060126T104500
SEQUENCE:2
DTSTART:20060126T104500
DTEND:20060126T114500
SUMMARY:OSAF Staff Mtg
X-OSAF-INCLUDE:TRUE
END:VEVENT
END:VCALENDAR

I'd like to have an interoperable way to suggest that most of a
recurring event isn't included, without confusing things by using a
different UID or specifying a different recurrence pattern.

Sincerely,
Jeffrey

Date: Tue, 17 Jan 2006 16:20:03 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Recurrence exception without master?

Hi Doug,

> Many seem to confuse what is sent over the wire with the contents
> of the calendar store.

Indeed, I do confuse these things occasionally.

> You can generate a single instance (NO RRULE) VEVENT/REQUEST
> and send it to anyone.  And it does not need the RRULE or
> RECURRENCE-ID as long as your code knows when it gets
> the REPLY to match it up with what was sent.

iTIP is a little off topic for the caldav list, perhaps this portion of
the discussion should move to a different list.  Since I don't know
which list, I'll continue here, though:

So in iTIP you're saying it's acceptable to send an invitation to a few
instances of a recurring event, but not to all of them, and the VEVENTs
on the wire are allowed to have the same UIDs as the full recurring
event?  I suppose there's no iCalendar idempotency god up in the sky,
but this seems somehow wrong to me.  If not, great.

> Is what really seems to be your problem is tying that
> unique VEVENT back to your store.

Not really.  The problem is that the CalDAV server becomes the source of
truth about events, not my data store.  If I can't express this use case
in valid CalDAV semantics that preserve the identities of events, that
makes things a little more bumpy for me.  Again, I can work around it,
it's certainly not a show stopper.

Sincerely,
Jeffrey

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Recurrence exception without master?
Date: Tue, 17 Jan 2006 20:53:54 +0100
To: CalDAV DevList <[email-masked]>

On Jan 17, 2006, at 20:29, Jeffrey Harris wrote:
> As far as I can tell, this isn't allowed in iTIP, you can't invite
> someone to a subset of a recurring meeting.

Really? Wouldn't that be a regular exception?

> Is the same true of CalDAV
> resources, a resource cannot represent a subset of a recurring event?

A resource cannot contain a (connected) exception for a _different_ 
resource. Exceptions must be stored together with the "master" vevent 
(in the same resource).

> This passage doesn't specifically forbid a RECURRENCE-ID in the absence
> of a recurrence rule, but it does implicitly forbid having two
> occurrences with difference RECURRENCE-IDs without having the event 
> that
> defines the whole recurrence pattern.

Its a bit difficult to follow you because you use different terminology 
along your description :-) What do you mean by "occurence" here? I 
guess you refer to resources.

CalDAV states that all events with the same UID MUST be contained in 
the same HTTP resource (so there is a 1:1 mapping between UIDs and 
relative resource names).

For recurrences that means that a single HTTP resource contains the 
"master" vevent and all vevents for the exceptions, in your case:
---snip---
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 1//EN
BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
DTSTART:20040527T104500
DTEND:20040527T114500
RRULE:FREQ=WEEKLY
SUMMARY:OSAF Staff Mtg
END:VEVENT
BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RECURRENCE-ID:20060119T104500
SEQUENCE:1
ORGANIZER:Mailto:[email-masked]
ATTENDEE;ROLE=CHAIR;PARTSTAT¬CEPTED:Mailto:[email-masked]
ATTENDEE:Mailto:[email-masked]
DTSTART:20060119T104500
DTEND:20060119T114500
SUMMARY:OSAF Staff Mtg
END:VEVENT
END:VCALENDAR
---snap---

Not sure whether this answers your question.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Tue, 17 Jan 2006 12:38:05 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-caldav] Recurrence exception without master?
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020002080807030503020002
Content-Type: multipart/mixed; boundary="------------020804080706020402020609"

This is a multi-part message in MIME format.
--------------020804080706020402020609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Many seem to confuse what is sent over the wire with the contents
of the calendar store.

You can generate a single instance (NO RRULE) VEVENT/REQUEST
and send it to anyone.  And it does not need the RRULE or
RECURRENCE-ID as long as your code knows when it gets
the REPLY to match it up with what was sent.

Is what really seems to be your problem is tying that
unique VEVENT back to your store.

Jeffrey Harris wrote:
> Hi Folks,
> 
> In working on recurrence for Chandler at OSAF, I've come across an
> interesting use case that I think isn't possible with CalDAV.  I'm
> prepared to work around this in Chandler, but I want to make sure this
> won't work.
> 
> Take a recurring meeting.
> 
> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:-//PYVOBJECT//NONSGML Version 1//EN
> BEGIN:VEVENT
> UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
> DTSTART:20040527T104500
> DTEND:20040527T114500
> RRULE:FREQ=WEEKLY
> SUMMARY:OSAF Staff Mtg
> END:VEVENT
> END:VCALENDAR
> 
> Suppose I want to invite [email-masked] to just one occurrence of this
> meeting, say,
> 
> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:-//PYVOBJECT//NONSGML Version 1//EN
> BEGIN:VEVENT
> UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
> RECURRENCE-ID:20060119T104500
> SEQUENCE:1
> ORGANIZER:Mailto:[email-masked]
> ATTENDEE;ROLE=CHAIR;PARTSTAT¬CEPTED:Mailto:[email-masked]
> ATTENDEE:Mailto:[email-masked]
> DTSTART:20060119T104500
> DTEND:20060119T114500
> SUMMARY:OSAF Staff Mtg
> END:VEVENT
> END:VCALENDAR
> 
> As far as I can tell, this isn't allowed in iTIP, you can't invite
> someone to a subset of a recurring meeting.  Is the same true of CalDAV
> resources, a resource cannot represent a subset of a recurring event?
> That's how I interpret the passage:
> 
>    Calendar components with the same UID property value, in a given
>    calendar collection, MUST be contained in the same calendar object
>    resource.  This ensures that all components in a recurrence "set" are
>    contained in the same calendar object resource.  In that case there
>    will be one component without a RECURRENCE-ID property (the component
>    that defines the recurrence pattern) and all the rest will have that
>    property (these are the recurrence exceptions).
> 
> This passage doesn't specifically forbid a RECURRENCE-ID in the absence
> of a recurrence rule, but it does implicitly forbid having two
> occurrences with difference RECURRENCE-IDs without having the event that
> defines the whole recurrence pattern.
> 
> In Chandler, it would be natural to allow someone to subscribe to a
> calendar with a recurring meeting and choose just a few meetings to
> attend, dragging those occurrences into their personal calendar.  As far
> as I can tell, to support this functionality and still sync to a CalDAV
> server, I'll need to make a copy of the exceptions of interest,
> assigning a new UID.
> 
> Sincerely,
> Jeffrey
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------020804080706020402020609
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix
	MSN: [email-masked]
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------020804080706020402020609--

--------------ms020002080807030503020002
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

iDPxJrgHn9GPNi9DV5UU3bSqeOC16+kijCdDbv8zu+M2B1tD7MoUvvdFitEAAAAAAAA--------------ms020002080807030503020002--

Date: Tue, 17 Jan 2006 11:29:03 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] Recurrence exception without master?

Hi Folks,

In working on recurrence for Chandler at OSAF, I've come across an
interesting use case that I think isn't possible with CalDAV.  I'm
prepared to work around this in Chandler, but I want to make sure this
won't work.

Take a recurring meeting.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 1//EN
BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
DTSTART:20040527T104500
DTEND:20040527T114500
RRULE:FREQ=WEEKLY
SUMMARY:OSAF Staff Mtg
END:VEVENT
END:VCALENDAR

Suppose I want to invite [email-masked] to just one occurrence of this
meeting, say,

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 1//EN
BEGIN:VEVENT
UID:829970E6-9865-41F6-8B4A-D672F8F93CC0
RECURRENCE-ID:20060119T104500
SEQUENCE:1
ORGANIZER:Mailto:[email-masked]
ATTENDEE;ROLE=CHAIR;PARTSTAT¬CEPTED:Mailto:[email-masked]
ATTENDEE:Mailto:[email-masked]
DTSTART:20060119T104500
DTEND:20060119T114500
SUMMARY:OSAF Staff Mtg
END:VEVENT
END:VCALENDAR

As far as I can tell, this isn't allowed in iTIP, you can't invite
someone to a subset of a recurring meeting.  Is the same true of CalDAV
resources, a resource cannot represent a subset of a recurring event?
That's how I interpret the passage:

   Calendar components with the same UID property value, in a given
   calendar collection, MUST be contained in the same calendar object
   resource.  This ensures that all components in a recurrence "set" are
   contained in the same calendar object resource.  In that case there
   will be one component without a RECURRENCE-ID property (the component
   that defines the recurrence pattern) and all the rest will have that
   property (these are the recurrence exceptions).

This passage doesn't specifically forbid a RECURRENCE-ID in the absence
of a recurrence rule, but it does implicitly forbid having two
occurrences with difference RECURRENCE-IDs without having the event that
defines the whole recurrence pattern.

In Chandler, it would be natural to allow someone to subscribe to a
calendar with a recurring meeting and choose just a few meetings to
attend, dragging those occurrences into their personal calendar.  As far
as I can tell, to support this functionality and still sync to a CalDAV
server, I'll need to make a copy of the exceptions of interest,
assigning a new UID.

Sincerely,
Jeffrey

From: pnayak <[email-masked]>
To: CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 05 Jan 2006 20:59:46 +0530
Subject: [Ietf-caldav] CalDAV server

Hi 

I am sorry if I am not supposed to send this message in this list.
I would like to know if any CalDAV server is ready as on date. I wanted
this info to test caldav support in 'Evolution' client. 

Thanks
Poornima

From: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis
Date: Wed, 4 Jan 2006 13:23:49 -0800
To: Lisa Dusseault <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

   Well, a better version of that idea is to go ahead and assign  
strong etags, but disallow content changes during the first second  
that file is created.  Weak etags shouldn't be necessary in that case  
at all.

   It does create a situation where a PUT would result in a FORBIDDEN  
response for a short period, not sure how people would feel about  
that.  Perhaps a harder problem is that there are other ways for  
content to change, and you'd have to cover them all.  Unfortunately,  
on some servers, content is modified by software other than the HTTP  
server, so you can't make this guarantee; in those cases you could  
then end up with an unchanged etag backed by changed content, which  
is, I think a more untenable situation than the current one, at least  
for people to whom that might be a usage scenario.

   You could then work around that problem by keeping the "weak etag  
for the first second" logic in place, but then you've got a very  
slight improvement (more in spec, but not in a way that helps any  
existing clients; remember the main complaints are the changed etag  
with not content change and the weak->strong transition, and we'd  
still have these) over the status quo regarding etags, and this new  
baggage of (probably unexpected by clients) FORBIDDEN responses in  
the first second.

	-wsv

On Dec 25, 2005, at 9:15 AM, Lisa Dusseault wrote:

> That does suggest a way for Apache to avoid the within-second  
> overwrite risk: to disallow PUT operations while there's a weak  
> ETag.  That would be consistent with HTTP as far as I can see.  It  
> would still, however, theoretically cause clients to reload the  
> resource content when the server switches to the strong ETag.
>
> lisa
>
> On Dec 24, 2005, at 2:14 AM, Julian Reschke wrote:
>
>> Helge Hess wrote:
>>> On 24. Dez 2005, at 01:31 Uhr, Mike Shaver wrote:
>>>> On 12/22/05, Julian Reschke <[email-masked]> wrote:
>>>>> Apache simply has decided that multiple updates within one  
>>>>> second *are*
>>>>> semantically equivalent.
>>>>
>>>> Do you mean to indicate that such a decision on the part of  
>>>> Apache is
>>>> reasonable, given the requirements of the HTTP specification?  It
>>>> certainly doesn't seem that way to me, but I am probably the  
>>>> biggest
>>>> HTTP dullard on this list, so I'm happy to learn.
>>> Maybe I'm wrong but if I understood Julian correctly Apache will  
>>> ensure that there will be only one PUT in the timeframe of 1s. If  
>>> the server ensures that, a timestamp with 1s granularity should  
>>> be enough for an etag?
>>
>> No, that's not what I intended to say. As far as I know, it  
>> currently allows multiple PUTs.
>>
>> 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
>
> _______________________________________________
> 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: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis
Date: Wed, 4 Jan 2006 13:12:52 -0800
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Dec 24, 2005, at 2:14 AM, Julian Reschke wrote:

>> Maybe I'm wrong but if I understood Julian correctly Apache will  
>> ensure that there will be only one PUT in the timeframe of 1s. If  
>> the server ensures that, a timestamp with 1s granularity should be  
>> enough for an etag?
>
> No, that's not what I intended to say. As far as I know, it  
> currently allows multiple PUTs.

   This is correct.

	-wsv