Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings
From: Helge Hess <[email-masked]>
To: ietf-caldav <[email-masked]>
Date: Sat, 29 Jan 2005 00:53:12 +0100
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

On 29. Jan 2005, at 00:38 Uhr, Dan Mosedale wrote:
> In my mind, the issue is not a matter of optimization, but of readable 
> code.

But isn't that the same reason why dashes are used in the protocol? XML 
is supposed to be human readable/writable for various reasons and 
slashes help with that.

>   My experience has been that less readable code tends to have more 
> bugs.  As you point out, it's too late to fix existing cases of this 
> in WebDAV itself, but by changing the new CalDAV-specific elements, we 
> can at least avoid making the problem worse.  If we do this, then 
> implementors end up having fewer code statements that need to use 
> hard-to-read escape syntaxes.  This should lead, I suspect, to at 
> least slightly less buggy code in the CalDAV implementations written 
> in such environments, which is good for the community as a whole.

It makes it easier for your specific implementation of the XML parser 
which may or may not be a worthwhile reason (IMHO its not).

Personally I would assume that your XML parser could be easily enhanced 
to escape dashes with eg underlines prior calling back to the 
application? Since dashes are regular XML, I would assume that this 
should be in the parser anyway?

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

Date: Fri, 28 Jan 2005 15:38:09 -0800
From: Dan Mosedale <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML	language bindings
Cc: ietf-caldav <[email-masked]>

Cyrus Daboo wrote:

> --On January 28, 2005 9:52:10 AM +0100 Julian Reschke 
> <[email-masked]> wrote:
>
>>> Would people be amenable to replacing hyphenated element names in 
>>> CalDAV
>>>  with non-hyphenated ones, assuming suitably clear ones could be found
>>> and agreed upon?
>>
>>
>> I sympathize with the issue, but hyphen-as-a-separator is almost is a
>> common usage pattern in WebDAV (see RFC3253, RFC3648, RFC3744). So even
>> if you get a small optimization here, you'll be likely to hit similar
>> issues with other XML names in WebDAV in the future. So: you may have to
>> live with it. If it's no showstopper...
>>
>
> The WebDAV ACL spec uses '-' in several places for XML elements (ones 
> which a CalDAV client that wants to do calendar sharing would have to 
> handle), so I am afraid there is really no way of getting around this 
> problem. Both DASL AND DeltaV use '-' in a number of places too, 
> though those aren't required for CalDAV.
>
In my mind, the issue is not a matter of optimization, but of readable 
code.  My experience has been that less readable code tends to have more 
bugs.  As you point out, it's too late to fix existing cases of this in 
WebDAV itself, but by changing the new CalDAV-specific elements, we can 
at least avoid making the problem worse.  If we do this, then 
implementors end up having fewer code statements that need to use 
hard-to-read escape syntaxes.  This should lead, I suspect, to at least 
slightly less buggy code in the CalDAV implementations written in such 
environments, which is good for the community as a whole.

Dan

Date: Fri, 28 Jan 2005 10:46:34 -0500
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, Dan Mosedale <[email-masked]>
Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML	language bindings
Cc: ietf-caldav <[email-masked]>

Hi Julian,

--On January 28, 2005 9:52:10 AM +0100 Julian Reschke 
<[email-masked]> wrote:

>> Would people be amenable to replacing hyphenated element names in CalDAV
>>  with non-hyphenated ones, assuming suitably clear ones could be found
>> and agreed upon?
>
> I sympathize with the issue, but hyphen-as-a-separator is almost is a
> common usage pattern in WebDAV (see RFC3253, RFC3648, RFC3744). So even
> if you get a small optimization here, you'll be likely to hit similar
> issues with other XML names in WebDAV in the future. So: you may have to
> live with it. If it's no showstopper...
>

The WebDAV ACL spec uses '-' in several places for XML elements (ones which 
a CalDAV client that wants to do calendar sharing would have to handle), so 
I am afraid there is really no way of getting around this problem. Both 
DASL AND DeltaV use '-' in a number of places too, though those aren't 
required for CalDAV.

-- 
Cyrus Daboo

Date: Fri, 28 Jan 2005 09:52:10 +0100
From: Julian Reschke <[email-masked]>
To: Dan Mosedale <[email-masked]>
Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings
Cc: ietf-caldav <[email-masked]>

Dan Mosedale wrote:
> ...
> Would people be amenable to replacing hyphenated element names in CalDAV 
>  with non-hyphenated ones, assuming suitably clear ones could be found 
> and agreed upon?

I sympathize with the issue, but hyphen-as-a-separator is almost is a 
common usage pattern in WebDAV (see RFC3253, RFC3648, RFC3744). So even 
if you get a small optimization here, you'll be likely to hit similar 
issues with other XML names in WebDAV in the future. So: you may have to 
live with it. If it's no showstopper...

Best regards, Julian

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

Date: Thu, 27 Jan 2005 17:23:46 -0800
From: Dan Mosedale <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: [Ietf-caldav] hyphens in element names problematic for XML language bindings

A lot of Mozilla's CalDAV implementation is written using E4X, which is 
a way to very conveniently handle XML data from JavaSript (see 
<http://weblog.infoworld.com/udell/2004/09/29.html> for a quick intro). 
  E4X appears to be getting a good reception, and after I've spent a 
bunch of time coding with it, I can see why; it's very convenient. 
Various other languages seem to want in on the XML language-binding fun: 
<http://weblog.infoworld.com/udell/2004/10/13.html#a1094> and 
<http://www.mnot.net/blog/2004/06/23/e4x>.

CalDAV's current use of hyphens in XML element names cause a problem: 
most languages parse a hyphen as the minus operator, and therefore as a 
separate token.  This means that the parser has no way to disambiguate 
whether the user is attempting to subtract two different objects or 
simply access one.

   So in order to use native bindings with any such elements in JS, I 
have to use an explicit namespacing syntax.  For example:

   var C = new Namespace("urn:ietf:params:xml:ns:caldav")
   default xml namespace = C;
   var queryXml = <calendar-query>
                    <calendar-query-result/>
                    <filter>
                      <icalcomp-filter name="VCALENDAR">
                        <icalcomp-filter/>
                      </icalcomp-filter>
                    </filter>
                  </calendar-query>;

   queryXml[0].C::filter.C::["icalcomp-filter"]
	.C::["icalcomp-filter"].@name = "VEVENT";

Note that it's not easy to read, at a glance, exactly what's going on
in the last assignment statement.

If, for the sake of this example, icalcomp-filter were simply named 
compfilter, the final assignment could be written as:

   queryXml[0].filter.compfilter.compfilter.@name = "VEVENT";

which is significantly clearer to the reader.

Assuming that native-XML bindings catch on, which seems pretty likely to 
me, I suspect that most implementors working with it are going to have 
to use similar obfuscating quoting hacks.

Would people be amenable to replacing hyphenated element names in CalDAV 
  with non-hyphenated ones, assuming suitably clear ones could be found 
and agreed upon?

Dan

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 11:46:45 -0800
To: Helge Hess <[email-masked]>
Cc: ietf-caldav DevList <[email-masked]>

> Anyway, you asked for comments and you got mine ;-)
>
> I'm not trying to tell or argue how someone should implement locks or 
> groupware servers, I'm just raising an issue which will hurt a lot of 
> existing OpenSource groupware servers due the legacy design. Feel free 
> to ignore ;-)
>
Yes, thank-you, and we certainly won't ignore your comments.  I was 
glad you were willing to drill down a little on your feedback, that 
helps me understand.

Lisa

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 20:38:16 +0100
To: ietf-caldav DevList <[email-masked]>

On 25. Jan 2005, at 20:23 Uhr, Lisa Dusseault wrote:
> So in order to add locking in this environment, can you add a "check 
> the lock table and respect it" function to each of the loadable 
> modules?

Basically yes.

Though locking is very invasive, eg all user interfaces will need to 
have support for pessimstic locking as well!

> (Yes I understand that's more work but I'm trying to find out if there 
> are more barriers I'm unaware of)  So for example, the Web UI would 
> have to have new logic to respect locks, although it wouldn't 
> necessarily have to have additional logic to create locks.  It could 
> also have additional logic, if you wanted to get fancy, to have the 
> owner of a resource blow away a dead or inappropriate lock.

Yes, I'm not saying its impossible. But its seems to be so much work to 
me that it probably isn't worth the effort (for us). We would only 
supports locks in the WebDAV daemon and accept possible loss of 
information when used from other clients.

> As an aside, another feasible architecture that handles locks 
> (although too late for many existing systems) is to have the WebUI go 
> through a WebDAV interface on its way to the database.

This might be feasable if you write a new system from scratch. Though I 
still doubt that it would make a lot of sense to go through WebDAV if 
the web interface is running on the same machine (if you write from 
scratch, you can just check the lock table as you outlined).

> This could be a WebDAV-aware API that enforced locks, or it could 
> literally be that the Web application formulates WebDAV requests 
> instead of SQL requests.  Getting PROPFIND results in XML makes it 
> rather easy to produce HTML listings.

Yes, this would be interesting to explore. But I think a "Logic layer" 
build with WebDAV in mind would make more sense, the additional 
overhead of HTTP in between might be a bit overly expensive compared to 
direct access to the RDBMS which already deal with multiuser/locking 
issues extremely well.

Anyway, you asked for comments and you got mine ;-)

I'm not trying to tell or argue how someone should implement locks or 
groupware servers, I'm just raising an issue which will hurt a lot of 
existing OpenSource groupware servers due the legacy design. Feel free 
to ignore ;-)

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 20:25:33 +0100
To: ietf-caldav DevList <[email-masked]>

On 25. Jan 2005, at 20:18 Uhr, Elias Sinderson wrote:
> Regarding the notion that other interfaces will be used to access a 
> (DB) repository, one should be very careful. It is astonishingly easy 
> to break things in this fashion (e.g. when a given client does not 
> respect the data model that is enforced at the application protocol 
> level).

Nope, it isn't. Actually its a primary reason why one would use a RDBMS 
system, ACID, right? ;-)

Anyway, as mentioned the daemons do implement the same application 
logic in the OGo case, so the same access behaviour is ensured. Though 
this probably won't hold true for a lot of other servers (and it 
doesn't have to if the database schema is properly setup).

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 11:23:51 -0800
To: Helge Hess <[email-masked]>
Cc: ietf-caldav DevList <[email-masked]>

Yes, I think I do see your point.  I am guessing that in these cases 
the modules that access the database is where the application 
intelligence lives, and the database backend is a vanilla database with 
no special logic based on the contents of the tables.

So in order to add locking in this environment, can you add a "check 
the lock table and respect it" function to each of the loadable 
modules?  (Yes I understand that's more work but I'm trying to find out 
if there are more barriers I'm unaware of)  So for example, the Web UI 
would have to have new logic to respect locks, although it wouldn't 
necessarily have to have additional logic to create locks.  It could 
also have additional logic, if you wanted to get fancy, to have the 
owner of a resource blow away a dead or inappropriate lock.

As an aside, another feasible architecture that handles locks (although 
too late for many existing systems) is to have the WebUI go through a 
WebDAV interface on its way to the database.  This could be a 
WebDAV-aware API that enforced locks, or it could literally be that the 
Web application formulates WebDAV requests instead of SQL requests.  
Getting PROPFIND results in XML makes it rather easy to produce HTML 
listings.

Lisa

On Jan 25, 2005, at 11:11 AM, Helge Hess wrote:

> Hi Lisa,
>
> On 25. Jan 2005, at 19:29 Uhr, Lisa Dusseault wrote:
>> I've implemented a WebDAV server with a DB backend before, and that's 
>> not how I'd recommend doing it :)
>
> I think you misunderstood me. I assume CalDAV will be implemented as 
> an add on to the server. For example the existing web interface will 
> still used the DB backend directly without going through CalDAV or 
> being aware of WebDAV locking.
>
>> One way is to add a table of lock tokens and locked URIs (along with 
>> other information about lock, like owner).  So the server's first 
>> transaction on receiving a LOCK would be to add an entry to this 
>> table.  Close transaction, reply to LOCK.
>
> Everything correct :-) But still the *existing functionality* won't 
> magically use that locking table and adding that kind of WebDAV 
> specific locking support is quite a major change (and one which 
> certainly wouldn't be done in OGo, we would just live with possible 
> overwrites then, its too invasive).
>
>> Slide already does something like this and it's open source, so I 
>> fail to see the connection to why this is a hard requirement for open 
>> source.
>
> I was thinking in the context of available OpenSource groupware 
> servers which want to add CalDAV connectivity, like phpGroupware or 
> OpenGroupware.org of course (or one of the other 200 servers listed in 
> Freshmeat). Most of those servers are RDBMS based and usually come 
> from a web interface background.
>
> Of course pure WebDAV storage servers (like Slide) won't have this 
> issue since WebDAV is the only way to access them.
>
> Consider:
>
>   http://www.opengroupware.org/en/devs/docs/OGoArchitecture.png
>
> the functionality is implemented as loadable modules and will be 
> loaded in each of the five different daemons, so it only needs to be 
> implemented once. But each of the daemons connects to the database 
> separatly and there is no concept of locks, except the one provided by 
> RDBMS transactions.
>
> Most other servers won't even reuse the functionality in their 
> frontends.
>
> See my point?
>
> Greets,
>   Helge
> -- 
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Tue, 25 Jan 2005 11:18:24 -0800
From: Elias Sinderson <[email-masked]>
To: ietf-caldav DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Reply-To: ietf-caldav DevList <[email-masked]>

I'll second Lisas' comments below and add that the approach she outlines 
is very similar to that taken by the Catacomb backend for mod_dav. 
Locking did not present a great deal of difficulty to implement relative 
to other WebDAV features.

Regarding the notion that other interfaces will be used to access a (DB) 
repository, one should be very careful. It is astonishingly easy to 
break things in this fashion (e.g. when a given client does not respect 
the data model that is enforced at the application protocol level).

Cheers,
Elias

Lisa Dusseault wrote:

> I've implemented a WebDAV server with a DB backend before, and that's 
> not how I'd recommend doing it :)
>
> One way is to add a table of lock tokens and locked URIs (along with 
> other information about lock, like owner).  So the server's first 
> transaction on receiving a LOCK would be to add an entry to this 
> table.  Close transaction, reply to LOCK.
>
> Then let's say the server receives a PUT request.  Before applying the 
> PUT, the server must check to see if it's locked, and if it's locked 
> that the correct lock token was provided by the correct principal.  
> Then make the change in transaction #2, close transaction, reply to PUT.
>
> Finally, the server receives UNLOCK.  Remove the lock info in 
> transaction #3, close transaction, reply to UNLOCK.
>
> Slide already does something like this and it's open source, so I fail 
> to see the connection to why this is a hard requirement for open source.
>
> Lisa
>
> On Jan 25, 2005, at 10:18 AM, Helge Hess wrote:
>
>> On Jan 25, 2005, at 19:11, Lisa Dusseault wrote:
>>
>>> From server implementors, it would be good to know if you were 
>>> already planning on supporting locking or would find it onerous.
>>
>>
>> I think for most OpenSource servers this would be a rather hard 
>> requirement since WebDAV won't be the only interface which accesses 
>> the database.
>>
>> So the assumption that an event can be locked would be limited to the 
>> WebDAV interface and you can hardly keep the transaction open for the 
>> whole locking time in RDBMS servers to ensure that no modifications 
>> are done by different (server) frontends.
>>
>> Greets,
>>   Helge 
>

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 20:11:52 +0100
To: ietf-caldav DevList <[email-masked]>

Hi Lisa,

On 25. Jan 2005, at 19:29 Uhr, Lisa Dusseault wrote:
> I've implemented a WebDAV server with a DB backend before, and that's 
> not how I'd recommend doing it :)

I think you misunderstood me. I assume CalDAV will be implemented as an 
add on to the server. For example the existing web interface will still 
used the DB backend directly without going through CalDAV or being 
aware of WebDAV locking.

> One way is to add a table of lock tokens and locked URIs (along with 
> other information about lock, like owner).  So the server's first 
> transaction on receiving a LOCK would be to add an entry to this 
> table.  Close transaction, reply to LOCK.

Everything correct :-) But still the *existing functionality* won't 
magically use that locking table and adding that kind of WebDAV 
specific locking support is quite a major change (and one which 
certainly wouldn't be done in OGo, we would just live with possible 
overwrites then, its too invasive).

> Slide already does something like this and it's open source, so I fail 
> to see the connection to why this is a hard requirement for open 
> source.

I was thinking in the context of available OpenSource groupware servers 
which want to add CalDAV connectivity, like phpGroupware or 
OpenGroupware.org of course (or one of the other 200 servers listed in 
Freshmeat). Most of those servers are RDBMS based and usually come from 
a web interface background.

Of course pure WebDAV storage servers (like Slide) won't have this 
issue since WebDAV is the only way to access them.

Consider:

   http://www.opengroupware.org/en/devs/docs/OGoArchitecture.png

the functionality is implemented as loadable modules and will be loaded 
in each of the five different daemons, so it only needs to be 
implemented once. But each of the daemons connects to the database 
separatly and there is no concept of locks, except the one provided by 
RDBMS transactions.

Most other servers won't even reuse the functionality in their 
frontends.

See my point?

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 10:29:40 -0800
To: Helge Hess <[email-masked]>
Cc: ietf-caldav DevList <[email-masked]>

I've implemented a WebDAV server with a DB backend before, and that's 
not how I'd recommend doing it :)

One way is to add a table of lock tokens and locked URIs (along with 
other information about lock, like owner).  So the server's first 
transaction on receiving a LOCK would be to add an entry to this table. 
  Close transaction, reply to LOCK.

Then let's say the server receives a PUT request.  Before applying the 
PUT, the server must check to see if it's locked, and if it's locked 
that the correct lock token was provided by the correct principal.  
Then make the change in transaction #2, close transaction, reply to 
PUT.

Finally, the server receives UNLOCK.  Remove the lock info in 
transaction #3, close transaction, reply to UNLOCK.

Slide already does something like this and it's open source, so I fail 
to see the connection to why this is a hard requirement for open 
source.

Lisa

On Jan 25, 2005, at 10:18 AM, Helge Hess wrote:

> On Jan 25, 2005, at 19:11, Lisa Dusseault wrote:
>> From server implementors, it would be good to know if you were 
>> already planning on supporting locking or would find it onerous.
>
> I think for most OpenSource servers this would be a rather hard 
> requirement since WebDAV won't be the only interface which accesses 
> the database.
>
> So the assumption that an event can be locked would be limited to the 
> WebDAV interface and you can hardly keep the transaction open for the 
> whole locking time in RDBMS servers to ensure that no modifications 
> are done by different (server) frontends.
>
> Greets,
>   Helge
> -- 
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Whether to require locks
Date: Tue, 25 Jan 2005 19:18:59 +0100
To: ietf-caldav DevList <[email-masked]>

On Jan 25, 2005, at 19:11, Lisa Dusseault wrote:
> From server implementors, it would be good to know if you were already 
> planning on supporting locking or would find it onerous.

I think for most OpenSource servers this would be a rather hard 
requirement since WebDAV won't be the only interface which accesses the 
database.

So the assumption that an event can be locked would be limited to the 
WebDAV interface and you can hardly keep the transaction open for the 
whole locking time in RDBMS servers to ensure that no modifications are 
done by different (server) frontends.

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

To: ietf-caldav DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 25 Jan 2005 10:11:36 -0800
Subject: [Ietf-caldav] Whether to require locks

Cyrus & Bernard & I discussed recently whether to require locking 
support in CalDAV servers, and we thought it would be good to get 
implementor feedback.

Strawman proposal: one approach is to require something less 
complicated than full WebDAV locking.
  - CalDAV servers MUST support WebDAV locking on individual resources.
  - CalDAV servers [MUST or MAY?] support WebDAV locking on collections
  - CalDAV servers MUST allow the LOCK method to work on an unmapped 
URL, but SHOULD simply create a locked empty resource rather than a 
special "null resource" [1]

The obvious drawback to requiring even minimal locking support means 
that CalDAV is more work for servers, particularly servers which have 
an existing installed base to support through some proprietary protocol 
which does not involve locking.

The advantages are kind of scattered, and it depends on the client 
implementation and user model.  We certainly can't gaurantee that all 
clients will use locking because they certainly don't have to and 
simple clients probably won't.   Overall, we don't know exactly what 
benefit each client might get from locking so it's kind of hard to 
evaluate that against the more certain cost of requiring each server to 
implement.  But we know from standards-deployment experience that 
unless most server implementations support a feature, most clients 
won't bother to use it -- the value to the client of using a feature 
like locking goes way down if the client can't rely on the feature 
being available and if the client must have a "plan B" anyway then why 
not abandon plan A.  Still, we can talk about some of the things 
clients might do:

  - It can be frustrating to users to start editing an event that hasn't 
changed, and then before finishing their edits, the event is changed by 
somebody else.  To avoid this, a client might lock the event with a 
short-term lock while it's open in an editing window, and unlock when 
the user is finished or moves to another event without making changes.

  - One way of dealing with the need to create a new event with a new 
name would be to send a LOCK request.  If the request comes back saying 
that an existing resource was created the client can UNLOCK it and try 
again to choose a unique name without harm done.  OTOH if the request 
comes back with "201 Created" status code, then the client knows that 
it did choose a new URL successfully, and can PUT and PROPPATCH the 
event.

  - Some clients might put metadata in the properties.  If that metadata 
is supposed to be consistent with the event body, then the client might 
LOCK the resource before doing PUT and PROPPATCH to increase the 
chances that both write requests can be done together and keep the 
resource consistent.

  - Chandler is thinking about tying events and tasks together -- a task 
which is also an event, it has reminders and "doneness", and start and 
end time, all in one object.  We might choose for best interoperability 
to represent this as a separate VTODO and VEVENT -- two resources with 
a custom property to link them together.  Chandler might want to LOCK 
both of those resources in order to be confident of being able to 
change each of them, when our  local Event+Task is changed.  (We're 
also considering doing this kind of combination with emails, in 
extension of the typical flagged-to-do email example, which would 
require a server that supported not only CalDAV and possibly locking 
but also had a general file sharing space for sharing Email+Task 
objects.)

Thoughts?  From client implementors, it would be good to know if you 
envision use cases for locks. From server implementors, it would be 
good to know if you were already planning on supporting locking or 
would find it onerous.

Lisa

[1]  Note that WebDAV originally required locked null resources -- this 
was a special kind of resource that showed up in listings but 
disappeared whenever the lock expired, and this special kind of 
resource could only support certain methods.  Interoperability testing 
showed that this wasn't necessary, it's actually quite OK for servers 
to accept a LOCK request to an unmapped URL by creating an empty, 
locked resource.  Some servers already support LOCK to an unmapped URL 
in exactly that manner. In these interoperability tests and subsequent 
meetings, we agreed that when WebDAV went to Draft Standard, it should 
simplify locking by removing the concept of special "lock null 
resources" and instead replace them with ordinary, but empty, locked 
resources.

Date: Sun, 23 Jan 2005 11:05:21 +0100
From: Julian Reschke <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: [email-masked]

Scott Carr wrote:
> Julian Reschke said:
> 
>>You're not wrong, just inprecise. Any WebDAV server by definition is an
>>HTTP server, so you can't have something that does WebDAV but not the
>>base HTTP spec.
>>
>>In this particular case, the question probably is whether software that
>>is based on or extends Apache/moddav will be able to do it's own POST
>>processing. I'd be surprised if the answer was "no", but that's
>>something to be checked...
> 
> 
> Ok.  That is what I thought.  I know we won't be removing POST from the
> mix.  What I was wondering is how would the server be able to
> differentiate from a standard POST request, and a CalDav POST request, if
> we went with this method.

If what you call a "standard POST" is whst browser usually do, you can 
distinguish this by the Content-Type header.

Best regards, Julian

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

Date: Sat, 22 Jan 2005 18:05:16 -0600 (CST)
Subject: Re: [Ietf-caldav] Creating Items [ideas]
From: "Scott Carr" <[email-masked]>
To: [email-masked]
Importance: Normal

Julian Reschke said:
> You're not wrong, just inprecise. Any WebDAV server by definition is an
> HTTP server, so you can't have something that does WebDAV but not the
> base HTTP spec.
>
> In this particular case, the question probably is whether software that
> is based on or extends Apache/moddav will be able to do it's own POST
> processing. I'd be surprised if the answer was "no", but that's
> something to be checked...

Ok.  That is what I thought.  I know we won't be removing POST from the
mix.  What I was wondering is how would the server be able to
differentiate from a standard POST request, and a CalDav POST request, if
we went with this method.
-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Sun, 23 Jan 2005 00:58:50 +0100
To: ietf-caldav <[email-masked]>

On 23. Jan 2005, at 00:22 Uhr, Neal Gafter wrote:
> I don't see why there is any problem for the client to select a unique
> resource name for a calendar entry.  The client already has a unique
> name - the VEVENT's UID.  I suggest we simply require that the
> resource's name be the event's UID.

That doesn't really resolve the issue discussed since the same problem 
applies for VEVENT UIDs. But I suppose there seems agreement by 
majority that server maintained identity is not being supported by 
CalDAV and its certainly problematic for iCal UIDs.

I do agree that it might make a lot of sense to require CalDAV 
servers/clients to keep UID and relative URL consistent. Is there 
anything which speaks against that? I suppose it would make both, 
servers and clients easier.

One thing which wouldn't work is dropping an existing ICS file (with 
some arbitary name) into a CalDAV collection using a generic WebDAV 
client. This would need to get rejected by the server (or redirected or 
'relocated' to the contained UID).

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

Date: Sat, 22 Jan 2005 15:22:17 -0800
From: Neal Gafter <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>
Reply-To: Neal Gafter <[email-masked]>

I don't see why there is any problem for the client to select a unique
resource name for a calendar entry.  The client already has a unique
name - the VEVENT's UID.  I suggest we simply require that the
resource's name be the event's UID.

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Sat, 22 Jan 2005 11:09:45 -0800
To: "Scott Carr" <[email-masked]>
Cc: [email-masked]

>
> I understand that we will need to modify the server to support the 
> CalDav
> extensions.  My point about this was what if the server is supposed to
> take care of CalDav and regular HTTP requests on the same folder.  This
> would be difficult to setup, wouldn't it?

It might be OK for CalDAV to change the meaning of POST on a resource, 
as long as the Web server can be modified that way.  Since the HTTP 1.1 
specification doesn't require POST to have any specific behavior on any 
given resource, in theory an extension to HTTP can define POST's 
behavior on certain resources.

And you say "if the server is supposed to take care of CalDAV and HTTP 
requests on the same folder" -- that might indicate some 
misunderstanding-- since CalDAV extends HTTP, a CalDAV server MUST 
handle HTTP requests on all CalDAV resources.

>
> I'll read over the WebDav spec a little more, but I thought the idea of
> WebDav was that you could support both WebDav and HTTP on the same
> folders...

Yes you MUST support WebDAV and HTTP on the same folder -- that means 
all the requirements of HTTP (and not necessarily all the extensions 
and implemenation details of any given HTTP server)

>
> Please, correct me if I am wrong.
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Sat, 22 Jan 2005 20:07:18 +0100
From: Julian Reschke <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: [email-masked]

Scott Carr wrote:
> Cyrus Daboo said:
> 
>>In order to support CalDAV, a WebDAV server is going to have to be
>>modified
>>to support the new CalDAV features such as custom reports, the calendar
>>collection resourcetype and MKCALENDAR (though that method will be
>>optional). As such modifying a server to do something special when POST
>>occurs on a calendar collection is a reasonable thing to do, so I don't
>>think we need to worry about how current servers implement POST - the only
>>thing that is important (and this is only from the server implementor's
>>point of view, not the protocol point of view per se) is how easy it is to
>>hook into the server's processing to do something different with a
>>'standard' method like POST.
> 
> 
> I understand that we will need to modify the server to support the CalDav
> extensions.  My point about this was what if the server is supposed to
> take care of CalDav and regular HTTP requests on the same folder.  This
> would be difficult to setup, wouldn't it?
> 
> I'll read over the WebDav spec a little more, but I thought the idea of
> WebDav was that you could support both WebDav and HTTP on the same
> folders...
> 
> Please, correct me if I am wrong.

You're not wrong, just inprecise. Any WebDAV server by definition is an 
HTTP server, so you can't have something that does WebDAV but not the 
base HTTP spec.

In this particular case, the question probably is whether software that 
is based on or extends Apache/moddav will be able to do it's own POST 
processing. I'd be surprised if the answer was "no", but that's 
something to be checked...

Best regards, Julian

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

Date: Sat, 22 Jan 2005 12:41:28 -0600 (CST)
Subject: Re: [Ietf-caldav] Creating Items [ideas]
From: "Scott Carr" <[email-masked]>
To: [email-masked]
Importance: Normal

Cyrus Daboo said:
> In order to support CalDAV, a WebDAV server is going to have to be
> modified
> to support the new CalDAV features such as custom reports, the calendar
> collection resourcetype and MKCALENDAR (though that method will be
> optional). As such modifying a server to do something special when POST
> occurs on a calendar collection is a reasonable thing to do, so I don't
> think we need to worry about how current servers implement POST - the only
> thing that is important (and this is only from the server implementor's
> point of view, not the protocol point of view per se) is how easy it is to
> hook into the server's processing to do something different with a
> 'standard' method like POST.

I understand that we will need to modify the server to support the CalDav
extensions.  My point about this was what if the server is supposed to
take care of CalDav and regular HTTP requests on the same folder.  This
would be difficult to setup, wouldn't it?

I'll read over the WebDav spec a little more, but I thought the idea of
WebDav was that you could support both WebDav and HTTP on the same
folders...

Please, correct me if I am wrong.

Date: Sat, 22 Jan 2005 11:57:00 -0500
From: Cyrus Daboo <[email-masked]>
To: Scott Carr <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: 

Hi Scott,

--On January 21, 2005 12:49:03 PM -0600 Scott Carr <[email-masked]> 
wrote:

>> Typically, POST requests to "live Web Servers" are only handled by
>> code that generates dynamic responses if the Request-URI identifies a
>> servlet, CGI script, or other code handler.  Live Web servers already
>> have to handle this distinction.  You could test this out by finding a
>> Web server that had some static file stored on disk, available via GET
>> to an arbitrary URL, and try POST to that URL and see what happens.  I
>> suspect it would say that the resource doesn't handle POST method.
>
> Just tried this against Apache 2.0.
>
> I sent the following request:
>
> POST /~scarr/test.html HTTP/1.1
> Host: progbits.com
>
> And it returned back with the test.html content immediately.  Granted
> this is not a WebDav server, but should it make a difference?
>

In order to support CalDAV, a WebDAV server is going to have to be modified 
to support the new CalDAV features such as custom reports, the calendar 
collection resourcetype and MKCALENDAR (though that method will be 
optional). As such modifying a server to do something special when POST 
occurs on a calendar collection is a reasonable thing to do, so I don't 
think we need to worry about how current servers implement POST - the only 
thing that is important (and this is only from the server implementor's 
point of view, not the protocol point of view per se) is how easy it is to 
hook into the server's processing to do something different with a 
'standard' method like POST.

-- 
Cyrus Daboo

Date: Fri, 21 Jan 2005 22:04:47 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Helge Hess wrote:
> On 21. Jan 2005, at 21:32 Uhr, Julian Reschke wrote:
> 
>> Well, you can't say "please don't restart it" and then restart it 
>> yourself (at least it won't work :-).
> 
> 
> Argh, sorry ;-)

No problem.

>> My recommendation is to follow up on the HTTP mailing list and ask for 
>> advice. That's what it's for.
> 
> 
> Definitely a good advice. Could you give a pointer to the proper list? I 
> suppose there are multiple lists?

Sure, it's <http://lists.w3.org/Archives/Public/ietf-http-wg/>.

>...

Best regards, Julian

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

Date: Fri, 21 Jan 2005 12:53:26 -0800
From: Dan Mosedale <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Cyrus Daboo wrote:

> The downside of this of course is that there could be multiple 
> roundtrips between the client and server when creating to get a unique 
> URI. However careful choice by the client should ensure this is not a 
> very common situation. We could even suggest a suitable hashing scheme 
> in the draft so that co-operating clients from different vendors could 
> improve their likelihood of avoiding a URI clash like this. 

