Calendar Availability
draft-ietf-calext-availability-04

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

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

[Ballot comment]
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

[Ballot discuss]

section 9: First, thanks for this, good to see it here.
Second, is "might need to be removed" sufficient in the 2nd
para? I don't think it is really. Wouldn't it be better to
say something more like "unless other information (e.g. a
user preference) is available, such attributes MUST be
removed"? If so, then I'd also add the list of attributes
or property values that are ok to leave in, or the list
that MUST be removed.

[Ballot comment]

- abstract - what're iCalendar and iTIP? Better to not use
such in the abstract if you can think of a way to explain in
natural language.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-calext-availability-03.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, IANA understands that there are two actions which must be completed. IANA also notes that the authors have requested the Expert Review required for registrations requested in the IANA Considerations section of the current document.

First, in the Component subregistry of the iCalendar Element Registries located at:

https://www.iana.org/assignments/icalendar/

two new iCalendar components are to be registered as follows:

Component: VAVAILABILITY
Status: Current
Reference: [ RFC-to-be ]

Component: AVAILABLE
Status: Current
Reference: [ RFC-to-be ]

Second, in the Property subregistry of the iCalendar Element Registries located at:

https://www.iana.org/assignments/icalendar/

a single, new iCalendar property is to be registered as follows:

Property: BUSYTYPE
Status: Current
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-calext-availability@ietf.org, daniel.migault@ericsson.com, calext-chairs@ietf.org, calsify@ietf.org, alexey.melnikov@isode.com, "Daniel Migault"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Calendar Availability) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG
(calext) to consider the following document:
- 'Calendar Availability'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a new iCalendar calendar component that
  allows the publication of available and unavailable time periods
  associated with a calendar user.  This component can be used in
  standard iCalendar free-busy lookups, including iTIP free-busy
  requests, to generate repeating blocks of available or busy time with
  exceptions as needed.

  This document also defines extensions to CalDAV calendar-access and
  calendar-auto-schedule which specify how this new calendar component
  can be used when doing free-busy time evaluation in CalDAV.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-calext-availability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-calext-availability/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The document status is in Standards Track which is appropriated to define a new iCalendar component and properties [RFC5545].

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies a new iCalendar calendar component that
  allows the publication of available and unavailable time periods
  associated with a calendar user.  This component can be used in
  standard iCalendar free-busy lookups, including iTIP free-busy
  requests, to generate repeating blocks of available or busy time with
  exceptions as needed.

  This document also defines extensions to CalDAV calendar-access and
  calendar-auto-schedule which specify how this new calendar component
  can be used when doing free-busy time evaluation in CalDAV.

Working Group Summary

  The document was approved by 7 people to be a working group document. Two people commented the document while implementing it. The document was approved by 2 non-authors during the WGLC. No one objected. Actually one asked for clarifications and then approved the current version.

Document Quality

  The document is well written. From Mailing list discussions two people have implemented these components. One implementers asked clarifications, and the document reflects these discussions.

Personnel

  Daniel Migault is the document shepherd and Alexey Melnikov is the Responsibel AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Daniel Migault  reviewed the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The current document has been implemented by two persons reviewing the document. Clarifications have been discussed while being implemented. All concerns have been addressed by the author.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document describes a new CALDAV component. I do not think special XML reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

The authors Cyrus Daboo and Mike Douglass have confirmed they are not aware of any IPR related to the draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

This document has no IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG is not very active, so the agreement could not represent a strong consensus. However, given the component's complexity the quality of the reviews, I believe the consensus is sufficient.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one opposed the WGLC.

(11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits have been detected.
ID-nits link from the document's datatracker page reports:
== Missing Reference: 'WGLC' is mentioned on line 959, but not defined

But the text mentioned is in appendix B that is expected to be removed.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

IANA Expert review has been requested. Minors modifications were asked to be provided. Cyrus is addressing them in the 03 version .

(13) Have all references within this document been identified as either normative or informative?

References are only normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All references are RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document does not change status of other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The names of components and properties have been appropriately documented in the IANA section. Templates used for the definition follow standard templates defined in RFC5545.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Bernard Desruisseaux, Cyrus Daboo are the designated IANA experts for Icalendar components and properties.  https://www.iana.org/assignments/icalendar/icalendar.xhtml
IANA Expert review has been requested. Minors modifications were asked to be provided. Cyrus is addressing them in the 03 version .


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

I review the document, conformance to the templates for IANA registration, rad ABNF checks have been performed and a empty line was generating an error. Cyrus is adressing this error in the version 03.

AD review:

One small nit:

3.1.  VAVAILABILITY Component

  availabilityprop  = *(
                    ;
                    ; the following are REQUIRED,
                    ; but MUST NOT occur more than once
                    ;
                    dtstamp / uid
                    ;
                    ; the following are OPTIONAL,
                    ; but MUST NOT occur more than once
                    ;
                    busytype / class / created / description /

But draft-ietf-calext-extensions-03, Section 5.3 says:

  Conformance:  This property can be specified multiple times in an
      iCalendar object.  However, each property MUST represent the
      description of the calendar in a different language.


                    dtstart / last-mod / location / organizer /
                    priority /seq / summary / url /



Similarly:

  availableprop  = *(
                ;
                ; the following are REQUIRED,
                ; but MUST NOT occur more than once
                ;
                dtstamp / dtstart / uid /
                ;
                ; Either 'dtend' or 'duration' MAY appear in
                ; an 'availableprop', but 'dtend' and
                ; 'duration' MUST NOT occur in the same
                ; 'availableprop'.
                ;
                dtend / duration /

                ;
                ; the following are OPTIONAL,
                ; but MUST NOT occur more than once
                ;
                created / description / last-mod /

the comment for description is not correct.

                location / recurid / rrule / summary /