Re: [calsify] Ben Campbell's No Objection on draft-ietf-calext-availability-03: (with COMMENT)

[Cyrus Daboo <[e-mail]>]

Hi Ben,
Thanks for your review. My comments are below.

--On July 6, 2016 at 1:13:34 PM -0700 Ben Campbell <[e-mail]> wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - General: I agree with Stephen's discuss comment. (And have some
> additional comments on that section, below.)
>
> - 7.1.1, first paragraph: "A value of "calendar-availability" in the
>    DAV response header MUST indicate that the server supports all MUST
>    level requirements specified in this document."
>
> The nested MUSTs are confusing. Do I correctly understand the intent to
> be that a value of “calendar-availability”  means the server supports
> this document? (It’s not necessary to say “supports all the MUSTs”,
> because that is the definition of supporting this document.)

I have changed that text to:

   A server supporting the features described in this document MUST
   include "calendar-availability" as a field in the DAV response header
   from an OPTIONS request.  A value of "calendar-availability" in the
   DAV response header indicates to clients that the server supports all
   the requirements specified in this document.


> -7.2.2, first paragraph:  Does this draft need to update 4791?

Yes. I already made that change in response to a similar comment in the 
OPS-DIR review.

> - 7.2.4, conformance: "Support for this
>       property is REQUIRED."
>
> What is required to support it? Does this mean something more than
> “Servers that support it are REQUIRED to support it?”

We've been using that terminology since RFC 4791. It basically relates back 
to the statement about the DAV header "capability" - i.e., if that 
"capability" is advertised then the server has to support all the 
requirements related to the property.

> "only a single "VAVAILABILITY" component
>       MUST be present in the property."
>
> Language of the form of “only one MUST be present” is ambiguous. Does
> this mean the property MUST have exactly one? MUST NOT have more than
> one?

I removed that sentence, and instead adjusted a prior sentence to read:

      The value of this property MUST be a valid
      iCalendar object containing only one "VAVAILABILITY" component,
      and optionally, "VTIMEZONE" components - other iCalendar
      components MUST NOT be present.

> -8, first paragraph:"servers MAY limit
>    the complexity"
> Is MAY strong enough here? Does it make since to ever allow arbitrarily
> complex information?

Agreed. I think a MUST makes sense here to force implementors to think 
about what limits they need to apply. I will make that change.

> -9, first paragraph: Does this imply a requirement for confidentiality
> protection on the wire? (Does caldae already require that?)

This statement was not about TLS (which CalDAV only requires if basic auth 
is in use as per RFC4791). It is about verifying who is requesting 
free-busy and only processing the request if they are authorized to be 
given such information.

As far as CalDAV security/privacy issues are concerned, I know Stephen is 
keen to start a general discussion on that to see if we can tighten up the 
specs (though I am pretty sure nearly every service already uses TLS 
everywhere).

> - 2nd paragraph: Seems like this could say more. For example. doesn’t
> this imply that a system needs to give users a way to specify who should
> get more or less information?

I think that is covered by the last sentence in the changes I proposed in 
response to Stephen's review:

    Thus, calendaring systems allowing "VAVAILABILITY" components to be
    sent or shared to other calendar users, MUST provide a way for
    non-essential properties to be removed (e.g., "SUMMARY", "LOCATION",
    and "DESCRIPTION").

> - last paragraph: I don't think this is an appropriate use of a 2119
> "MUST". Please consider something of the form of "Privacy Considerations
> in [refs] also apply."

Um OK. But draft-ietf-calext-extensions-05 was approved with exactly the 
same language. So to clarify, you would like me to change that text in both 
this draft and the other, and in both Security and Privacy section?

> - 10.1 and 10.2: The referenced sections of 5545 do not contain the
> registry definitions. (Rather, they contain the initial populations.)

Again, the same references were used in draft-ietf-calext-extensions-05. 
Practcally speaking, RFC5545 does not formally define the registries. 
Instead, section 8.2 defines the overal process for the various registries 
that are needed. The sub-sections of 8.2 then define templates for use with 
various registries. The items in section 8.3 are really what IANA keyed off 
for the creation of the registries.


-- 
Cyrus Daboo