Calendar Availability
draft-ietf-calext-availability-04

Agree with Stephen's DISCUSS.

- 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.)

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

- 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?”

"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? 

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

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

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

- 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."

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

Here is Qin Wu's OPS DIR review on v3. The discussion is well engaged with the authors, and changes will be applied to the next version.



I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This document proposes a new iCalendar calendar component that allows the publication of available and unavailable time periods associated with a calendar user and further extends CalDAV calendar-access and calendar-auto-schedule to allow free-busy looksup to use the information from the new iCalendar availability components.

I think this document is ready for publication. Here are a few editorial comments:

 

1.       Paragraph 4,5 of section 1:

Is Update to RFC4791 required when you introduce an extension to CALDAV calendar-acess and CALDAV calendar-auto-schedule features?

Can new iCalendar availability component work together with VERFY component? Or They are exclusive.

 

2．Section 4

How VALAILABILITY component works together with VERYBUSY component? It looks the section 3 is about how one VAVAILABILITY component works together with another VAVAILABILITY component while the section 5 is about one VAVAILABILITY component works together with other component? Would you like to make this clear in the section title or in the texts of each section.

 

3. Last paragraph of section 4

Since the range for priority property value is {0,9~1}, spacing out method doesn’t looks scalable suppose you have 20 components that need to be ordered by priority.

 

Is there any default priority difference between two intersecting component with different priority value? In your example, it seems you choose 2?

 

4. The 3rd paragraph of section 5

s/ first available time /first the available time

 

5.Example procedure in the section 5

Suggest to move all the example to one place .e.g., appendix A since it is hard to understand when some example snippet in one place and other example snippet in the appendix.

 

6. Section 5, step 2 of example procedure said:

“

Append the "VAVAILABILITY" component to a list of components

           for further processing in step 3, if it has not been ignored.

”

Step 3 is confusing, since the example procedure has a third step, in the second step, there is also a 3rd step. Suggest change 4 steps in the step 2 into sub step such as step 2.1, step 2.2, step 2.3, step 2.4 Then you will clear the confusing step 3 in the step 2 with step 3 in the example procedure.

 

7. Section 5, the first paragraph said:

“

In the examples below a table is used to represent time slots for the

   period of a free-busy request.

”

There are two tables in the section 5.1, which table are you referred to? I believe it is the second table, I would suggest to add a number and title for each table and then you can reference table number to clear the confusing introduced here.

 

8. Section 5.1.2

Would you like to generate a similar table as one in the section 5.1.1?

 

9. Section 7.1 said:

“

"VAVAILABILITY" components are treated in a manner similar to

   "VEVENT" and "VTODO" components,

”

How VENET and VTDO component are treated? In which way? Can you provide a reference which discuss how VEVENT component is treated?

 

-Qin

FWIW, I checked the ABNF.

I agree with Stephen's discuss.

Thanks for the addition to section 9.