At the risk of adding a minor dependency on another draft, perhaps using 
some form of UUIDs as documented in 
<http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt> 
would do the trick?  I believe that draft just moved to Proposed 
Standard status

Dan

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 21:52:55 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 21:32 Uhr, Julian Reschke wrote:
> Well, you can't say "please don't restart it" and then restart it 
> yourself (at least it won't work :-).

Argh, sorry ;-)

> My recommendation is to follow up on the HTTP mailing list and ask for 
> advice. That's what it's for.

Definitely a good advice. Could you give a pointer to the proper list? 
I suppose there are multiple lists?

>> Of course. This is how our server operates since the beginning. It 
>> works just fine since most (all?) of the generic file browsing 
>> clients just
> Most or all? Did you encounter clients with problems?

No, I'm not aware that any client had problems in the way that it 
doesn't work in an unpredictable way.

>> In both contexts there are no SHOULD's or MAY's, only a MUST for a) 
>> and a plain statement for b).
> Well, if you think that the absence of UPPERCASED requirements means 
> that the text isn't normative, you are wrong.

Hm, no, actually I think that missing SHOULDs/MAYs make the written 
text a MUST? Wrong?

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

Date: Fri, 21 Jan 2005 21:32:03 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Helge Hess wrote:
> On 21. Jan 2005, at 19:44 Uhr, Julian Reschke wrote:
> 
>>> - clients which support redirect will work excellent with 
>>> PUT/201/location
>>>   - all actually should, as per HTTP RFC, otherwise they are no HTTP 
>>> clients, right?
>>
>> 201 is not a redirect, 3xx is.
> 
> 
> Sorry, of course. What would be a proper name, "relocation"?
> 
>> You can't say "created" and "look elsewhere" at the same time for PUT.
> 
> 
> I can say "created" and the new position is specified by "location". 
> This is documented in the HTTP spec, we had this before (please lets not 
> restart this discussion, can be read up in the archives ;-)

Well, you can't say "please don't restart it" and then restart it 
yourself (at least it won't work :-). My recommendation is to follow up 
on the HTTP mailing list and ask for advice. That's what it's for.

>>> - the far majority of clients without location support on PUT will 
>>> still work just
>>>   fine (reasons already mentioned)
>>
>> Did you try?
> 
> 
> Of course. This is how our server operates since the beginning. It works 
> just fine since most (all?) of the generic file browsing clients just 

Most or all? Did you encounter clients with problems?

> ...
> PUT + 201 + location + if-none-match:* is exactly that as per spec - at 
> least as I read it. It may have issues attached (like that the etag must 
> be queried after the PUT if reequired, anything else?).
> 
> Again my reasoning:
> 
> a) 9.6 PUT states:
> ---snip---
> If a new resource is created, the origin server MUST inform the user 
> agent via the 201 (Created) response.
> ---snap---
> 9.6 doesn't say anything else about that, so I assume that 201 is 
> completely valid for PUT, all strings attached. It also says:
> ---snip---

Of course 201 is ok. But 9.6 also says:

"The PUT method requests that the enclosed entity be stored under the 
supplied Request-URI."

So that's what the client is asking for. If you do something else, it's 
not what it was asking for.

> ... the origin server can create the resource with that URI. ...
> ---snap---
> While I'm not a native speaker, "with that URI" only says that the 
> server "uses" the URI to create the request, not that it will store the 
> new object "at that URI".

Well, nor am I, but I think RFC2616 is pretty clear here:

"If the Request-URI does not point to an existing resource, and that URI 
is capable of being defined as a new resource by the requesting user 
agent, the origin server can create the resource with that URI."

Arguing that this is a license to create a new resource with a different 
URI seems to be really far-fetched. But we already disagreed on that, 
and I don't think we'll come to a consensus, so we'll need more people 
looking at it, such as the members of the HTTP mailing list.

> b) 10.2.2 201 Created:
> ---snip---
> The newly created resource can be referenced by the URI(s) returned in 
> the entity of the response, with the most specific URI for the resource 
> given by a Location header field
> ---snap---
 >
> In both contexts there are no SHOULD's or MAY's, only a MUST for a) and 
> a plain statement for b).

Well, if you think that the absence of UPPERCASED requirements means 
that the text isn't normative, you are wrong.

> ...

Best regards, Julian

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

Date: Fri, 21 Jan 2005 11:36:07 -0800
From: Elias Sinderson <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Reply-To: ietf-caldav <[email-masked]>

Scott Carr wrote:

> The way I see WebDav, is as a glorified directory storage mechanism.

That is one way to view it, yes. One can also view WebDAV as a 
distributed authoring (the 'DA' in 'DAV') protocol that supports 
collaborative editing of resources... There are other views, to be sure.

> With CalDav, we are extending this mechanism to better handle Calendar 
> events.  Shouldn't we be able to extend it in ways that make clients 
> easier to write.

Certainly, provided that said extensions do not subvert or conflict with 
existing standards and definitions. for example the recent discussion on 
using HTTP PUT in a non-standard way, which is in conflict with the 
definition of the PUT  method in RFC 2616.

>> <Dan Mosedale> [...] this is just regular HTTP GET/PUT with an 
>> text/calendar entity. </Dan Mosedale>
>
> In a normal webdav server that is the case, but with the CalDav 
> extension, we could make it more 'usable' to our needs.

See above and reflect on the definition of interoperability - changing 
the definition of standardized protocol methods so that they are more 
useful for caldav, but less useful for existing applications, is a step 
in the wrong direction.

Cheers,
Elias

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 20:18:51 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 19:44 Uhr, Julian Reschke wrote:
>> - clients which support redirect will work excellent with 
>> PUT/201/location
>>   - all actually should, as per HTTP RFC, otherwise they are no HTTP 
>> clients, right?
> 201 is not a redirect, 3xx is.

Sorry, of course. What would be a proper name, "relocation"?

> You can't say "created" and "look elsewhere" at the same time for PUT.

I can say "created" and the new position is specified by "location". 
This is documented in the HTTP spec, we had this before (please lets 
not restart this discussion, can be read up in the archives ;-)

>> - the far majority of clients without location support on PUT will 
>> still work just
>>   fine (reasons already mentioned)
> Did you try?

Of course. This is how our server operates since the beginning. It 
works just fine since most (all?) of the generic file browsing clients 
just issue a collection reload after a creation and do not keep the URL 
for anything.
A periodic refresh is what they need to do anyway, since other users 
might have changed the server.

So, yes, it has issues attached for non-location aware clients, but a 
lot of operations still work just fine. Like dropping ICS files into 
Nautilus folder. In the worst case you need to trigger a manual 
refresh.

> I think you are confusing 201 and 3xx. A location header sent with a 
> "Created" status is not a redirect.

No, I'm not confusing this. I just failed to use proper terminology in 
some places, sorry about that.
Actually I think our past discussion on this was a bit mixed up due to 
this. I never intended to do a redirect 3xx to achieve the 
functionality.

> I *do* see the merits of having a standard way to let the server 
> choose a new name (not only for caldav), but as far as I can tell, 
> there currently is none. It may make sense to define a new one (new 
> method name?), but that shouldn't be part of CalDav.

PUT + 201 + location + if-none-match:* is exactly that as per spec - at 
least as I read it. It may have issues attached (like that the etag 
must be queried after the PUT if reequired, anything else?).

Again my reasoning:

a) 9.6 PUT states:
---snip---
If a new resource is created, the origin server MUST inform the user 
agent via the 201 (Created) response.
---snap---
9.6 doesn't say anything else about that, so I assume that 201 is 
completely valid for PUT, all strings attached. It also says:
---snip---
... the origin server can create the resource with that URI. ...
---snap---
While I'm not a native speaker, "with that URI" only says that the 
server "uses" the URI to create the request, not that it will store the 
new object "at that URI".

b) 10.2.2 201 Created:
---snip---
The newly created resource can be referenced by the URI(s) returned in 
the entity of the response, with the most specific URI for the resource 
given by a Location header field
---snap---

In both contexts there are no SHOULD's or MAY's, only a MUST for a) and 
a plain statement for b).

As you correctly mention, 'location' + 201 is _not_ a redirect, so the 
issues on redirects in the spec do not apply.

To get back to the discussion, while resolving this issue is probably 
interesting, it doesn't matter to CalDAV if the majority of the 
participants does not need this functionality. It indeed makes clients 
a tad more difficult to write.

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

Date: Fri, 21 Jan 2005 12:49:03 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Lisa Dusseault wrote:

> Typically, POST requests to "live Web Servers" are only handled by 
> code that generates dynamic responses if the Request-URI identifies a 
> servlet, CGI script, or other code handler.  Live Web servers already 
> have to handle this distinction.  You could test this out by finding a 
> Web server that had some static file stored on disk, available via GET 
> to an arbitrary URL, and try POST to that URL and see what happens.  I 
> suspect it would say that the resource doesn't handle POST method.

Just tried this against Apache 2.0.

I sent the following request:

POST /~scarr/test.html HTTP/1.1
Host: progbits.com

And it returned back with the test.html content immediately.  Granted 
this is not a WebDav server, but should it make a difference?

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

Date: Fri, 21 Jan 2005 19:44:20 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Helge Hess wrote:
> On 21. Jan 2005, at 19:12 Uhr, Cyrus Daboo wrote:
> 
>> That's really the question: do existing webdav clients properly handle 
>> a re-direct on the creation of a new resource? I think some 
>> experimentation is needed. If we find that all existing 
>> clients/libraries cope with that then we're OK. If that's not the 
>> case, then we have to decide whether we care about 'breaking' those 
>> clients...
> 
> 
> As mentioned:
> - clients which support redirect will work excellent with PUT/201/location
>   - all actually should, as per HTTP RFC, otherwise they are no HTTP 
> clients, right?

201 is not a redirect, 3xx is. You can't say "created" and "look 
elsewhere" at the same time for PUT.

> - the far majority of clients without location support on PUT will still 
> work just
>   fine (reasons already mentioned)

Did you try?

> - the POST approach will work with _no_ existing client nor server

That's correct. So the thr working group / community should decide 
whether that's a scenario that absolutely must be supported for existing 
clients. As far as I can tell, there is no conformant way to do so.

> I do not expect all clients to work fine with that. And this is not just 
> a client _application_ issue - a client _library_ is very likely to 
> include redirect/location support (since this is without question widely 
> supported for GET). So as a client developer I can just reuse existing 
> functionality for PUTs if this isn't even supported already.

I think you are confusing 201 and 3xx. A location header sent with a 
"Created" status is not a redirect.

> Now allowing the client to choose arbitary names is certainly the 
> approach which provides the best possible compatibility with generic 
> clients. But has other issues as mentioned.
> Since I'm apparently the only one who wishes for the server maintained 
> namespace support, I suppose Lisa's proposal might indeed be the way to 
> go :-|

I *do* see the merits of having a standard way to let the server choose 
a new name (not only for caldav), but as far as I can tell, there 
currently is none. It may make sense to define a new one (new method 
name?), but that shouldn't be part of CalDav.

Best regards, Julian

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

Date: Fri, 21 Jan 2005 12:30:23 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Julian Reschke wrote:

> I think what's important here is that the spec doesn't contain any 
> normative requirements that are in conflict with PUT semantics (and I 
> think those would be).
>
> Proposal:
>
> - have a normative way to use POST to do that operation (or a new 
> verb), but

A new verb would work as well, something like PUTNEW, or a variation 
thereof.

> - allow server implementers to do with PUT with they want on their own 
> risk.

This will be a part of the spec no matter what we come up with.  The 
client can still use the normal WebDav functionality.

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 19:30:15 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 19:12 Uhr, Cyrus Daboo wrote:
> That's really the question: do existing webdav clients properly handle 
> a re-direct on the creation of a new resource? I think some 
> experimentation is needed. If we find that all existing 
> clients/libraries cope with that then we're OK. If that's not the 
> case, then we have to decide whether we care about 'breaking' those 
> clients...

As mentioned:
- clients which support redirect will work excellent with 
PUT/201/location
   - all actually should, as per HTTP RFC, otherwise they are no HTTP 
clients, right?
- the far majority of clients without location support on PUT will 
still work just
   fine (reasons already mentioned)
- the POST approach will work with _no_ existing client nor server

I do not expect all clients to work fine with that. And this is not 
just a client _application_ issue - a client _library_ is very likely 
to include redirect/location support (since this is without question 
widely supported for GET). So as a client developer I can just reuse 
existing functionality for PUTs if this isn't even supported already.

Now allowing the client to choose arbitary names is certainly the 
approach which provides the best possible compatibility with generic 
clients. But has other issues as mentioned.
Since I'm apparently the only one who wishes for the server maintained 
namespace support, I suppose Lisa's proposal might indeed be the way to 
go :-|

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

Date: Fri, 21 Jan 2005 19:21:05 +0100
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Cyrus Daboo wrote:
> Hi Helge,
> 
> --On January 21, 2005 7:02:58 PM +0100 Helge Hess 
> <[email-masked]> wrote:
> 
>> Since HTTP clients are required to support redirects in any case, I don't
>> see why CalDAV should restrict HTTP here. As mentioned before in the
>> discussion with Julian, the location header is explicitly specified for
>> 201.
>>
> 
> That's really the question: do existing webdav clients properly handle a 
> re-direct on the creation of a new resource? I think some 
> experimentation is needed. If we find that all existing 
> clients/libraries cope with that then we're OK. If that's not the case, 
> then we have to decide whether we care about 'breaking' those clients...

I think what's important here is that the spec doesn't contain any 
normative requirements that are in conflict with PUT semantics (and I 
think those would be).

Proposal:

- have a normative way to use POST to do that operation (or a new verb), but
- allow server implementers to do with PUT with they want on their own risk.

Best regards, Julian

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

Date: Fri, 21 Jan 2005 13:12:42 -0500
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: 

Hi Helge,

--On January 21, 2005 7:02:58 PM +0100 Helge Hess 
<[email-masked]> wrote:

> Since HTTP clients are required to support redirects in any case, I don't
> see why CalDAV should restrict HTTP here. As mentioned before in the
> discussion with Julian, the location header is explicitly specified for
> 201.
>

That's really the question: do existing webdav clients properly handle a 
re-direct on the creation of a new resource? I think some experimentation 
is needed. If we find that all existing clients/libraries cope with that 
then we're OK. If that's not the case, then we have to decide whether we 
care about 'breaking' those clients...

-- 
Cyrus Daboo

Date: Fri, 21 Jan 2005 12:05:57 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Cyrus Daboo wrote:

> The proper distinction is this:
>
> A 'level 0' server is one in which an entire iCalendar 'agenda' is 
> accessed as a single resource. i.e. all events, to-dos, timezones etc 
> are bundled up into one iCalendar object.
>
> A 'level 1' server is one in which each separate component in an 
> iCalendar 'agenda' is accessed as a separate resource. i.e. each 
> event, to-do etc has a separate URI.
>
Ohhhh, thanks.  Makes sense now.

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 19:02:58 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 18:31 Uhr, Lisa Dusseault wrote:
> Then what about the client choosing to upload an event where the final 
> URL segment is  "lunch.ics" vs. "event128" vs. "foo.cal.event"?  Can 
> we require the server to allow any of these without doing a redirect 
> or rename?  I think we can and probably should.  After all, we're only 
> asking the server to maintain an extra table mapping client-chosen 
> resource names to its existing naming.

I'm rather allergic against protocols which require me to change or 
extend the datastorage (the RDBMS database schema in our server). 
Changing a database schema is a maintenance/update nightmare.

Since HTTP clients are required to support redirects in any case, I 
don't see why CalDAV should restrict HTTP here. As mentioned before in 
the discussion with Julian, the location header is explicitly specified 
for 201.

> E.g. if the existing calendar server has a global table of events 
> where every event is indexed by its UID, then we're requiring it to 
> persist the mappings between UIDs and client-chosen segment names and 
> calendar paths (another table, column, cache, etc.)

Thats an interesting point. Of course server side namespaces also 
affect iCalendar UIDs! After all thats the point, using the server side 
"primary key" in all places to avoid additional lookup tables.

> Now I'm not responsible for implementing one of these servers, but if 
> those who do can get behind this this, it would sure simplify by 
> removing the feature for a calendar server to choose a resource name 
> on behalf of the client, and that *should* allow existing WebDAV 
> clients to synchronize (both upload and download) directories of 
> events in iCalendar files.

