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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Julian,

--On August 29, 2006 9:17:11 AM +0200 Julian Reschke <julian.reschke@xxxxxx> 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.

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.

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.


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.


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.

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.

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.

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.

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.

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.

--
Cyrus Daboo


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]