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,

below are last call comments, interleaved with the spec text.

Best regards, Julian

--

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


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.

Section 2., para. 5:

    o  MUST support transport over TLS [RFC2246] as defined in [RFC2818]
       (note that [RFC2246] has been obsoleted by [RFC4346]); [[anchor6:
       I assume that the down reference to RFC2818 (informational RFC) is
       intended; but what about the stuff with RFC2246?  Why doesn't spec
       refer to RFC4346 instead? --reschke]]

Section 3.1., para. 4:

    The CalDAV server or repository is the canonical location for
    calendar data and state information. [[anchor8: "server or
    repository": I think it would be good if the spec would choose one
    term and stick with it --reschke]] Both CalDAV servers and clients
    MUST ensure that the data is consistent and compliant. [[anchor9:
    What does it exactly mean for the data to be "consistent" and
    "compliant"?  If there's no exact definition for that then the "MUST"
    should go --reschke]] Clients may submit requests to change data or
    download data.  Clients may store calendar objects offline and
    attempt to synchronize at a later time.  However, clients MUST be
    prepared for calendar data on the server to change between the time
    of last synchronization and when attempting an update, as calendar
    collections may be shared and accessible via multiple clients.
    Entity tags and other features make this possible.


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

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

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

Section 6.2.1., para. 4:

    Conformance:  This property MAY be defined in a principal resource.
       If defined, it MAY be protected and SHOULD NOT be returned by a
       PROPFIND DAV:allprop request (as defined in Section 14.2 of
       [I-D.ietf-webdav-rfc2518bis]).  Support for this property is
       RECOMMENDED. [[anchor24: Doesn't compute.  Is this a MAY
       (OPTIONAL) or a SHOULD (RECOMMENDED)? --reschke]]

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

Section 7.7.6., para. 1:

    In this example, the client requests the server to return the VEVENT
    component that has the UID property set to
    "DC6C50A017428C5216A2F1CD@xxxxxxxxxxx". [[anchor37: Is whitespace
    significant here?  In which case the example below would be invalid.
    -reschke]]

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.

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

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

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


_______________________________________________

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]