I don't think existing WebDAV clients will be affected at all. Could 
you give an example where the given PUT approach is a real world issue 
with existing clients?

Having said that, sure, should CalDAV specify that clients are allowed 
to choose arbitary names and must not implement redirection, we would 
implement it. But this is significant additional work which will hinder 
adoption (IMO).

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

Date: Fri, 21 Jan 2005 13:03:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Scott Carr <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: 

Hi Scott,

--On January 21, 2005 11:36:49 AM -0600 Scott Carr <[email-masked]> 
wrote:

>>> The problem is the 'whole calendar' 'level 0' approach will not
>>> interact very well with the 'per component' 'level 1' (current
>>> design) scheme.
>>
> Just to make sure I have this concept correct before I start talking
> about it...
>
> Level 0:  Server would get a URL and have to decide what Events the
> request is dealing with itself.
>
> Level 1:  Server would geta  full URL with Filename and would be able to
> know which file to work with based on URL.
>
> Do I have this correct?
>

The proper distinction is this:

A 'level 0' server is one in which an entire iCalendar 'agenda' is accessed 
as a single resource. i.e. all events, to-dos, timezones etc are bundled up 
into one iCalendar object.

A 'level 1' server is one in which each separate component in an iCalendar 
'agenda' is accessed as a separate resource. i.e. each event, to-do etc has 
a separate URI.

-- 
Cyrus Daboo

Date: Fri, 21 Jan 2005 11:58:56 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Helge Hess wrote:

> On 21. Jan 2005, at 18:31 Uhr, Scott Carr wrote:
>
>>> I won't object, but IMO this does not belong into the CalDAV 
>>> discussion nor should be codified as some standard - lets just hope 
>>> that this approach of calendar sharing is a thing of history very soon.
>>
>>
>> This approach of Calendar sharing?  Could you elaborate, please.  
>> Unfortunately, I haven't been involved with these discussions for 
>> that long.
>
>
> I referred to the current approach implemented by most/all OpenSource 
> clients which package all vevents in a single HTTP entity. This 
> results in the various issues the others have just mentioned.
>
> Personally I hope that CalDAV will replace the above approach (I call 
> it iCal-over-HTTP) completely. Though it needs to be simple enough to 
> accomplish that.

Ohhhh, I understand it now.  I have used Sunbird and they are looking to 
use CalDav.  I think the developers are currently using something from 
Oracle to play around with the CalDav implementation.  That is how I 
came to be aware of CalDav.

So I think things should come together once the spec is there.

>
>> The way I see WebDav, is as a glorified directory storage mechanism.  
>> With CalDav, we are extending this mechanism to better handle 
>> Calendar events.  Shouldn't we be able to extend it in ways that make 
>> clients easier to write.
>
>
> Definitely.
>
> Clients are easier to write if we reuse existing technology to the 
> largest possible degree. That is WebDAV/HTTP client libraries and 
> tools. Why invent something like a POST on a collection if HTTP 
> libraries already implement etag processing and redirection as per spec?
> There need to be very good reasons for that.

Understand.  We should have a very good reason for changes of this 
magnitude.  We shouldn't just add stuff because it makes us feel better. ;-)

>
>>> BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT 
>>> with an text/calendar entity.
>>
>> In a normal webdav server that is the case, but with the CalDav 
>> extension, we could make it more 'usable' to our needs.
>
>
> With a CalDAV extension there is no reason to use the 'old' approach 
> anymore.

Ok, just making sure I understood things clearly.  ;-)

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 09:58:09 -0800
To: Scott Carr <[email-masked]>
Cc: ietf-caldav <[email-masked]>

Typically, POST requests to "live Web Servers" are only handled by code 
that generates dynamic responses if the Request-URI identifies a 
servlet, CGI script, or other code handler.  Live Web servers already 
have to handle this distinction.  You could test this out by finding a 
Web server that had some static file stored on disk, available via GET 
to an arbitrary URL, and try POST to that URL and see what happens.  I 
suspect it would say that the resource doesn't handle POST method.

Lisa

On Jan 21, 2005, at 9:41 AM, Scott Carr wrote:

> Lisa Dusseault wrote:
>
>> There's a certain amount of "allergic reaction" to the use of POST 
>> because in the past there have been proposals to write entire 
>> layerable protocols on top of HTTP using POST.  This arose rather 
>> naturally from the fact that POST allows WebUIs with user 
>> interaction, and a WebUI's fields and forms constitute a de facto 
>> "protocol" that is modeled by assigning values to field names and 
>> uploading those names and values in the Web form format.
>
> Correct me if I am wrong, please, but:
>
> Isn't a WebDav server also, potentially a LIVE web server?  If we use 
> POST in the CalDav protocol, isn't it possible that a WebServer could 
> get confussed and think it is supposed to GET the resource instead of 
> editing the resource?
>
> -- 
> Scott Carr
> OpenOffice.org
> Documentation Co-Lead
> http://documentation.openoffice.org
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 09:55:46 -0800
To: Helge Hess <[email-masked]>
Cc: ietf-caldav <[email-masked]>

>
>> The goal with that would be that CalDAV 'aware' clients can use POST 
>> to ensure that they avoid the 412 errors on PUT and avoid extra 
>> roundtrips (which are actually quite expensive in that the data gets 
>> uploaded each time, only to be rejected by the server - defintiely 
>> not ideal for mobile devices).
>
> Good point. Yet I'm not sure whether it matters in practice. The 412 
> errors only occur if a name is already taken which should be a 
> extremely rare (though important) exception in practice if the client 
> generates sufficiently unique identifiers.
>
In theory HTTP has a way of avoiding this too!

--client---

PUT /users/lisa/calendar/event1284.ics HTTP/1.1
If-None-Match: *
Content-Type: text/icalendar
Content-Length: 882
Expect: 100-continue

---server---

HTTP/1.1 100 Continue

---client---

BEGIN:VCALENDAR
....more stuff
END:VCALENDAR

----

Result: if the server could not satisfy the request due to permissions, 
policy, disallowed MIME format, excessive length, failure to satify 
If-None-Match or any other problem, it would respond with 412 instead 
of 100.  However unless the event has a very large attachment I just 
wouldn't bother.  Besides, the client could always create the event 
with a very small file then add the attachment in a first modification.

Y'all need to read my book again :)

Lisa

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 18:45:21 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 18:31 Uhr, Scott Carr wrote:
>> I won't object, but IMO this does not belong into the CalDAV 
>> discussion nor should be codified as some standard - lets just hope 
>> that this approach of calendar sharing is a thing of history very 
>> soon.
>
> This approach of Calendar sharing?  Could you elaborate, please.  
> Unfortunately, I haven't been involved with these discussions for that 
> long.

I referred to the current approach implemented by most/all OpenSource 
clients which package all vevents in a single HTTP entity. This results 
in the various issues the others have just mentioned.

Personally I hope that CalDAV will replace the above approach (I call 
it iCal-over-HTTP) completely. Though it needs to be simple enough to 
accomplish that.

> The way I see WebDav, is as a glorified directory storage mechanism.  
> With CalDav, we are extending this mechanism to better handle Calendar 
> events.  Shouldn't we be able to extend it in ways that make clients 
> easier to write.

Definitely.

Clients are easier to write if we reuse existing technology to the 
largest possible degree. That is WebDAV/HTTP client libraries and 
tools. Why invent something like a POST on a collection if HTTP 
libraries already implement etag processing and redirection as per 
spec?
There need to be very good reasons for that.

>> BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT 
>> with an text/calendar entity.
> In a normal webdav server that is the case, but with the CalDav 
> extension, we could make it more 'usable' to our needs.

With a CalDAV extension there is no reason to use the 'old' approach 
anymore.

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

Date: Fri, 21 Jan 2005 11:41:03 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Lisa Dusseault wrote:

> There's a certain amount of "allergic reaction" to the use of POST 
> because in the past there have been proposals to write entire 
> layerable protocols on top of HTTP using POST.  This arose rather 
> naturally from the fact that POST allows WebUIs with user interaction, 
> and a WebUI's fields and forms constitute a de facto "protocol" that 
> is modeled by assigning values to field names and uploading those 
> names and values in the Web form format.

Correct me if I am wrong, please, but:

Isn't a WebDav server also, potentially a LIVE web server?  If we use 
POST in the CalDav protocol, isn't it possible that a WebServer could 
get confussed and think it is supposed to GET the resource instead of 
editing the resource?

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

Date: Fri, 21 Jan 2005 11:36:49 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Helge Hess wrote:

> On 21. Jan 2005, at 16:46 Uhr, Cyrus Daboo wrote:
>
>> The problem is the 'whole calendar' 'level 0' approach will not 
>> interact very well with the 'per component' 'level 1' (current 
>> design) scheme.
>
Just to make sure I have this concept correct before I start talking 
about it...

Level 0:  Server would get a URL and have to decide what Events the 
request is dealing with itself.

Level 1:  Server would geta  full URL with Filename and would be able to 
know which file to work with based on URL.

Do I have this correct?

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 09:36:49 -0800
To: Cyrus Daboo <[email-masked]>
Cc: ietf-caldav <[email-masked]>

There's a certain amount of "allergic reaction" to the use of POST 
because in the past there have been proposals to write entire layerable 
protocols on top of HTTP using POST.  This arose rather naturally from 
the fact that POST allows WebUIs with user interaction, and a WebUI's 
fields and forms constitute a de facto "protocol" that is modeled by 
assigning values to field names and uploading those names and values in 
the Web form format.

However, I *believe* there is now sufficient understanding of when it's 
OK to use POST that this might be widely considered to be an acceptable 
definition, rather than simply trigger the allergic reaction of "nobody 
can use POST!"

On the other hand the sufficient understanding and lack of allergic 
reaction might exist and yet the community might deduce that it's not 
OK to use POST on a WebDAV collection to create a new resource to be 
named by the server.  We could always float this and see -- that is, if 
we agree that this is a requirement for CalDAV.  My previous email 
suggested that it is not.

Lisa

On Jan 21, 2005, at 9:26 AM, Cyrus Daboo wrote:

> Hi Scott,
>
> --On January 21, 2005 11:18:24 AM -0600 Scott Carr 
> <[email-masked]> wrote:
>
>>> Really the core problem we have here is the fact that some servers 
>>> may
>>> prefer to use a URI naming scheme that they define because they need
>>> to operate on top of an existing calendar store with specific
>>> requirements for naming resources. So we need to solve the redirect
>>> problem in a way that has minimal impact for 'plain' WebDAV clients
>>> and with minimum complexity for CalDAV clients that can expect a
>>> redirect.
>>>
>> I think having a method in the spec to keep from doing a roundtrip 
>> would
>> be a good idea as well.  With WebDav, if the client wants to use the
>> standard way of doing things, we won't be removing functionality.  We 
>> are
>> adding functionality that better helps our specific needs.
>>
>> If we add a way to set something and be done with it, then it will 
>> help
>> "dumb down" the clients needed logic.
>
> Currently my personal preference for this is to use 'POST' on the 
> calendar collection with a text/calendar body - that tells the server 
> to create a new resource for the calendar data, and the server would 
> return the new location in a Location (or other appropriate header). 
> However, I have been told that there are 'issues' with POST, so I'm 
> not sure how viable that would be.
>
> The goal with that would be that CalDAV 'aware' clients can use POST 
> to ensure that they avoid the 412 errors on PUT and avoid extra 
> roundtrips (which are actually quite expensive in that the data gets 
> uploaded each time, only to be rejected by the server - defintiely not 
> ideal for mobile devices). Regular WebDAV clients would continue to 
> use PUT in their normal way and would have to cope with the roundtrips 
> as they would anyway.
>
> -- 
> Cyrus Daboo
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 18:35:50 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 18:26 Uhr, Cyrus Daboo wrote:
> Currently my personal preference for this is to use 'POST' on the 
> calendar collection with a text/calendar body - that tells the server 
> to create a new resource for the calendar data, and the server would 
> return the new location in a Location (or other appropriate header). 
> However, I have been told that there are 'issues' with POST, so I'm 
> not sure how viable that would be.

One major drawback is that you won't be able create items with existing 
WebDAV clients (or client libraries). You need to write special code to 
handle the POST even though all the functionality is available in the 
base protocol.

> The goal with that would be that CalDAV 'aware' clients can use POST 
> to ensure that they avoid the 412 errors on PUT and avoid extra 
> roundtrips (which are actually quite expensive in that the data gets 
> uploaded each time, only to be rejected by the server - defintiely not 
> ideal for mobile devices).

Good point. Yet I'm not sure whether it matters in practice. The 412 
errors only occur if a name is already taken which should be a 
extremely rare (though important) exception in practice if the client 
generates sufficiently unique identifiers.

> Regular WebDAV clients would continue to use PUT in their normal way 
> and would have to cope with the roundtrips as they would anyway.

Regular WebDAV clients still might want to know about the new URL the 
item will live on for servers which require namespace maintenance.
IMO the location header with 201 is the best solution and while Julian 
raised several issues in the past, I think there are no strong 
objections towards that.

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 09:32:28 -0800
To: Cyrus Daboo <[email-masked]>
Cc: Dan Mosedale <[email-masked]>, ietf-caldav <[email-masked]>

Yep, it's not easy, that's why I'd like to see a separate document 
describing it!

lisa

On Jan 21, 2005, at 9:21 AM, Cyrus Daboo wrote:

> Hi Lisa,
>
> --On January 21, 2005 8:55:52 AM -0800 Lisa Dusseault 
> <[email-masked]> wrote:
>
>>   - The server MUST split up the full calendar whenever uploaded and
>> attempt to apply each changed event one by one, matching UIDs to 
>> existing
>> events.  The server MUST NOT cause an existing event to change if the
>> data in it is unchanged.
>
> Determining whether the data is unchanged or not is not easy. There 
> are issues like:
>
> - clients simply re-ordering the properties but not changing the 
> content (e.g. my client reads all props into a database, and writes 
> them out in alphabetic order due to the way the database works - that 
> may not match the original order)
>
> - clients re-wrapping long lines at a slightly different location than 
> in the original.
>
> - clients using a different unicode normalisation on non-ascii text 
> that results in the same effective unicode text (stringprep would 
> solve that - uggh).
>
> There is also the issue of not wanting to rely on timestamps in the 
> component (e.g. 'LAST-MODIFIED') because often clients and servers are 
> NOT in sync wrt their clocks.
>
> -- 
> Cyrus Daboo

Date: Fri, 21 Jan 2005 11:31:22 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Helge Hess wrote:

> On 21. Jan 2005, at 07:00 Uhr, Dan Mosedale wrote:
>
>>> This is actually something we do in our ZideStore server. You can 
>>> either retrieve/store a collection as a single iCalendar entity 
>>> containing all events or treat it like a WebDAV collection 
>>> containing individual events.
>>>
>>> Good for compatibility with existing clients.
>>
>>
>> This is an elegant semantic, because it allows people to advertise a 
>> single URL as their calendar URL, and smart clients can access it as 
>> CalDAV, while simpler ones can access it as WebDAV.  Codifying this 
>> in some way in the standard (as a MAY, perhaps) seems worthwhile to me.
>
>
> I won't object, but IMO this does not belong into the CalDAV 
> discussion nor should be codified as some standard - lets just hope 
> that this approach of calendar sharing is a thing of history very soon.

This approach of Calendar sharing?  Could you elaborate, please.  
Unfortunately, I haven't been involved with these discussions for that long.

The way I see WebDav, is as a glorified directory storage mechanism.  
With CalDav, we are extending this mechanism to better handle Calendar 
events.  Shouldn't we be able to extend it in ways that make clients 
easier to write.

>
> Its just a 'smart' way to support two different approaches in one 
> server. Our server also supports some WCAP and Exchange WebDAV API at 
> the same time, that doesn't imply that CalDAV should specify the to ;-)
>
> BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT 
> with an text/calendar entity.

In a normal webdav server that is the case, but with the CalDav 
extension, we could make it more 'usable' to our needs.

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

Date: Fri, 21 Jan 2005 12:31:46 -0500
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: 

Hi Helge,

--On January 21, 2005 6:25:58 PM +0100 Helge Hess 
<[email-masked]> wrote:

>> In terms of how to do it, as Julian points out, you cannot use PUT on
>> the collection.
>
> This I can't follow and I don't think that this is what Julian said. He
> said that a PUT on a collection writes the content of the collection and
> does NOT write content for new items inside the collection. In other
> words: PUT on a collection is already specified in HTTP and can't be
> redefined to do something else.
>
> It should be perfectly valid for a WebDAV collection to have content as
> well as children protocolwise.
> Please correct me by pointing to the proper section of the WebDAV spec in
> case I'm wrong.
>
> Thanks,
>    Helge
>
> PS: yes, I'm perfectly aware that several WebDAV servers might not allow
> for that, that doesn't imply its forbidden by the protocol ;-)

Sorry, I think my wording was a bit lax there - I agree with your analysis 
of this situation: PUT on the collection is allowed via the spec, but may 
not be supported by a server and certainly won't have the desired effect of 
actually creating a new resource inside the collection.

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 09:31:11 -0800
To: Cyrus Daboo <[email-masked]>
Cc: ietf-caldav <[email-masked]>

>
>
> Really the core problem we have here is the fact that some servers may 
> prefer to use a URI naming scheme that they define because they need 
> to operate on top of an existing calendar store with specific 
> requirements for naming resources. So we need to solve the redirect 
> problem in a way that has minimal impact for 'plain' WebDAV clients 
> and with minimum complexity for CalDAV clients that can expect a 
> redirect.
>
>

Perhaps we haven't looked closely enough at whether it's reasonable to 
require servers to support arbitrary event URLs chosen by clients.  
After all, the server can already restrict where to create calendars 
and can even provision the calendar locations -- e.g. a server isn't 
actually required to support MKCALENDAR because it can simply create a 
calendar wherever it likes for every defined user.  So rather than 
store locations like "/users/ldusseault/calendar" and 
"/users/cdaboo/calendar" it can generate those paths from its 
provisioning policies.

Then what about the client choosing to upload an event where the final 
URL segment is  "lunch.ics" vs. "event128" vs. "foo.cal.event"?  Can we 
require the server to allow any of these without doing a redirect or 
rename?  I think we can and probably should.  After all, we're only 
asking the server to maintain an extra table mapping client-chosen 
resource names to its existing naming.  E.g. if the existing calendar 
server has a global table of events where every event is indexed by its 
UID, then we're requiring it to persist the mappings between UIDs and 
client-chosen segment names and calendar paths (another table, column, 
cache, etc.)

Now I'm not responsible for implementing one of these servers, but if 
those who do can get behind this this, it would sure simplify by 
removing the feature for a calendar server to choose a resource name on 
behalf of the client, and that *should* allow existing WebDAV clients 
to synchronize (both upload and download) directories of events in 
iCalendar files.

Lisa

Date: Fri, 21 Jan 2005 12:26:35 -0500
From: Cyrus Daboo <[email-masked]>
To: Scott Carr <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: 

Hi Scott,

--On January 21, 2005 11:18:24 AM -0600 Scott Carr <[email-masked]> 
wrote:

>> Really the core problem we have here is the fact that some servers may
>> prefer to use a URI naming scheme that they define because they need
>> to operate on top of an existing calendar store with specific
>> requirements for naming resources. So we need to solve the redirect
>> problem in a way that has minimal impact for 'plain' WebDAV clients
>> and with minimum complexity for CalDAV clients that can expect a
>> redirect.
>>
> I think having a method in the spec to keep from doing a roundtrip would
> be a good idea as well.  With WebDav, if the client wants to use the
> standard way of doing things, we won't be removing functionality.  We are
> adding functionality that better helps our specific needs.
>
> If we add a way to set something and be done with it, then it will help
> "dumb down" the clients needed logic.

Currently my personal preference for this is to use 'POST' on the calendar 
collection with a text/calendar body - that tells the server to create a 
new resource for the calendar data, and the server would return the new 
location in a Location (or other appropriate header). However, I have been 
told that there are 'issues' with POST, so I'm not sure how viable that 
would be.

The goal with that would be that CalDAV 'aware' clients can use POST to 
ensure that they avoid the 412 errors on PUT and avoid extra roundtrips 
(which are actually quite expensive in that the data gets uploaded each 
time, only to be rejected by the server - defintiely not ideal for mobile 
devices). Regular WebDAV clients would continue to use PUT in their normal 
way and would have to cope with the roundtrips as they would anyway.

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 18:25:58 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 16:46 Uhr, Cyrus Daboo wrote:
> The problem is the 'whole calendar' 'level 0' approach will not 
> interact very well with the 'per component' 'level 1' (current design) 
> scheme.
...
> This adds a lot more complexity to the server.

Exactly. I would really like to keep iCal-over-HTTP out of the 
discussion.

I would like to have clarification on that:

> In terms of how to do it, as Julian points out, you cannot use PUT on 
> the collection.

This I can't follow and I don't think that this is what Julian said. He 
said that a PUT on a collection writes the content of the collection 
and does NOT write content for new items inside the collection. In 
other words: PUT on a collection is already specified in HTTP and can't 
be redefined to do something else.

It should be perfectly valid for a WebDAV collection to have content as 
well as children protocolwise.
Please correct me by pointing to the proper section of the WebDAV spec 
in case I'm wrong.

Thanks,
   Helge

PS: yes, I'm perfectly aware that several WebDAV servers might not 
allow for that, that doesn't imply its forbidden by the protocol ;-)
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Fri, 21 Jan 2005 12:21:03 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: Dan Mosedale <[email-masked]>, ietf-caldav <[email-masked]>

Hi Lisa,

--On January 21, 2005 8:55:52 AM -0800 Lisa Dusseault 
<[email-masked]> wrote:

>   - The server MUST split up the full calendar whenever uploaded and
> attempt to apply each changed event one by one, matching UIDs to existing
> events.  The server MUST NOT cause an existing event to change if the
> data in it is unchanged.

Determining whether the data is unchanged or not is not easy. There are 
issues like:

- clients simply re-ordering the properties but not changing the content 
(e.g. my client reads all props into a database, and writes them out in 
alphabetic order due to the way the database works - that may not match the 
original order)

- clients re-wrapping long lines at a slightly different location than in 
the original.

- clients using a different unicode normalisation on non-ascii text that 
results in the same effective unicode text (stringprep would solve that - 
uggh).

There is also the issue of not wanting to rely on timestamps in the 
component (e.g. 'LAST-MODIFIED') because often clients and servers are NOT 
in sync wrt their clocks.

-- 
Cyrus Daboo

Date: Fri, 21 Jan 2005 11:18:24 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Cyrus Daboo wrote:

> Hi Scott,
>
> --On January 21, 2005 10:07:18 AM -0600 Scott Carr 
> <[email-masked]> wrote:
>
>> The problem that I see in the this is, how do we know that the 
>> following:
>>
>> PUT /scarr/Calendar/1234.evt HTTP/1.1
>>
>> Is not meant to edit 1234.evt if it already exists.  The / could denote
>> an add operation to a CalDav based server.  The return header would
>> include the filename that was generated for the new resource.  Of 
>> course,
>> there are several ways we could do this, as well.
>>
>
> ETags and the If-Match/If-None-Match header can be used by clients to 
> ensure expected behaviour when creating or editing existing resources 
> - this is just standard http behaviour.
>
> e.g.:
>
> To create a new resource:
>
> PUT /calendar/cyrus/1234.ics HTTP/1.1
> Host: localhost
> If-None-Match: *
> ...
>
> In the above request, if a resource already exists at the specified 
> URI, then the server will return a '412 (Precondition Failed)' and the 
> client will know to try another URI for create.
>
> To edit an existing resource:
>
> PUT /calendar/cyrus/1234.ics HTTP/1.1
> Host: localhost
> If-Match: 1234etag-2005-01-21
> ...
>
> In the above request, if the resource on the server has changed or 
> been deleted, the server will respond with a '412 (Precondition 
> Failed)' and the client will know to take remedial action.
>
Ok.  Thanks for the explanation.  It makes sense as well.

> Right now this is what my implementation does: it generates a unique 
> uri based on a hash of the component UID, SEQUENCE, DTSTAMP & 
> RECURRENCE-ID, and tries to create that with the If-None-Match header 
> present. If that fails with 412, we add a counter into the string 
> being hashed, rehash it and try with that. The downside of this of 
> course is that there could be multiple roundtrips between the client 
> and server when creating to get a unique URI. However careful choice 
> by the client should ensure this is not a very common situation. We 
> could even suggest a suitable hashing scheme in the draft so that 
> co-operating clients from different vendors could improve their 
> likelihood of avoiding a URI clash like this.
>
> Really the core problem we have here is the fact that some servers may 
> prefer to use a URI naming scheme that they define because they need 
> to operate on top of an existing calendar store with specific 
> requirements for naming resources. So we need to solve the redirect 
> problem in a way that has minimal impact for 'plain' WebDAV clients 
> and with minimum complexity for CalDAV clients that can expect a 
> redirect.
>
I think having a method in the spec to keep from doing a roundtrip would 
be a good idea as well.  With WebDav, if the client wants to use the 
standard way of doing things, we won't be removing functionality.  We 
are adding functionality that better helps our specific needs.

If we add a way to set something and be done with it, then it will help 
"dumb down" the clients needed logic.

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 18:14:00 +0100
To: ietf-caldav <[email-masked]>

On 21. Jan 2005, at 07:00 Uhr, Dan Mosedale wrote:
>> This is actually something we do in our ZideStore server. You can 
>> either retrieve/store a collection as a single iCalendar entity 
>> containing all events or treat it like a WebDAV collection containing 
>> individual events.
>>
>> Good for compatibility with existing clients.
>
> This is an elegant semantic, because it allows people to advertise a 
> single URL as their calendar URL, and smart clients can access it as 
> CalDAV, while simpler ones can access it as WebDAV.  Codifying this in 
> some way in the standard (as a MAY, perhaps) seems worthwhile to me.

I won't object, but IMO this does not belong into the CalDAV discussion 
nor should be codified as some standard - lets just hope that this 
approach of calendar sharing is a thing of history very soon.

Its just a 'smart' way to support two different approaches in one 
server. Our server also supports some WCAP and Exchange WebDAV API at 
the same time, that doesn't imply that CalDAV should specify the to ;-)

BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT 
with an text/calendar entity.

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

Date: Fri, 21 Jan 2005 12:05:40 -0500
From: Cyrus Daboo <[email-masked]>
To: Scott Carr <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: 

Hi Scott,

--On January 21, 2005 10:07:18 AM -0600 Scott Carr <[email-masked]> 
wrote:

> The problem that I see in the this is, how do we know that the following:
>
> PUT /scarr/Calendar/1234.evt HTTP/1.1
>
> Is not meant to edit 1234.evt if it already exists.  The / could denote
> an add operation to a CalDav based server.  The return header would
> include the filename that was generated for the new resource.  Of course,
> there are several ways we could do this, as well.
>

ETags and the If-Match/If-None-Match header can be used by clients to 
ensure expected behaviour when creating or editing existing resources - 
this is just standard http behaviour.

e.g.:

To create a new resource:

PUT /calendar/cyrus/1234.ics HTTP/1.1
Host: localhost
If-None-Match: *
...

In the above request, if a resource already exists at the specified URI, 
then the server will return a '412 (Precondition Failed)' and the client 
will know to try another URI for create.

To edit an existing resource:

PUT /calendar/cyrus/1234.ics HTTP/1.1
Host: localhost
If-Match: 1234etag-2005-01-21
...

In the above request, if the resource on the server has changed or been 
deleted, the server will respond with a '412 (Precondition Failed)' and the 
client will know to take remedial action.

Right now this is what my implementation does: it generates a unique uri 
based on a hash of the component UID, SEQUENCE, DTSTAMP & RECURRENCE-ID, 
and tries to create that with the If-None-Match header present. If that 
fails with 412, we add a counter into the string being hashed, rehash it 
and try with that. The downside of this of course is that there could be 
multiple roundtrips between the client and server when creating to get a 
unique URI. However careful choice by the client should ensure this is not 
a very common situation. We could even suggest a suitable hashing scheme in 
the draft so that co-operating clients from different vendors could improve 
their likelihood of avoiding a URI clash like this.

Really the core problem we have here is the fact that some servers may 
prefer to use a URI naming scheme that they define because they need to 
operate on top of an existing calendar store with specific requirements for 
naming resources. So we need to solve the redirect problem in a way that 
has minimal impact for 'plain' WebDAV clients and with minimum complexity 
for CalDAV clients that can expect a redirect.

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 09:04:44 -0800
To: Scott Carr <[email-masked]>
Cc: ietf-caldav <[email-masked]>

The problem with PUT doing an overwrite vs. only creating a new 
resource is solved by HTTP already with ETags and the If-None-Match 
header.

There's a kind of paper which might help explain this: 
http://www.w3.org/1999/04/Editing/

Lisa

On Jan 21, 2005, at 8:07 AM, Scott Carr wrote:

> Julian Reschke wrote:
>
>> Scott Carr wrote:
>>
>>> I agree, post/redirect would be way too complex of a design for this.
>>>
>>> How about something like:
>>>
>>> -- New Entry --
>>> PUT /scarr/Calendar/ HTTP/1.1
>>>
>>> Notice the last /, this should be a required item, so WebDav/CalDav 
>>> knows this is supposed to go into this directory as a generated 
>>> file.
>>
>>
>> That breaks the HTTP semantics for PUT. If you send a representation 
>> for "/scarr/Calendar/", and the server accepts it (200/201), then 
>> that's the new content for "/scarr/Calendar/".
>>
> The problem that I see in the this is, how do we know that the 
> following:
>
> PUT /scarr/Calendar/1234.evt HTTP/1.1
>
> Is not meant to edit 1234.evt if it already exists.  The / could 
> denote an add operation to a CalDav based server.  The return header 
> would include the filename that was generated for the new resource.  
> Of course, there are several ways we could do this, as well.
>
> -- Example 1 --
> PUT /scarr/Calendar/new HTTP/1.1
>
> This would visually denote that a new operation is requested by the 
> client.  The server would then look at the contents being added, and 
> would be able to deside what filename and extension to use.
>
> -- Example 2 --
> PUT /scarr/Calendar/1234.evt HTTP/1.1
> X-Operation:  new
>
> Here, we would be able to see that a new operation is requested, and 
> the server could change the filename as needed.  I personally like the 
> 1st example, because it is one line that we have to look at.
>
> -- Problem with Redirection --
> The problem I see with redirection, is that it would require two 
> different requests to the server to get something added.  If you 
> multiply that by n number of users, it could put a big strain on the 
> server.  The company where I work has 100 employees, and they use 
> scheduling constantly.  If you take one person creating a meeting 
> request for 10 people, and each of those requests having to do 2 
> operations potentially to get something saved, it adds up quick, and 
> that is only one meeting request.
>
> -- 
> Scott Carr
> OpenOffice.org
> Documentation Co-Lead
> http://documentation.openoffice.org
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 08:55:52 -0800
To: Cyrus Daboo <[email-masked]>
Cc: Dan Mosedale <[email-masked]>, ietf-caldav <[email-masked]>

I was hoping Dan Winship would write a draft explaining how a server 
should support both level 1 and level 0 approaches together, Dan are 
you out there and are you still interested?  This would be partly 
specification (knowing which URL to use for the level 0 version) and 
partly requirements for how not to screw up CalDAV clients.  E.g.

A server MAY support downloading the full calendar as a single resource 
without allowing upload -- a read-only 'level 0' calendar.  This can be 
useful for CalDAV clients to publish their calendars through the CalDAV 
server to be consumed by clients that do not support CalDAV but know 
how to interpret an entire calendar in a single iCalendar-formatted 
document available as a HTTP resource.

If a server wishes to support a read-write 'level 0' calendar, in 
addition to supporting CalDAV clients, these are the requirements for 
how to do that:
  - The server MUST split up the full calendar whenever uploaded and 
attempt to apply each changed event one by one, matching UIDs to 
existing events.  The server MUST NOT cause an existing event to change 
if the data in it is unchanged.
  - The server MUST respect locks on existing events as it goes through 
and applies these changes.
  ... etc...  I think a fair bit of thought needs to go into this to do 
it right, including understanding how writing a 'level 1' calendar 
works in practice, and understanding how to handle the UIDs and 
recurrances and stuff.

