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

Re: Comments on draft-dusseault-caldav-04

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,

Re: Comments on draft-dusseault-caldav-04

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 

Re: Comments on draft-dusseault-caldav-04

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.

Re: Comments on draft-dusseault-caldav-04

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 

Re: Comments on draft-dusseault-caldav-04

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

Re: Comments on draft-dusseault-caldav-04

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.

Re: Comments on draft-dusseault-caldav-04

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? 

[Fwd: I-D ACTION:draft-royer-ical-basic-00.txt]

FYI

-------- Original Message --------
Subject: I-D ACTION:draft-royer-ical-basic-00.txt
Date: Mon, 03 Jan 2005 15:40:02 -0500
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

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

draft-royer-ical-basic-01.txt - sent to IETF

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
-------------------------------|-----------------------------
Doug <at> Royer.com                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

_______________________________________________
Ietf-caldav mailing list
Ietf-caldav <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav