Subject: Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Aug 2006 20:41:20 +0200

Cyrus Daboo schrieb:
>> Section 1.2., para. 3:
>>
>>
>>      The XML declarations used in this document do not include namespace
>>      information.  Thus, implementers MUST NOT use these declarations as
>>      the only way to create valid CalDAV properties or to validate CalDAV
>>      XML element type. [[anchor5: "...MUST NOT use these declarations as
>>      the only way..." is extremly hard to understand; the presence of
>>      RFC2119 keywords make things worse in that the reader is confused to
>>      believe that a normative statement is being made.  As far as I can
>>      tell, all this wants to say is that the missing namespace needs 
>> to be
>>      taken into account.  Please clarify. --reschke]] Some of the
>>      declarations refer to XML elements defined by WebDAV
>>      [I-D.ietf-webdav-rfc2518bis] which use the "DAV:" namespace.
>>      Wherever such XML elements appear, they are explicitly prefixed with
>>      "DAV:" to avoid confusion.
>>
>> -> Not fixed.
> 
> We wanted to put emphasis on this issue because we had heard of 
> interoperability problems in the past, but perhaps you are right in that 
> we can downgrade to non-2119 terminology.

Thanks. Keep in mind that RFC2119 keywords are for implementations, not 
implementers.

>> Section 5.2.4., para. 5:
>>
>>
>>      Description:  The CALDAV:supported-calendar-data property is used to
>>         specify the media type supported for the calendar object 
>> resources
>>         contained in a given calendar collection (e.g., iCalendar version
>>         2.0).  Any attempt by the client to store calendar object
>>         resources with a media type not listed in this property MUST
>>         result in an error, with the CALDAV:supported-calendar-data
>>         precondition (Section 5.3.2.1) being violated.  In the absence of
>>         this property the server MUST accept data with the media type
>>         "text/calendar" and iCalendar version 2.0, and clients can assume
>>         that. [[anchor15: What about other types in this case? 
>> --reschke]]
>>
>> -> Not changed. Does this mean it MAY accept others in this case?
> 
> Actually we did change this - we added the word 'only' to give 'MUST 
> only accept data' - i.e. only text/calendar is allowed when the property 
> is not present.

OK then. Thanks.

>> Section 5.3.1., para. 3:
>>
>>
>>      Clients SHOULD use the DAV:displayname property for a human-readable
>>      name of the calendar.  Clients can either specify the value of the
>>      DAV:displayname property in the request body of the MKCALENDAR
>>      request, or alternatively issue a PROPPATCH request to change the
>>      DAV:displayname property to the appropriate value immediately after
>>      issuing the MKCALENDAR request.  Clients SHOULD NOT set the DAV:
>>      displayname property to be the same as any other calendar collection
>>      at the same URI "level".  When displaying calendar collections to
>>      users, clients SHOULD check the DAV:displayname property and use 
>> that
>>      value as the name of the calendar.  In the event that the DAV:
>>      displayname property is empty, the client MAY use the last part of
>>      the calendar collection URI as the name, however that path segment
>>      may be "opaque" and not represent any meaningful human-readable 
>> text.
>>      [[anchor17: This seems to profile DAV:displayname as defined by
>>      RFC2518bis.  Furthermore it's not clear what happens when the client
>>      violates the constraint. --reschke]]
>>
>> -> Not fixed.
> 
> Agreed - we wanted the 2518bis clarification for this as we feel it is 
> important to use the displayname property here. As to violating the 
> unique displayname requirement - that does not affect the protocol as 
> URIs are always used in the protocol to refer to resources. All it will 
> do is result in two calendars with the same name in the client UI.

Well. If this doesn't affect the protocol, there's no reason to throw 
normative requirements in. If you're really concerned with what the 
DAV:displayname semantics implies for a UI that uses it instead of the 
URI or last path segment, just state that.

>> Section 5.3.4., para. 4:
>>
>>
>>      In the case where the data stored by a server as a result of a PUT
>>      request is not equivalent by octet equality to the submitted 
>> calendar
>>      object resource, the behavior of the ETag response header is not
>>      specified here, with the exception that a strong entity tag MUST NOT
>>      be returned in the response.  As a result, clients may need to
>>      retrieve the modified calendar object resource (and ETag) as a basis
>>      for further changes, rather than use the calendar object resource it
>>      had sent with the PUT request. [[anchor22: See comments on ietf-
>>      discuss mailing list. --reschke]]
>>
>> -> Not fixed.
> 
> Correct.

Yet, this is the problem I'm concerned about most.

>> Section 7.5., para. 1:
>>
>>
>>      Some calendaring REPORTs defined in this document allow partial
>>      retrieval of calendar object resources.  A CalDAV client MAY specify
>>      what information to return in the body of a calendaring REPORT
>>      request. [[anchor29: Why does this simple statement require RFC2219
>>      terminology?  Please don't over-use it.  In particular, please check
>>      that all "MAY" requirements really are needed for the purposes
>>      outlined in RFC2219. --reschke]]
>>
>> -> This one was fixed, but I think there are more of these, such as in
>> para 2.
> 
> Agreed several of the other paragraphs in that section need to use 'may' 
> instead of 'MAY'. We will provide a note to the RFC editor for that.

I appreciate that you want to change that, but I really think this needs 
to be done by the authors, and be reviewed before things get published.

>> Section 7.8., para. 4:
>>
>>
>>         The request body MUST be a CALDAV:calendar-multiget XML element
>>         (see Section 9.9).  If the Request-URI is a collection resource,
>>         then the DAV:href elements MUST refer to calendar object 
>> resources
>>         within that collection, and they MAY refer to calendar object
>>         resources at any depth within the collection.  As a result the
>>         "Depth" header MUST be ignored by the server and SHOULD NOT be
>>         sent by the client. [[anchor42: Bad idea.  Just stick with
>>         RFC3253/RFC3744 terminology (invalid depth values are rejected by
>>         the server, not ignored).  This leaves the possibilily to later
>>         define semantics for these values. --reschke]] If the Request-URI
>>         refers to a non-collection resource, then there MUST be a single
>>         DAV:href element that is equivalent to the Request-URI.
>>
>> -> Not fixed.
> 
> We felt multiget was a special case here as depth is really not relevant 
> since the actual resources 'touched' by the report are explicitly listed 
> in the request. i.e. the server does not do any hierarchy traversal 
> per-se as it would for PROPFIND or other REPORTs, so Depth is never 
> going to be used.

By doing it differently than the other specs, you take away a future 
extension point. This may be harmless in this case, but it would be 
*mich* easier for readers *and* implementors if this REPORT wouldn't 
behave differently from others. Please make it a "must reject" instead 
of a "must ignore". In which case the client requirement can go.

>> Section 8.4., para. 3:
>>
>>
>>      For calendar sharing and scheduling use cases, one might wish to 
>> find
>>      the calendar belonging to another user.  If the other user has a
>>      calendar in the same repository, that calendar can be found by using
>>      the principal namespace required by WebDAV ACL support.  For other
>>      cases, the authors have no universal solution but implementers can
>>      consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards
>>      together with calendar attributes [RFC2739]. [[anchor55: LDAP
>>      reference is outdated. --reschke]]
>>
>> -> Not fixed.
> 
> Will get fixed via note to RFC editor.

OK.

>> Section 8.5.2., para. 1:
>>
>>
>>      CalDAV clients SHOULD support downloading of external attachments
>>      referenced by arbitrary URI schemes, by either processing them
>>      directly, or by passing the attachment URI to a suitable "helper
>>      application" for processing, if such an application exists.  CalDAV
>>      clients MUST support downloading of external attachments referenced
>>      by the "http" URI scheme, and MAY support downloading of external
>>      attachments referenced by the "https" URI scheme.  An external
>>      attachment could be: [[anchor59: Very confusing: MAY, SHOULD and 
>> MUST
>>      requirements for basically the same thing.  In particular, the MAY
>>      for "https" is bogus, because the spec just stated that the client
>>      SHOULD support arbitrary schemes. --reschke]]
>>
>> -> Not fixed.
> 
> We did not feel this needed to be changed.

I don't get how it makes sense to state "SHOULD support arbitrary 
schemes, MAY support https". So "http" is MUST, and everything except 
"https" is SHOULD, while "https" is MAY? Is this really the intention??

>> Section 9.5., para. 7:
>>
>>
>>      Note:  The CALDAV:calendar-data XML element is specified in requests
>>         and responses inside the DAV:prop XML element as if it were a
>>         WebDAV property.  However, the CALDAV:calendar-data XML 
>> element is
>>         not a WebDAV property and as such it is not returned in PROPFIND
>>         responses nor used in PROPPATCH requests. [[anchor62: For this
>>         reason, I think a syntax where it can't be confused with a
>>         property whould be better. --reschke]]
>>
>> -> Not fixed, but I didn't expect that :-)
> 
> Right - such a change would be a major change to the spec and would 
> seriously impact many existing implementations. Note that we did 
> originally have the calendar-data element as a non-property element in 
> the multi-status response, but that lead to issues with how to indicate 
> that there was an error with reading that data as opposed to 
> error/success with the properties. i.e. we would have had to increase 
> the amount of extra XML in the multi-status to tie together a status 
> element with the calendar-data. Overall it was felt making it a property 
> would be better all around.

Best regards, Julian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 30 Aug 2006 16:58:38 -0400

> Yet, this is the problem I'm concerned about most.

Why can't the CalDAV spec note the ambiguity with Etags and move on? I
don't think it's appropriate for this document add semantics to the
general purpose ETag header with a MUST NOT, since "calendar object
resource" is meaningless from a general HTTP perspective.

also concerned,

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 29 Aug 2006 14:12:17 -0400

Hi Julian,

--On August 29, 2006 9:17:11 AM +0200 Julian Reschke 
<[email-masked]> wrote:

>> FYI Many of your comments were addressed in -14, several of the others
>> (outdated references) etc will be fixed by the RFC editor. I apologize
>> that we did not reply to you original message to let you know what had
>> been done.
>
> OK,
>
> I'll re-check my list then:
>
> Section 1., para. 2:
>
>
>      Discussion of this specification is taking place on the mailing list
>      <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
>      [[anchor2: Clarify that this paragraph should be removed upon
>      publication --reschke]]
>
> -> Not fixed.

Will be taken care of by note to RFC editor.

>      tell, all this wants to say is that the missing namespace needs to be

We wanted to put emphasis on this issue because we had heard of 
interoperability problems in the past, but perhaps you are right in that we 
can downgrade to non-2119 terminology.

>         specify the media type supported for the calendar object resources
>         that. [[anchor15: What about other types in this case? --reschke]]
>

Actually we did change this - we added the word 'only' to give 'MUST only 
accept data' - i.e. only text/calendar is allowed when the property is not 
present.

>      users, clients SHOULD check the DAV:displayname property and use that
>      may be "opaque" and not represent any meaningful human-readable text.

Agreed - we wanted the 2518bis clarification for this as we feel it is 
important to use the displayname property here. As to violating the unique 
displayname requirement - that does not affect the protocol as URIs are 
always used in the protocol to refer to resources. All it will do is result 
in two calendars with the same name in the client UI.

>      request is not equivalent by octet equality to the submitted calendar

Correct.

>         then the DAV:href elements MUST refer to calendar object resources

We felt multiget was a special case here as depth is really not relevant 
since the actual resources 'touched' by the report are explicitly listed in 
the request. i.e. the server does not do any hierarchy traversal per-se as 
it would for PROPFIND or other REPORTs, so Depth is never going to be used.

> Section 8.4., para. 3:
>
>
>      For calendar sharing and scheduling use cases, one might wish to find

>      attachment could be: [[anchor59: Very confusing: MAY, SHOULD and MUST

>         WebDAV property.  However, the CALDAV:calendar-data XML element is

Right - such a change would be a major change to the spec and would 
seriously impact many existing implementations. Note that we did originally 
have the calendar-data element as a non-property element in the 
multi-status response, but that lead to issues with how to indicate that 
there was an error with reading that data as opposed to error/success with 
the properties. i.e. we would have had to increase the amount of extra XML 
in the multi-status to tie together a status element with the 
calendar-data. Overall it was felt making it a property would be better all 
around.

-- 
Cyrus Daboo