Lisa

On Jan 21, 2005, at 7:46 AM, Cyrus Daboo wrote:

> Hi Mike,
>
> --On January 21, 2005 12:10:26 AM -0800 Mike Shaver 
> <[email-masked]> wrote:
>
>>> This is an elegant semantic, because it allows people to advertise a
>>> single URL as their calendar URL, and smart clients can access it as
>>> CalDAV, while simpler ones can access it as WebDAV.  Codifying this 
>>> in
>>> some way in the standard (as a MAY, perhaps) seems worthwhile to me.
>>
>> This is something that I've been pushing for as "CalDAV Level Zero"
>> for a few months now.  I'm glad to see it gathering support!
>>
>
> The problem is the 'whole calendar' 'level 0' approach will not 
> interact very well with the 'per component' 'level 1' (current design) 
> scheme. The biggest problem is 'level 0' clients uploading an entire 
> calendar with only one changed component - in the worst case the 
> server ends up overwriting all the existing components, changing the 
> ETags, and forcing level 1 clients to resync the entire set of events 
> - this is bad for 'level 1'. In the best case the server has to do a 
> lot more work by trying to sync each component in the 'level 0' PUT 
> with each existing component in the separate resource collection and 
> only overwrite those that have changed, are new or ones deleted. This 
> adds a lot more complexity to the server.
>
> The bottom line is I (personally) am not adverse to a 'level 0' type 
> solution but it MUST NOT have any negative impact on 'level 1'. The 
> other issue is whether wereally want to contin ue to promote 'level 0' 
> type access when we believe (at least I do) that 'level 1' is 
> potentially much superior.
>
> In terms of how to do it, as Julian points out, you cannot use PUT on 
> the collection. What I would suggest is that we define a 'standard' 
> resource name in each calendar collection that represents the entire 
> set of components, e.g. the resource 'TOTALCALENDAR' inside the 
> calendar collection: 
> <http://caldav.example.com/calendars/cyrus/work/TOTALCALENDAR>, and 
> then PUT/GET on that does 'level 0' behaviour. The alternative would 
> be to have a property on the calendar collection that specifies a 
> server-defined URI that can be used for 'level 0' operations and can 
> be easily discovered, and would remove the need to have a fixed 
> pre-defined resource name.
>
> -- 
> Cyrus Daboo
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Fri, 21 Jan 2005 10:07:18 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Julian Reschke wrote:

> Scott Carr wrote:
>
>> I agree, post/redirect would be way too complex of a design for this.
>>
>> How about something like:
>>
>> -- New Entry --
>> PUT /scarr/Calendar/ HTTP/1.1
>>
>> Notice the last /, this should be a required item, so WebDav/CalDav 
>> knows this is supposed to go into this directory as a generated file.
>
>
> That breaks the HTTP semantics for PUT. If you send a representation 
> for "/scarr/Calendar/", and the server accepts it (200/201), then 
> that's the new content for "/scarr/Calendar/".
>
The problem that I see in the this is, how do we know that the following:

PUT /scarr/Calendar/1234.evt HTTP/1.1

Is not meant to edit 1234.evt if it already exists.  The / could denote 
an add operation to a CalDav based server.  The return header would 
include the filename that was generated for the new resource.  Of 
course, there are several ways we could do this, as well.

-- Example 1 --
PUT /scarr/Calendar/new HTTP/1.1

This would visually denote that a new operation is requested by the 
client.  The server would then look at the contents being added, and 
would be able to deside what filename and extension to use.

-- Example 2 --
PUT /scarr/Calendar/1234.evt HTTP/1.1
X-Operation:  new

Here, we would be able to see that a new operation is requested, and the 
server could change the filename as needed.  I personally like the 1st 
example, because it is one line that we have to look at.

-- Problem with Redirection --
The problem I see with redirection, is that it would require two 
different requests to the server to get something added.  If you 
multiply that by n number of users, it could put a big strain on the 
server.  The company where I work has 100 employees, and they use 
scheduling constantly.  If you take one person creating a meeting 
request for 10 people, and each of those requests having to do 2 
operations potentially to get something saved, it adds up quick, and 
that is only one meeting request.

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

Date: Fri, 21 Jan 2005 10:46:45 -0500
From: Cyrus Daboo <[email-masked]>
To: Mike Shaver <[email-masked]>, Dan Mosedale <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Hi Mike,

--On January 21, 2005 12:10:26 AM -0800 Mike Shaver <[email-masked]> 
wrote:

>> This is an elegant semantic, because it allows people to advertise a
>> single URL as their calendar URL, and smart clients can access it as
>> CalDAV, while simpler ones can access it as WebDAV.  Codifying this in
>> some way in the standard (as a MAY, perhaps) seems worthwhile to me.
>
> This is something that I've been pushing for as "CalDAV Level Zero"
> for a few months now.  I'm glad to see it gathering support!
>

The problem is the 'whole calendar' 'level 0' approach will not interact 
very well with the 'per component' 'level 1' (current design) scheme. The 
biggest problem is 'level 0' clients uploading an entire calendar with only 
one changed component - in the worst case the server ends up overwriting 
all the existing components, changing the ETags, and forcing level 1 
clients to resync the entire set of events - this is bad for 'level 1'. In 
the best case the server has to do a lot more work by trying to sync each 
component in the 'level 0' PUT with each existing component in the separate 
resource collection and only overwrite those that have changed, are new or 
ones deleted. This adds a lot more complexity to the server.

The bottom line is I (personally) am not adverse to a 'level 0' type 
solution but it MUST NOT have any negative impact on 'level 1'. The other 
issue is whether wereally want to contin ue to promote 'level 0' type 
access when we believe (at least I do) that 'level 1' is potentially much 
superior.

In terms of how to do it, as Julian points out, you cannot use PUT on the 
collection. What I would suggest is that we define a 'standard' resource 
name in each calendar collection that represents the entire set of 
components, e.g. the resource 'TOTALCALENDAR' inside the calendar 
collection: <http://caldav.example.com/calendars/cyrus/work/TOTALCALENDAR>, 
and then PUT/GET on that does 'level 0' behaviour. The alternative would be 
to have a property on the calendar collection that specifies a 
server-defined URI that can be used for 'level 0' operations and can be 
easily discovered, and would remove the need to have a fixed pre-defined 
resource name.

-- 
Cyrus Daboo

Date: Fri, 21 Jan 2005 09:22:51 +0100
From: Julian Reschke <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Scott Carr wrote:
> Continuation of this post:  [Thanks Mike for pointing me to it]
> http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/000102.html 
> 
> 
> I agree, post/redirect would be way too complex of a design for this.
> 
> How about something like:
> 
> -- New Entry --
> PUT /scarr/Calendar/ HTTP/1.1
> 
> Notice the last /, this should be a required item, so WebDav/CalDav 
> knows this is supposed to go into this directory as a generated file.

That breaks the HTTP semantics for PUT. If you send a representation for 
"/scarr/Calendar/", and the server accepts it (200/201), then that's the 
new content for "/scarr/Calendar/".

 > ...

Best regards, Julian

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

Date: Fri, 21 Jan 2005 00:10:26 -0800
From: Mike Shaver <[email-masked]>
To: Dan Mosedale <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>
Reply-To: Mike Shaver <[email-masked]>

On Thu, 20 Jan 2005 22:00:44 -0800, Dan Mosedale <[email-masked]> wrote:
> Helge Hess wrote:
> 
> >> Another thing that PUT on a collection could do would be to define a
> >> body *for the collection*.
> >
> >
> > This is actually something we do in our ZideStore server. You can
> > either retrieve/store a collection as a single iCalendar entity
> > containing all events or treat it like a WebDAV collection containing
> > individual events.
> >
> > Good for compatibility with existing clients.
> 
> This is an elegant semantic, because it allows people to advertise a
> single URL as their calendar URL, and smart clients can access it as
> CalDAV, while simpler ones can access it as WebDAV.  Codifying this in
> some way in the standard (as a MAY, perhaps) seems worthwhile to me.

This is something that I've been pushing for as "CalDAV Level Zero"
for a few months now.  I'm glad to see it gathering support!

Mike

Date: Thu, 20 Jan 2005 22:00:44 -0800
From: Dan Mosedale <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Cc: ietf-caldav <[email-masked]>

Helge Hess wrote:

>> Another thing that PUT on a collection could do would be to define a 
>> body *for the collection*.
>
>
> This is actually something we do in our ZideStore server. You can 
> either retrieve/store a collection as a single iCalendar entity 
> containing all events or treat it like a WebDAV collection containing 
> individual events.
>
> Good for compatibility with existing clients.

This is an elegant semantic, because it allows people to advertise a 
single URL as their calendar URL, and smart clients can access it as 
CalDAV, while simpler ones can access it as WebDAV.  Codifying this in 
some way in the standard (as a MAY, perhaps) seems worthwhile to me.

Dan

Date: Thu, 20 Jan 2005 18:00:00 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]

Lisa Dusseault wrote:

> That's kind of an elegant solution, since as yet PUT isn't defined on 
> a  collection.
>
> Another thing that PUT on a collection could do would be to define a  
> body *for the collection*.  There's no reason why a collection can't  
> itself have a body -- presumably that would make the behavior of GET 
> on  a collection defined, which is also at the moment undefined.
>
> To answer this whole problem, however, we first need to make clear 
> our  goal.
>  - Is our goal for new CalDAV clients to be able to create items  
> without selecting a URL, to make the server do the work of avoiding 
> URL  conflicts with existing resources?  For that problem, we have a 
> nearly  unlimited set of workable solutions, including POST, 
> redirects, PUT  request headers, new verbs like CREATE, etc.

I would suggest defining the behavior such that if a URL is there then 
it is up to the Client to make sure it is unique.  Otherwise an error 
occurs.  If it is a directory store with no filename then the CalDav 
implementation would create the file and respond in the header.

This solution seems like the best of both worlds.  It seems like asking 
alot of a client to require they keep track of what's on a server, but 
if the Spec defines a way around this, we would probably get more buyin 
from Server developers. 

BTW, I am talking about this after looking over the Slide 
implementation.  I have talked to James about the implementation and 
have started putting things together to start building the extensions.

>
>  -  Is our goal for existing WebDAV clients to be able to 
> successfully  create items in a server which wants to control 
> precisely the URL  space?  Such that a client like WebDAV FS on a Mac 
> could use its  existing code to synchronize a local directory 
> containing .ics files by  uploading each of them with PUT?  In that 
> case, we can't specify any  new client request syntax because we 
> already know what request those  clients send - a PUT which includes 
> the exact URL to be created.

See above.  The implementation would require a client to handle 
Uniqueness if it specifies a complete URL.  This also has ramnifications 
if there are multiple people adding records, because the client could 
not know that that filename has already been used until after it tries 
to save.

But, if the server has a way to handle unspecified filenames in the 
directory, and a way of notifying the Client after it is complete, then 
this should fix most issues, and puts ownership on the server, which is 
where I think it should be.  In this type of implementation, anyway.

>
> Some servers find it easy to assign whatever URL the client chooses,  
> but some implementors would find that much more of a challenge --  
> server implementors should speak up, here, about the constraints and  
> goals.

It may be a little more difficult, but it is much easier to fix the 
server than it is to have each new software client do things the same way.

>
> Lisa
>
> On Jan 20, 2005, at 3:28 PM, Scott Carr wrote:
>
>> Continuation of this post:  [Thanks Mike for pointing me to it]
>> http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/ 
>> 000102.html
>>
>> I agree, post/redirect would be way too complex of a design for this.
>>
>> How about something like:
>>
>> -- New Entry --
>> PUT /scarr/Calendar/ HTTP/1.1
>>
>> Notice the last /, this should be a required item, so WebDav/CalDav  
>> knows this is supposed to go into this directory as a generated file.
>>
>> Then the WebDav server could be extended to Generate the filename  
>> itself.  For now CalDav, could extend the Put method to generate a  
>> filename.  This would be doable, and it also makes for future use of  
>> the same feature.  Thinking about doing a Contact directory, and a  
>> Notes directory the same basic way, in the future.
>>
>> The response would include a Header item that tells the client the  
>> generated name.  This would need to be put in the spec as well.
>>
>> -- Edited Entry --
>> PUT /scarr/Calendar/msg01234.evt HTTP/1.1
>>
>> Here there wouldn't be a problem because the client already knows 
>> the  name of the file to save with.
>>
>> Does this make sense?  This sounds like a good extension to WebDav 
>> in  general.
>>
>> -- 
>> Scott Carr
>> OpenOffice.org
>> Documentation Co-Lead
>> http://documentation.openoffice.org
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Fri, 21 Jan 2005 00:59:29 +0100
To: ietf-caldav <[email-masked]>

On Jan 21, 2005, at 0:43, Lisa Dusseault wrote:
> That's kind of an elegant solution, since as yet PUT isn't defined on 
> a collection.

Really? I think PUT is defined generically on any URL and has pretty 
clear and defined semantics (but would need to look this up to prove 
it).

Requiring the trailing "/" would be against all HTTP URL resource rules 
unless I'm missing something very crucial.

> Another thing that PUT on a collection could do would be to define a 
> body *for the collection*.

This is actually something we do in our ZideStore server. You can 
either retrieve/store a collection as a single iCalendar entity 
containing all events or treat it like a WebDAV collection containing 
individual events.

Good for compatibility with existing clients.

> Is our goal for new CalDAV clients to be able to create items without 
> selecting a URL, to make the server do the work of avoiding URL 
> conflicts with existing resources?  For that problem, we have a nearly 
> unlimited set of workable solutions, including POST, redirects, PUT 
> request headers, new verbs like CREATE, etc.

There are two issues at hand:
a) there are servers which enforce maintenance of URLs, this needs to be
    supported
b) the client will need to write to some 'creation' URL

For a) I still think that PUT + 201/location is the best possible 
solution.

For b) - I think the if-none-match:* solution is pretty much ok. The 
client can invent arbitary names for new resources and the server will 
tell him in case the name is already taken.

> -  Is our goal for existing WebDAV clients to be able to successfully 
> create items in a server which wants to control precisely the URL 
> space?

I don't think that this needs to be a primary goal though this is 
pretty well supported by PUT+location.

> Such that a client like WebDAV FS on a Mac could use its existing code 
> to synchronize a local directory containing .ics files by uploading 
> each of them with PUT?

Would work with the PUT+location solution. The new local item would 
disappear and a new server item would come up. The location is only 
relevant for clients which need to maintain "open windows".
Generic WebDAV synchronisation should work without issues.

> In that case, we can't specify any new client request syntax because 
> we already know what request those clients send - a PUT which includes 
> the exact URL to be created.

Yes. I would prefer to keep it like that.

> Some servers find it easy to assign whatever URL the client chooses, 
> but some implementors would find that much more of a challenge -- 
> server implementors should speak up, here, about the constraints and 
> goals.

First case doesn't work. The server needs to check for existing URLs in 
any case unless the client locks the whole collection.

The latter - yes, I speak up. We need the redirect (or some other 
solution) to allow the server maintain IDs after initial creation.

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating Items [ideas]
Date: Thu, 20 Jan 2005 15:43:07 -0800
To: Scott Carr <[email-masked]>
Cc: ietf-caldav <[email-masked]>

That's kind of an elegant solution, since as yet PUT isn't defined on a  
collection.

Another thing that PUT on a collection could do would be to define a  
body *for the collection*.  There's no reason why a collection can't  
itself have a body -- presumably that would make the behavior of GET on  
a collection defined, which is also at the moment undefined.

To answer this whole problem, however, we first need to make clear our  
goal.
  - Is our goal for new CalDAV clients to be able to create items  
without selecting a URL, to make the server do the work of avoiding URL  
conflicts with existing resources?  For that problem, we have a nearly  
unlimited set of workable solutions, including POST, redirects, PUT  
request headers, new verbs like CREATE, etc.

  -  Is our goal for existing WebDAV clients to be able to successfully  
create items in a server which wants to control precisely the URL  
space?  Such that a client like WebDAV FS on a Mac could use its  
existing code to synchronize a local directory containing .ics files by  
uploading each of them with PUT?  In that case, we can't specify any  
new client request syntax because we already know what request those  
clients send - a PUT which includes the exact URL to be created.

Some servers find it easy to assign whatever URL the client chooses,  
but some implementors would find that much more of a challenge --  
server implementors should speak up, here, about the constraints and  
goals.

Lisa

On Jan 20, 2005, at 3:28 PM, Scott Carr wrote:

> Continuation of this post:  [Thanks Mike for pointing me to it]
> http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/ 
> 000102.html
>
> I agree, post/redirect would be way too complex of a design for this.
>
> How about something like:
>
> -- New Entry --
> PUT /scarr/Calendar/ HTTP/1.1
>
> Notice the last /, this should be a required item, so WebDav/CalDav  
> knows this is supposed to go into this directory as a generated file.
>
> Then the WebDav server could be extended to Generate the filename  
> itself.  For now CalDav, could extend the Put method to generate a  
> filename.  This would be doable, and it also makes for future use of  
> the same feature.  Thinking about doing a Contact directory, and a  
> Notes directory the same basic way, in the future.
>
> The response would include a Header item that tells the client the  
> generated name.  This would need to be put in the spec as well.
>
> -- Edited Entry --
> PUT /scarr/Calendar/msg01234.evt HTTP/1.1
>
> Here there wouldn't be a problem because the client already knows the  
> name of the file to save with.
>
> Does this make sense?  This sounds like a good extension to WebDav in  
> general.
>
> -- 
> Scott Carr
> OpenOffice.org
> Documentation Co-Lead
> http://documentation.openoffice.org
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 20 Jan 2005 15:31:42 -0800
From: Charles N Wyble <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] CalDAV Server Project

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Everyone,<br>
<br>
&nbsp;&nbsp;&nbsp; I want to bring to your attention a CalDAV server project of
interest. It is part of the open connector (<a class="moz-txt-link-abbreviated" href="http://www.openconnector.org">www.openconnector.org</a>)
project and shows promise. From the web page
(<a class="moz-txt-link-freetext" href="http://openconnector.org/caldav/">http://openconnector.org/caldav/</a>)......<br>
<br>
The goal of this sub-project is to develop a prototype CalDAV server
derived from the <a href="http://jakarta.apache.org/slide/">Apache
Slide</a> WebDAV server and a prototype client library functions
developed using Microsoft XML parser.<br>
<br>
Hope someone finds this interesting/helpful. <br>
<br>
<pre class="moz-signature" cols="72">-- 
Charles N Wyble
Homepage: <a class="moz-txt-link-freetext" href="http://www.thewybles.com/~charles">http://www.thewybles.com/~charles</a>
Blog: <a class="moz-txt-link-freetext" href="http://jackshck.livejournal.com">http://jackshck.livejournal.com</a>
Developer/Consultant. 30.00 an hour is my fee. 
</pre>
</body>
</html>

Date: Thu, 20 Jan 2005 17:28:44 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: [Ietf-caldav] Creating Items [ideas]

Continuation of this post:  [Thanks Mike for pointing me to it]
http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/000102.html

I agree, post/redirect would be way too complex of a design for this.

How about something like:

-- New Entry --
PUT /scarr/Calendar/ HTTP/1.1

Notice the last /, this should be a required item, so WebDav/CalDav 
knows this is supposed to go into this directory as a generated file.

Then the WebDav server could be extended to Generate the filename 
itself.  For now CalDav, could extend the Put method to generate a 
filename.  This would be doable, and it also makes for future use of the 
same feature.  Thinking about doing a Contact directory, and a Notes 
directory the same basic way, in the future.

The response would include a Header item that tells the client the 
generated name.  This would need to be put in the spec as well.

-- Edited Entry --
PUT /scarr/Calendar/msg01234.evt HTTP/1.1

Here there wouldn't be a problem because the client already knows the 
name of the file to save with.

Does this make sense?  This sounds like a good extension to WebDav in 
general.

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

Date: Thu, 20 Jan 2005 12:53:22 -0800
From: Mike Shaver <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] Event Naming in WebDav
Cc: ietf-caldav <[email-masked]>
Reply-To: Mike Shaver <[email-masked]>

On Thu, 20 Jan 2005 13:32:00 -0600, Scott Carr <[email-masked]> wrote:
> Are clients going to have to keep track of Resource naming themselves?
> 
> When an item is placed in the WebDav repository, is the client going to
> be required to specify a unique filename to save the event to?

Still an open issue.

This thread has some of the prior discussion on the topic:
http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/000102.html

Mike

Date: Thu, 20 Jan 2005 13:32:00 -0600
From: Scott Carr <[email-masked]>
To: ietf-caldav <[email-masked]>
Subject: [Ietf-caldav] Event Naming in WebDav

Are clients going to have to keep track of Resource naming themselves?

When an item is placed in the WebDav repository, is the client going to 
be required to specify a unique filename to save the event to?

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org 

Date: Wed, 19 Jan 2005 20:51:54 -0600 (CST)
From: "Scott Carr" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [Ietf-caldav] Re: CalDav Draft

Moving the discussion to the list.  Thanks, Lisa for letting me know about
the list.

Comments inline.

Lisa Dusseault said:
> Hi Scott,
>
> We're removing Scheduling from CalDAV in the -05 draft, which is in
> progress.  So we probably won't finalize the design of scheduling quite
> yet, but this is an interesting approach.

Is the scheduling being removed so the draft will be easier to approve? 
.. or is there some other reason?

>
> The problem of keeping the Originator's event and the Attendee's event
> synchronized is a very tough one.  In the worst case, the Originator is
> on one CalDAV server, and the Attendee is on a different CalDAV server,
> and there's no way for the two servers to access each other, or for
> either client to access the other person's server (both servers might
> be behind different firewalls, accessible via VPN).  So there is a UID
> (defined in the iCalendar specification) which might help depending on
> exactly what the use case is.  We probably need to add some language on
> that.

But, in the worst case, how are the events going to get to their
respective attendees anyway?  Would a directory that is not inside normal
ACL priviledge work?  Something like SMTP where there is no password to
send an event request.

>
> On Jan 18, 2005, at 9:10 PM, Scott Carr wrote:
>
>> http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html
>>
>> Section 9.3 Acting on iTip Messages
>>
>> You have in this section a TODO entry.
>>
>> With an iTip acceptance, would it be a good idea to have an AcceptEvent
>> method?  If we have an iTip store, wouldn't we have to know what state
>> a
>> specific iTip is in at any given point?  With an AcceptEvent method the
>> server would basically create the event in the users store, and set the
>> original message to an Accepted state, or delete the iTip message
>> totally.
>>
>> We would also have to send an iTip or some other message to the
>> Originators event store, to let them know that the user accepted the
>> event.  All this could be handled by the AcceptEvent method.
>>
>> Another issue I can see with this is how would we keep the event on the
>> Originators box in sync with the event in the Attendees.  Is there an
>> Event ID that would co-exist in each users event store?  If so, we
>> would
>> need to be able to initiate change requests across user storage
>> boundaries.
>>

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead

Date: Mon, 17 Jan 2005 12:12:48 -0700
From: Doug Royer <[email-masked]>
To: Jonathan Lennox <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] Re: IANA  Time Zone Registration
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2005 19:13:28 -0000

This is a cryptographically signed message in MIME format.

--------------ms030108000109080403050606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Thank you - I just sent the email.

Jonathan Lennox wrote:
> On Sunday, January 16 2005, "Doug Royer" wrote to "[email-masked], [email-masked], CalDAV DevList" saying:
> 
> 
>>A couple of years ago there was talk on the CALSCH mailing list
>>to have an IANA time zone registration process. I have submitted
>>a proposal for that registry to the IETF.
> 
> 
> This proposal should also be shared with the TZ mailing list,
> <[email-masked]>.
> 
> I note that your list of time zone names is out of date with respect
> to the current version of tzdata (2005b).
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

--------------ms030108000109080403050606
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

--------------ms030108000109080403050606--

From: Jonathan Lennox <[email-masked]>
Date: Mon, 17 Jan 2005 12:40:11 -0500
To: Doug Royer <[email-masked]>
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] Re: IANA  Time Zone Registration

On Sunday, January 16 2005, "Doug Royer" wrote to "[email-masked], [email-masked], CalDAV DevList" saying:

> A couple of years ago there was talk on the CALSCH mailing list
> to have an IANA time zone registration process. I have submitted
> a proposal for that registry to the IETF.

This proposal should also be shared with the TZ mailing list,
<[email-masked]>.

I note that your list of time zone names is out of date with respect
to the current version of tzdata (2005b).

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Date: Sun, 16 Jan 2005 16:10:45 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-caldav] IANA  Time Zone Registration
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 16 Jan 2005 23:10:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms040804090802090308080209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

]
A couple of years ago there was talk on the CALSCH mailing list
to have an IANA time zone registration process. I have submitted
a proposal for that registry to the IETF.

A copy can be found at:

	http://inet-consulting.com/draft-royer-timezone-registry-00.txt

And an HTML version:

	http://inet-consulting.com/draft-royer-timezone-registry-00.html

I am adding the POLYGON property targeted for the -01 version
that has an ADD/DELETE parameter to allow for the optional
inclusion of latitude/longitude geographic areas to be included
that include (add) and exclude (delete) areas from the time zone
geographic region (again from the CALSCH mailing list discussions).

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

--------------ms040804090802090308080209
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

--------------ms040804090802090308080209--

Date: Sun, 16 Jan 2005 14:11:43 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-caldav] draft-royer-ical-basic-01.txt - sent to IETF
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 16 Jan 2005 21:12:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms010605090304020907010903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I send -01 of iCal-Basis to the IETF. It fixed some problems and
typos that were sent to me and the lists. It also deprecates DTEND and
replaced the examples and ABNF with DURATION.

Copy at:

	http://inet-consulting.com/draft-royer-ical-basic-01.txt

And HTML version at:

	http://inet-consulting.com/draft-royer-ical-basic-01.html
	
-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

--------------ms010605090304020907010903
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

--------------ms010605090304020907010903--

Date: Mon, 10 Jan 2005 14:06:01 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: 
Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-royer-ical-basic-00.txt]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2005 21:06:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms040000010404040105070301
Content-Type: multipart/mixed; boundary="------------090801060904050606000008"

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

FYI

-------- Original Message --------
Subject: I-D ACTION:draft-royer-ical-basic-00.txt
Date: Mon, 03 Jan 2005 15:40:02 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Basic Internet Calendaring and Scheduling Core
			  Object Specification (iCalendar Basic)
	Author(s)	: D. Royer
	Filename	: draft-royer-ical-basic-00.txt
	Pages		: 104
	Date		: 2005-1-3
	
This is the second release of a iCalendar.  After having learned from
    RFC-2445.  This document represents the common objects needed for
    calendaring.  VTODO, VJOURNAL, VTIMEZONE, recurrence rules, and
    scheduling and their associated properties have been removed.  These
    removals are expected to appear in new memos at a later time and will
    be independent extensions of this specification.  The new EXTENSIONS
    property will exist to allow for compatible sets of extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-royer-ical-basic-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-royer-ical-basic-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-royer-ical-basic-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

--------------090801060904050606000008
Content-Type: Message/External-body;
 name="draft-royer-ical-basic-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-royer-ical-basic-00.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

--------------090801060904050606000008
Content-Type: text/plain;
 name="file:///tmp/nsmail.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="file:///tmp/nsmail.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------090801060904050606000008--

--------------ms040000010404040105070301
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

--------------ms040000010404040105070301--

Date: Mon, 03 Jan 2005 09:21:31 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> Since the URI is not supposed to be stable by the protocol and since  
> server side ID generation is nothing unusual either I don't consider  
> this very far fetched. But anyway.

To rephrase it differently: server-side URL assignment is quite common, 
but I have never seen it before used for PUT.

 > ...
>> Basically, the PUT operation defined in RFC2616 doesn't have the  
>> semantics CalDAV seems to require. Historically, servers have been  
>> using POST to a container resource to actually create new members. Is  
>> there a particular reason why CalDAV can't do the same?
> 
> 
> I also considered this. Why don't we require a POST on a collection to  
> create items? POST + 201 with location.

It seems to me that this would be the most straighforward way to spec it.

If a server wants to support PUT the way it's currently defined for teh 
sake of making demos with existing clients simpler, that's fine and 
simply an implementation issue. Just don't put *that* into the spec.

> For me I had the impression the PUT+location is perfectly valid and  
> that POST is somewhat too generic. POST also has the disadvantage that  
> it won't work with generic servers nor with generic clients. PUT isn't  
> a perfect fit for them but works for the majority.

I thought that generic clients weren't considered to be major focus? 
Maybe the spec should first state what the requirements are...

>> Thus this will not help with a generic client anyway. So what *are*  
>> the requirements? Do you expect a non-CalDAV-aware client to be able  
>> to PUT new events this way?
> 
> 
> I can only speak for myself, but I would not expect generic clients to  
> be very useful with CalDAV servers. Being able to drop an iCal file  
> into a WebDAV mounted iDisk is a nice demo but has little value in  
> practice.

See above: it's ok if a server implementor chooses to implement it that 
way for demo purposes; just don't make it the single (or recommended) 
way to do it.

> Personally I assumed that this paragraph was written with PUT in mind.  
> But I also found (POST 9.5):
> "If a resource has been created on the origin server, the response  
> SHOULD be 201
>  (Created) and contain an entity which describes the status of the  
> request and refers
>  to the new resource, and a Location header (see Section 14.30)."
> 
> 
> I'm still very interested on how to implement the mentioned  
> functionality in the best possible "HTTP way". Maybe POST is really the  
> way to go (but this will be completely unavailable to generic clients!  
> Interoperability is much worse than with PUT+loc).

Again: the spec should be clear about what it's trying to achieve. If 
generic PUT-aware clients are required to work then I think this is not 
generally achievable. If that's not the requirement, just define a 
different way that fits better into the HTTP framework.

Best regards, Julian

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Date: Sun, 2 Jan 2005 23:25:49 +0100
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On 2. Jan 2005, at 22:08 Uhr, Julian Reschke wrote:
> "The PUT method requests that the enclosed entity be stored under the  
> supplied Request-URI."

OK, 2:1 for you ;-)

> ...so I think the interpretation that the server may choose a  
> different URI is really far-fetched.

Since the URI is not supposed to be stable by the protocol and since  
server side ID generation is nothing unusual either I don't consider  
this very far fetched. But anyway.

> Using the Location response header is fine for methods that create new  
> resources in locations other than the request URI (such for instance a  
> POST). The question is whether it's ok to let PUT choose a different  
> location.

Si, thats the question.

>> Technically I don't see the issue with it either. The server is free  
>> to move the resource afterwards anyway, there is nothing in HTTP  
>> which ensures that a GET following the PUT will succeed (more  
>> exactly: no transactions).
>> Am I missing something?
>
> Of course a server can do anything it wants. How much it deviates in  
> doing this affects how well generic clients will work. Any generic  
> client that issues PUT requests today will assume that a 201 upon PUT  
> means that the resource indeed was created at the request URI.

Of course. 201 means the resource was created on the request URI. But  
the client may not assume that the same URI is still there after  
creation (Q: unless it locked the whole collection?) since HTTP systems  
are to be considered "heavily multiuser".

I don't think the major focus of CalDAV is being able to access a  
server using generic clients. Thats should be pretty useless except for  
debugging (and notably Cadaver doesn't have any issues with the  
mentioned PUT+location combination).

> Basically, the PUT operation defined in RFC2616 doesn't have the  
> semantics CalDAV seems to require. Historically, servers have been  
> using POST to a container resource to actually create new members. Is  
> there a particular reason why CalDAV can't do the same?

I also considered this. Why don't we require a POST on a collection to  
create items? POST + 201 with location.
For me I had the impression the PUT+location is perfectly valid and  
that POST is somewhat too generic. POST also has the disadvantage that  
it won't work with generic servers nor with generic clients. PUT isn't  
a perfect fit for them but works for the majority.

> Depends on the requirements. A generic client will not automatically  
> follow a redirect upon PUT because of the reasons given in  
> <http://greenbytes.de/tech/webdav/ 
> rfc2616.html#rfc.section.10.3.3.p.3>:

Thanks for the pointer, valid issue.

> Thus this will not help with a generic client anyway. So what *are*  
> the requirements? Do you expect a non-CalDAV-aware client to be able  
> to PUT new events this way?

I can only speak for myself, but I would not expect generic clients to  
be very useful with CalDAV servers. Being able to drop an iCal file  
into a WebDAV mounted iDisk is a nice demo but has little value in  
practice.

> If a spec that builds on HTTP chooses to override SHOULD-level  
> requirements of HTTP, I'd expect a very good rational for that.

Si.

> Right now, there doesn't seem to be a compelling reason except that it  
> reduces the amount of work for the authors of the spec :-).

I think I brought up a good reason (which you may accept or not). I  
still think that PUT+location is the best way to represent what one  
wants without affecting the idea behind the data/protocol model and  
retaining good interoperability at the same time.

>> Actually during this I found:
>>   http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30
>> it explicitly states:
>>   "For 201 (Created) responses, the Location is that of the new  
>> resource
>>    which was created by the request."
>> I assume this makes us happy? ;-)
>
> Nope (see above). Of course the Location header is the right thing to  
> use if a method creates a resource at a location other than the  
> Request-URI. The question was whether it's ok for PUT to actually do  
> that.

Personally I assumed that this paragraph was written with PUT in mind.  
But I also found (POST 9.5):
"If a resource has been created on the origin server, the response  
SHOULD be 201
  (Created) and contain an entity which describes the status of the  
request and refers
  to the new resource, and a Location header (see Section 14.30)."

I'm still very interested on how to implement the mentioned  
functionality in the best possible "HTTP way". Maybe POST is really the  
way to go (but this will be completely unavailable to generic clients!  
Interoperability is much worse than with PUT+loc).

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

Date: Sun, 02 Jan 2005 22:22:30 +0100
From: Julian Reschke <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Cc: CalDAV DevList <[email-masked]>

Here's another minor issue:

04-C17, Section 6.2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.6.2>

In the example response, the value for "ETag:" is invalid (ETags are 
always quoted, see 
<http://greenbytes.de/tech/webdav/rfc2616.html#header.etag>).

Best regards, Julian

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

Date: Sun, 02 Jan 2005 22:08:30 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> On 2. Jan 2005, at 20:29 Uhr, Julian Reschke wrote:
> 
>> From <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6>:
>>
>> "If the resource could not be created or modified with the 
>> Request-URI, an appropriate error response SHOULD be given that 
>> reflects the nature of the problem."
>>
>> That is, PUT is not allowed to succeed by creating a resource at a 
>> different URI.
> 
> 
> Hm, I'm not a native speaker, so its not unlikely I'm wrong, but "with 
> the Request-URI" is not the same like "*at* the Request-URI" to me.

Nor am I, but it also says...:

"The PUT method requests that the enclosed entity be stored under the 
supplied Request-URI."

...so I think the interpretation that the server may choose a different 
URI is really far-fetched.

> The resource could be successfully created "with" the URL, which is why 
> there is a 201. It afterward lives at a new URL, which is what is hinted 
> by the location header.

Using the Location response header is fine for methods that create new 
resources in locations other than the request URI (such for instance a 
POST). The question is whether it's ok to let PUT choose a different 
location.

> Technically I don't see the issue with it either. The server is free to 
> move the resource afterwards anyway, there is nothing in HTTP which 
> ensures that a GET following the PUT will succeed (more exactly: no 
> transactions).
> Am I missing something?

Of course a server can do anything it wants. How much it deviates in 
doing this affects how well generic clients will work. Any generic 
client that issues PUT requests today will assume that a 201 upon PUT 
means that the resource indeed was created at the request URI.

Basically, the PUT operation defined in RFC2616 doesn't have the 
semantics CalDAV seems to require. Historically, servers have been using 
POST to a container resource to actually create new members. Is there a 
particular reason why CalDAV can't do the same?

> ...
>> I'm not sure that using a 3xx is a good idea either, unless the server 
>> is going to continue to send redirects to the target resource.
> 
> 
> Good point. But 302 is a temporary redirect which assumes that the 
> redirect will go away, right? Again: what in HTTP requires that the 
> server ensures objects not going away?
> Anyway, I'm not really pleased with the 302 solution anyway, see above.

Depends on the requirements. A generic client will not automatically 
follow a redirect upon PUT because of the reasons given in 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.3.3.p.3>:

"If the 302 status code is received in response to a request other than 
GET or HEAD, the user agent MUST NOT automatically redirect the request 
unless it can be confirmed by the user, since this might change the 
conditions under which the request was issued."

Thus this will not help with a generic client anyway. So what *are* the 
requirements? Do you expect a non-CalDAV-aware client to be able to PUT 
new events this way?

>>> IMHO the 201+location says, yes, it was successfully created and just 
>>>  got moved afterwards. Just an optimization of 201 and a move by a  
>>> thirdparty (actually CalDAV might need to require a full rescan of a  
>>> collection [unless we have notifications], eg in case the server  
>>> 'flattened' cyclic events).
>>
>> But that's not the semantics of PUT as defined by RFC2616 (see above).
> 
> 
> Read that. But I don't see something which forbids it either, actually 
> the spec for PUT is very open being composed of a lot of SHOULD's.

 From RFC2119:

"3. SHOULD  This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course."

If a spec that builds on HTTP chooses to override SHOULD-level 
requirements of HTTP, I'd expect a very good rational for that. Right 
now, there doesn't seem to be a compelling reason except that it reduces 
the amount of work for the authors of the spec :-).

> Actually during this I found:
>   http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30
> 
> it explicitly states:
>   "For 201 (Created) responses, the Location is that of the new resource
>    which was created by the request."
> 
> I assume this makes us happy? ;-)

Nope (see above). Of course the Location header is the right thing to 
use if a method creates a resource at a location other than the 
Request-URI. The question was whether it's ok for PUT to actually do that.

Best regards, Julian

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Date: Sun, 2 Jan 2005 21:32:30 +0100
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On 2. Jan 2005, at 20:29 Uhr, Julian Reschke wrote:
> From <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6>:
>
> "If the resource could not be created or modified with the 
> Request-URI, an appropriate error response SHOULD be given that 
> reflects the nature of the problem."
>
> That is, PUT is not allowed to succeed by creating a resource at a 
> different URI.

Hm, I'm not a native speaker, so its not unlikely I'm wrong, but "with 
the Request-URI" is not the same like "*at* the Request-URI" to me.
The resource could be successfully created "with" the URL, which is why 
there is a 201. It afterward lives at a new URL, which is what is 
hinted by the location header.

Technically I don't see the issue with it either. The server is free to 
move the resource afterwards anyway, there is nothing in HTTP which 
ensures that a GET following the PUT will succeed (more exactly: no 
transactions).
Am I missing something?

> I'm not sure why this capability is needed, but if the protocol really 
> needs it, it could fail the PUT and return a new Request-URI in the 
> response headers or body (I'd put that into a DAV:error/precondition 
> element that contains a DAV:href).

IMHO we really need a way to represent "a method which creates the 
object on a new URL". It is a very common thing that the server will 
enforce maintenance of unique ids.
What I said before, a "redirect to URL, then PUT" is an improvement 
(covering an additional class of servers) but still leaves out some.

> I'm not sure that using a 3xx is a good idea either, unless the server 
> is going to continue to send redirects to the target resource.

Good point. But 302 is a temporary redirect which assumes that the 
redirect will go away, right? Again: what in HTTP requires that the 
server ensures objects not going away?
Anyway, I'm not really pleased with the 302 solution anyway, see above.

>> IMHO the 201+location says, yes, it was successfully created and just 
>>  got moved afterwards. Just an optimization of 201 and a move by a  
>> thirdparty (actually CalDAV might need to require a full rescan of a  
>> collection [unless we have notifications], eg in case the server  
>> 'flattened' cyclic events).
> But that's not the semantics of PUT as defined by RFC2616 (see above).

Read that. But I don't see something which forbids it either, actually 
the spec for PUT is very open being composed of a lot of SHOULD's.

Actually during this I found:
   http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30

it explicitly states:
   "For 201 (Created) responses, the Location is that of the new resource
    which was created by the request."

I assume this makes us happy? ;-)

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

Date: Sun, 02 Jan 2005 20:29:30 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> On 2. Jan 2005, at 19:53 Uhr, Julian Reschke wrote:
> 
>> 04-C06, Section 6.2
>>
>> <http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
>> -04.html#rfc.section.6.2>
>>
>> The example given (resource created at a different URI) seems to  
>> violate HTTP semantics: if PUT doesn't actually create a resource at  
>> the Request-URI, a status code of 201 (actually any 2xx code) seems 
>> to  be wrong.
> 
> 
> What would be your suggestion to fix this?
> 
> Return a 302 and then make the HTTP client repeat the PUT? (which has  
> the disadvantage that the server may not yet know the final location at  
> creation time).
> 
> Or is there any other 3xx code which could be used for 201+Location?
> 
> Actually you write "seems to be wrong", I find it quite natural, _is  
> it_ wrong or not? If yes, could you please point to the HTTP spec  
> positions in question?

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

"If the resource could not be created or modified with the Request-URI, 
an appropriate error response SHOULD be given that reflects the nature 
of the problem."

That is, PUT is not allowed to succeed by creating a resource at a 
different URI. I'm not sure why this capability is needed, but if the 
protocol really needs it, it could fail the PUT and return a new 
Request-URI in the response headers or body (I'd put that into a 
DAV:error/precondition element that contains a DAV:href).

I'm not sure that using a 3xx is a good idea either, unless the server 
is going to continue to send redirects to the target resource.

> IMHO the 201+location says, yes, it was successfully created and just  
> got moved afterwards. Just an optimization of 201 and a move by a  
> thirdparty (actually CalDAV might need to require a full rescan of a  
> collection [unless we have notifications], eg in case the server  
> 'flattened' cyclic events).

But that's not the semantics of PUT as defined by RFC2616 (see above).

Julian

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04
Date: Sun, 2 Jan 2005 20:12:55 +0100
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On 2. Jan 2005, at 19:53 Uhr, Julian Reschke wrote:
> 04-C06, Section 6.2
>
> <http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> -04.html#rfc.section.6.2>
>
> The example given (resource created at a different URI) seems to  
> violate HTTP semantics: if PUT doesn't actually create a resource at  
> the Request-URI, a status code of 201 (actually any 2xx code) seems to  
> be wrong.

What would be your suggestion to fix this?

Return a 302 and then make the HTTP client repeat the PUT? (which has  
the disadvantage that the server may not yet know the final location at  
creation time).

Or is there any other 3xx code which could be used for 201+Location?

Actually you write "seems to be wrong", I find it quite natural, _is  
it_ wrong or not? If yes, could you please point to the HTTP spec  
positions in question?

IMHO the 201+location says, yes, it was successfully created and just  
got moved afterwards. Just an optimization of 201 and a move by a  
thirdparty (actually CalDAV might need to require a full rescan of a  
collection [unless we have notifications], eg in case the server  
'flattened' cyclic events).

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

Date: Sun, 02 Jan 2005 19:53:50 +0100
From: Julian Reschke <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Comments on draft-dusseault-caldav-04

Hi,

below are my comments about the -04 draft (top-down read, focusing on 
WebDAV/HTTP questions with little Calendaring specific checks):

Best regards, Julian

--

04-C01 Section 1.1.1

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.1.1.1>

A few terminology problems here:

"WebDAV is an extension to the HTTP/1.1 [4] protocol, therefore its URLs 
are HTTP URLs."

That's a bit misleading, as there are other URLs used within WebDAV 
which aren't HTTP URLs, for instance lock tokens.

"If HTTP GET can be used to represent a calendar object..."

GET doesn't represent objects, it *retrieves* representations of objects.

In general, this probably should be re-organized into two parts:

1) why it's good to have retrievable URIs for calendar objects, thus HTTP
2) why it's good to re-use existing HTTP extensions, thus WebDAV

04-C03 Section 1.1.8

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.1.1.8>

"Dead properties are client-controlled properties, where the namespace, 
name and value are entirely controlled by the client. However, the 
server is required to store these properties and return them, if 
requested, in PROPFIND queries for individual resources or in listings 
of collection contents."

Why: "however"?

"Some servers support text searching on all dead properties through the 
DASL extensions (a work in progress) [TODO: REF]. Dead properties can 
also be used in reports."

Missing reference.

04-C04, Section 6

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.6>

"Calendars and individual calendar objects may all be created by either 
the CalDAV client or by the CalDAV server."

This is misleading. It's always the server thst creates objects. If this 
is about who *initiates* the creation, this should be clarified.

04-C05, Section 6.1

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.6.1>

"The successful response to MKCALENDAR is typically 201 (Created)."

What is "typically" supposed to mean? Please either be precise here or 
remove that sentence (thus RFC2616 applies).

"Note that there is no semantic value in any other part of a calendar 
name (or a resource name, other than possibly the file extension)."

No, not even the file extension. Neither HTTP nor WebDAV have a notion 
of "file extension".

"Thus, a calendar collection may be called "calendar", "cal", 
"Calendario" and so on. It's the properties of the resource that define 
what it is, not the name.""

It's the DAV:resourcetype property, right? Why not simply say so?

04-C06, Section 6.2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.6.2>

The example given (resource created at a different URI) seems to violate 
HTTP semantics: if PUT doesn't actually create a resource at the 
Request-URI, a status code of 201 (actually any 2xx code) seems to be wrong.

04-C07, Section 7

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.7.p.3>

"A server supporting CalDAV MUST support additional properties on 
principal resources if these principals are associated with calendars. 
In addition, certain properties are required on calendars to link to 
principal resources. These properties are defined in the properties 
section."

This additional requirement will make some existing RFC3744 
implementations unable to conform to this spec. I think this is a 
problem, and an alternate solution (not requiring custom properties on 
principal resources) should be discussed.

04-C08, Section 9

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.9.p.8>

It's unclear why the discussion about PUT vs PROPPATCH vs SCHEDULE is 
still in when the document indeed defines a SCHEDULE method in section 9.1.

(editorial note: it would be nice if editorial comments and notes would 
use RFC2629's <cref> element for better readability)

04-C09, Section 9.1

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.9.1>

Why is the title "SCHEDULE method for WebDAV"? What does it make a 
method for WebDAV, rather than an HTTP method? What's the difference?

Also, it would be good if the method description would be a bit more 
formal in defining the new HTTP request headers (ABNF?). (forward 
reference to section 10?)

04-C10, Section 9.1.1

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.9.1.1>

There seems be some confusion about when to return a 207 and when not. 
For instance, I'd expect a malformed request body to result in a HTTP 
status of 400. Also, the multistatus response for a successful request 
needs to be more formally defined (such as: must contain response 
elements for each Recipient reuqest header URI).

04-C11, Section 11

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.11>

Which XML namespace are the has-* properties in?

04-C12, Section 12

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.12.p.2>

"Note that the XML Schema declarations used in this document are 
incomplete, in that they do not include namespace information."

There are no XML Schema declarations in this document.

04-C13, Section 12.2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.12.2>

I think it would be good if the document would explain what this 
property is used for.

04-C14, Section 13

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.13>

"Generally, if no appropriate value is known for these properties, the 
properties SHOULD exist but be blank."

This seems to be inconsistent with other WebDAV properties (which will 
simply not be present when not applicable.

Also need to specify whether these are live or dead properties, and if 
they are live, whether protected or not. Furthermore, if live the spec 
should define whether they should appear on propfind/allrop (same 
applies to the properties defined in section 12).

04-C15, Section 15

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.15>

The introduction should point to the normative definition of the REPORT 
method (RFC3253, 3.6) and it also needs to define whether the 
DAV:expand-property-report (3.8) is mandatory (it is in RFC3253 and 
RFC3744).

Also, error marshalling shouldn't be repeated (is it the same as in 
RFC3253? If not, why?), and usage of the DAV:error response element 
needs to be consistent with RFC3253.

04-C16, Section 15.1

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.15.1>

Should define the role of the Depth request header when applied to a 
collection resource.

04-C17, Section 15.2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.15.2>

There doesn't seem to be a definition of the calendar-query-result 
request element.

It's a bit unclear why the spec needs to extend multistatus, that is, 
why the requested ical information can't be returned in the form of 
promoted properties (I think this would greatly simplify the spec).

04-E01, References

The following references are not used (RFC2629-wise) in the text:

WARNING: unused reference 'RFC3339'
WARNING: unused reference 'RDF-ICAL'
WARNING: unused reference 'I-D.reschke-webdav-search'

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