iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-10

[Ballot comment]
3.2.2.3.  Delegating an Event to another CU

  In response to the request, the "Delegate" MUST send a "REPLY" method
  to the "Organizer" and optionally, to the "Delegator".  The "REPLY"
  method SHOULD include the "ATTENDEE" property with the "DELEGATED-
  FROM" parameter value

The SHOULD sounds a bit too weak here.

  of the "Delegator's" calendar address.

5.1.1.  Event-Related Fallbacks

  +----------------+--------------------------------------------------+
  | Method        | Fallback                                        |
  +----------------+--------------------------------------------------+
  | PUBLISH        | Required                                        |
  | REQUEST        | PUBLISH                                          |
  | REPLY          | Required                                        |
  | ADD            | Required if recurrences supported, otherwise    |
  |                | reply with a REQUEST-STATUS "2.8;Success,        |
  |                | repeating event ignored.  Scheduled as a single  |
  |                | component." and schedule as a single component.  |
  | CANCEL        | Required                                        |
  | REFRESH        | Required                                        |
  | COUNTER        | Reply with "Not Supported"                      |
  | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs,  |
  |                | otherwise reply with "Not Supported"            |
  +----------------+--------------------------------------------------+

This table is not very clear which requirements apply to Organizer and
which requirements apply to Attendees.
(Similar comment about other tables)

[Ballot discuss]
Updated as per -10:

This is an important document and I don't want to be blocking it for any significant period of time. However I have a list of relatively minor issues that needs to be addressed, or at least discussed:

The document doesn't specify the IANA registration policy for "REQUEST-STATUS" values.

[Ballot comment]
3.2.2.3.  Delegating an Event to another CU

  In response to the request, the "Delegate" MUST send a "REPLY" method
  to the "Organizer" and optionally, to the "Delegator".  The "REPLY"
  method SHOULD include the "ATTENDEE" property with the "DELEGATED-
  FROM" parameter value

The SHOULD sounds a bit too weak here.

  of the "Delegator's" calendar address.

5.1.1.  Event-Related Fallbacks

  +----------------+--------------------------------------------------+
  | Method        | Fallback                                        |
  +----------------+--------------------------------------------------+
  | PUBLISH        | Required                                        |
  | REQUEST        | PUBLISH                                          |
  | REPLY          | Required                                        |
  | ADD            | Required if recurrences supported, otherwise    |
  |                | reply with a REQUEST-STATUS "2.8;Success,        |
  |                | repeating event ignored.  Scheduled as a single  |
  |                | component." and schedule as a single component.  |
  | CANCEL        | Required                                        |
  | REFRESH        | Required                                        |
  | COUNTER        | Reply with "Not Supported"                      |
  | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs,  |
  |                | otherwise reply with "Not Supported"            |
  +----------------+--------------------------------------------------+

This table is not very clear which requirements apply to Organizer and
which requirements apply to Attendees.
(Similar comment about other tables)

[Ballot discuss]
This is an important document and I don't want to be blocking it for any significant period of time. However I have a list of relatively minor issues that needs to be addressed, or at least discussed:

The document doesn't specify the IANA registration policy for "REQUEST-STATUS" values.

[Ballot discuss]
This discuss is basically a placeholder for the ongoing discussions between the authors
and the secdir reviewer.

Of the remaining issues in that discussion, I see the lack if detail regarding use of TLS
to secure the protocol as discuss-level and blocking.

[Ballot comment]
I don't think the reference to [I-D.ietf-calsify-rfc2447bis] is Normative.

In Section 1.4:

  | COUNTER        | The Counter method is used by an "Attendee" to  |
  |                | negotiate a change in an iCalendar objecy.      |

typo: object


3.2.2.3.  Delegating an Event to another CU

  In response to the request, the "Delegate" MUST send a "REPLY" method
  to the "Organizer" and optionally, to the "Delegator".  The "REPLY"
  method SHOULD include the "ATTENDEE" property with the "DELEGATED-
  FROM" parameter value

The SHOULD sounds a bit too weak here.

  of the "Delegator's" calendar address.


3.2.5.  CANCEL

  The "Organizer" is MUST send a "CANCEL" message to each "Attendee"

s/is//

3.3.3.  REPLY

  |  REQUEST-STATUS  | 0+      |                                  |

Not 1+?


3.7.2.  Attendee Property Considerations

  There are valid [RFC5322] addresses that represent groups.

Do you mean email addresses that represent groups, or Group syntax in To:
header field?

I think the reference to RFC 5321 is more suitable here. In particular
it doesn't allow RFC 5322 comments and you probably don't want to imply that they might be allowed here.

5.1.1.  Event-Related Fallbacks

  +----------------+--------------------------------------------------+
  | Method        | Fallback                                        |
  +----------------+--------------------------------------------------+
  | PUBLISH        | Required                                        |
  | REQUEST        | PUBLISH                                          |
  | REPLY          | Required                                        |
  | ADD            | Required if recurrences supported, otherwise    |
  |                | reply with a REQUEST-STATUS "2.8;Success,        |
  |                | repeating event ignored.  Scheduled as a single  |
  |                | component." and schedule as a single component.  |
  | CANCEL        | Required                                        |
  | REFRESH        | Required                                        |
  | COUNTER        | Reply with "Not Supported"                      |
  | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs,  |
  |                | otherwise reply with "Not Supported"            |
  +----------------+--------------------------------------------------+

This table is not very clear which requirements apply to Organizer and
which requirements apply to Attendees.
(Similar comment about other tables)

5.1.1.  Event-Related Fallbacks

  +-----------------+-------------------------------------------------+
  | Component      | Fallback                                        |
  | Property        |                                                |
  +-----------------+-------------------------------------------------+
[...]
  | DURATION        | Reply with "Not Supported"                      |

I am surprised to find that support for DURATION is optional.
(The same comment for VTODO)
Is this stated somewhere in rfc2445bis?

  | DTSTAMP        | Required                                        |
  | DTSTART        | Required                                        |
  | DTEND          | Required                                        |


5.1.2.  Free/Busy-Related Fallbacks

  +---------+---------------------------------------------------------+
  | Method  | Fallback                                                |
  +---------+---------------------------------------------------------+
  | PUBLISH | Implementations MAY ignore the METHOD type.  The        |

I am confused by "MAY ignore the METHOD type". I think a good implementation needs to check it.

  |        | REQUEST-STATUS "3.14;Unsupported capability" MUST be    |
  |        | returned.                                              |
  | REQUEST | Implementations MAY ignore the METHOD type.  The        |
  |        | REQUEST-STATUS "3.14;Unsupported capability" MUST be    |
  |        | returned.                                              |
  | REPLY  | Implementations MAY ignore the METHOD type.  The        |
  |        | REQUEST-STATUS "3.14;Unsupported capability" MUST be    |
  |        | returned.                                              |
  +---------+---------------------------------------------------------+



6.2.1.  Use of [RFC1847] to secure iTIP transactions

  [...]

  Implementations MAY provide controls for users to disable this

What is "this" referring to here? Use of S/MIME in general, or use
for a particular purpose?

  capability.


7.  IANA Consideration

  This documents defines the following values for the iCalendar
  "METHOD" property and these should be added to the Methods Registry
  defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]:

Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis] doesn't define which template needs to be used for registrations. It took me a couple of minutes to figure out that the registration template from Section 8.2.6 of [I-D.ietf-calsify-rfc2445bis] needs to be used.

[Ballot discuss]
This is an important document and I don't want to be blocking it for any significant period of time. However I have a list of relatively minor issues that needs to be addressed, or at least discussed:

1). I am holding a DISCUSS on behalf of IANA:

--On September 14, 2009 7:22:20 PM +0000 Amanda Baber via RT  wrote:

    IANA has reviewed draft-ietf-calsify-2446bis-09.txt, which is
    currently in Last Call, and has the following questions/comments:

    - In section 3.6 you define a set of Status Replies but those values
    are not put into a registry. Do you want a registry of status values?

Cyrus: After discussion with a few people the general feeling is that we should have a status code registry. Whilst it would have been best to have that in the 2445bis document (about to be published now) it can reasonably go in this document. I propose that I generate a new -10 version of the draft with the new registry defined.

2).
A.2.  Deprecated features

  The "THISANDFUTURE" option for the "RANGE" parameter was removed in
  [I-D.ietf-calsify-rfc2445bis] and references to that have been
  removed in this document too.

I can still find several references to THISANDFUTURE in the document.
I think this paragraph just needs to be deleted.

[Ballot comment]
I don't think the reference to [I-D.ietf-calsify-rfc2447bis] is Normative.

In Section 1.4:

  | COUNTER        | The Counter method is used by an "Attendee" to  |
  |                | negotiate a change in an iCalendar objecy.      |

typo: object


3.2.2.3.  Delegating an Event to another CU

  In response to the request, the "Delegate" MUST send a "REPLY" method
  to the "Organizer" and optionally, to the "Delegator".  The "REPLY"
  method SHOULD include the "ATTENDEE" property with the "DELEGATED-
  FROM" parameter value

The SHOULD sounds a bit too weak here.

  of the "Delegator's" calendar address.


3.2.5.  CANCEL

  The "Organizer" is MUST send a "CANCEL" message to each "Attendee"

s/is//

3.3.3.  REPLY

  |  REQUEST-STATUS  | 0+      |                                  |

Not 1+?


3.7.2.  Attendee Property Considerations

  There are valid [RFC5322] addresses that represent groups.

Do you mean email addresses that represent groups, or Group syntax in To:
header field?

I think the reference to RFC 5321 is more suitable here. In particular
it doesn't allow RFC 5322 comments and you probably don't want to imply that they might be allowed here.

5.1.1.  Event-Related Fallbacks

  +----------------+--------------------------------------------------+
  | Method        | Fallback                                        |
  +----------------+--------------------------------------------------+
  | PUBLISH        | Required                                        |
  | REQUEST        | PUBLISH                                          |
  | REPLY          | Required                                        |
  | ADD            | Required if recurrences supported, otherwise    |
  |                | reply with a REQUEST-STATUS "2.8;Success,        |
  |                | repeating event ignored.  Scheduled as a single  |
  |                | component." and schedule as a single component.  |
  | CANCEL        | Required                                        |
  | REFRESH        | Required                                        |
  | COUNTER        | Reply with "Not Supported"                      |
  | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs,  |
  |                | otherwise reply with "Not Supported"            |
  +----------------+--------------------------------------------------+

This table is not very clear which requirements apply to Organizer and
which requirements apply to Attendees.
(Similar comment about other tables)

5.1.1.  Event-Related Fallbacks

  +-----------------+-------------------------------------------------+
  | Component      | Fallback                                        |
  | Property        |                                                |
  +-----------------+-------------------------------------------------+
[...]
  | DURATION        | Reply with "Not Supported"                      |

I am surprised to find that support for DURATION is optional.
(The same comment for VTODO)
Is this stated somewhere in rfc2445bis?

  | DTSTAMP        | Required                                        |
  | DTSTART        | Required                                        |
  | DTEND          | Required                                        |


5.1.2.  Free/Busy-Related Fallbacks

  +---------+---------------------------------------------------------+
  | Method  | Fallback                                                |
  +---------+---------------------------------------------------------+
  | PUBLISH | Implementations MAY ignore the METHOD type.  The        |

I am confused by "MAY ignore the METHOD type". I think a good implementation needs to check it.

  |        | REQUEST-STATUS "3.14;Unsupported capability" MUST be    |
  |        | returned.                                              |
  | REQUEST | Implementations MAY ignore the METHOD type.  The        |
  |        | REQUEST-STATUS "3.14;Unsupported capability" MUST be    |
  |        | returned.                                              |
  | REPLY  | Implementations MAY ignore the METHOD type.  The        |
  |        | REQUEST-STATUS "3.14;Unsupported capability" MUST be    |
  |        | returned.                                              |
  +---------+---------------------------------------------------------+



6.2.1.  Use of [RFC1847] to secure iTIP transactions

  [...]

  Implementations MAY provide controls for users to disable this

What is "this" referring to here? Use of S/MIME in general, or use
for a particular purpose?

  capability.


7.  IANA Consideration

  This documents defines the following values for the iCalendar
  "METHOD" property and these should be added to the Methods Registry
  defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]:

Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis] doesn't define which template needs to be used for registrations. It took me a couple of minutes to figure out that the registration template from Section 8.2.6 of [I-D.ietf-calsify-rfc2445bis] needs to be used.

[Ballot discuss]
This is an important document and I don't want to be blocking it. However I have a list of relatively minor issues that needs to be addressed, or at least discussed:

1). I am holding a DISCUSS on behalf of IANA:

--On September 14, 2009 7:22:20 PM +0000 Amanda Baber via RT  wrote:

    IANA has reviewed draft-ietf-calsify-2446bis-09.txt, which is
    currently in Last Call, and has the following questions/comments:

    - In section 3.6 you define a set of Status Replies but those values
    are not put into a registry. Do you want a registry of status values?

Cyrus: After discussion with a few people the general feeling is that we should have a status code registry. Whilst it would have been best to have that in the 2445bis document (about to be published now) it can reasonably go in this document. I propose that I generate a new -10 version of the draft with the new registry defined.

2).
A.2.  Deprecated features

  The "THISANDFUTURE" option for the "RANGE" parameter was removed in
  [I-D.ietf-calsify-rfc2445bis] and references to that have been
  removed in this document too.

I can still find several references to THISANDFUTURE in the document.
I think this paragraph just needs to be deleted.

[Ballot comment]
The OPS-DIR review by Menachem Dodge brought up the following issues and nits:

1. This document obsoletes RFC 2446. The modifications are listed in Appendix A – "Differences from RFC 2446". It would be useful to have text that discusses any possible interworking issues that may occur between implementations of this document and implementations of RFC 2446.

2. It would be helpful to have an abbreviations section to refer to as needed, or to exapnd acronyms at first occurence.

Example:

CS  -  Calendar Service
CU -    Calendar User

3.      A few minor corrections:

a.      Page 9: Section 1.4 Methods

Within the table for the method COUNTER.

"objecy"

OLD ->  COUNTER        |  The Counter method is used by an "Attendee" to  negotiate a change in an iCalendar objecy.

SUGGESTED -> COUNTER |  The Counter method is used by an "Attendee" to  negotiate a change in an iCalendar object.

b.      Page 53

OLD -> The "Organizer" is MUST send a "CANCEL"

SUGGESTED -> The "Organizer" MUST send a "CANCEL

[Ballot comment]
I don't think the reference to [I-D.ietf-calsify-rfc2447bis] is Normative.

In Section 1.4:

  | COUNTER        | The Counter method is used by an "Attendee" to  |
  |                | negotiate a change in an iCalendar objecy.      |

typo: object

[Ballot discuss]
This is a preliminary DISCUSS, I might have more issues before the telechat:

1). I am holding a DISCUSS on behalf of IANA:

--On September 14, 2009 7:22:20 PM +0000 Amanda Baber via RT  wrote:

    IANA has reviewed draft-ietf-calsify-2446bis-09.txt, which is
    currently in Last Call, and has the following questions/comments:

    - In section 3.6 you define a set of Status Replies but those values
    are not put into a registry. Do you want a registry of status values?

Cyrus: After discussion with a few people the general feeling is that we should have a status code registry. Whilst it would have been best to have that in the 2445bis document (about to be published now) it can reasonably go in this document. I propose that I generate a new -10 version of the draft with the new registry defined.

2).
A.2.  Deprecated features

  The "THISANDFUTURE" option for the "RANGE" parameter was removed in
  [I-D.ietf-calsify-rfc2445bis] and references to that have been
  removed in this document too.

I can still find several references to THISANDFUTURE in the document.

[Ballot comment]
Section 5.2.1 recommends holding onto CANCEL messages that can't be correlated to a REQUEST when they arrive (because of reordering on store-and-forward transports perhaps). The security considerations section should discuss when to stop doing this (bad-guys can make up a lot of CANCELs). Something similar to the flood mitigation discussed in 6.2.2 paragraph 2 would work.

The first paragraph of 6.2.2 recommends that CUs be given the choice to honor an Organizer change. I think it would be useful guidance to implementers to point out here that if individual CUs in that set make different choices, future changes by _either_ of the resulting Organizers will not be accepted by all of the CUs. The protocol will not malfunction (as far as I can tell), but the original set of CUs may end up attending two different meetings. (Implementers could, in turn, provide guidance to users making that choice or to let Organizers know that their attempt to make a change was not wholly accepted).

[Ballot comment]
The Gen-ART Review by Vijay K. Gurbani posted on 16-Sep-2009 points
  out two nits:

  1) S6.1.4 is about eavesdropping and not data integrity, right?
  But the misuse suffered by a cleartext iCalendar object is given
  both treatments: lack of privacy and loss of data integrity.  A
  simple suggestion would be to remove "and/or changed" from S6.1.4,
  and have a new paragraph as follows:

    Data Integrity

    The iCalendar object is constructed with human-readable
    clear text.  Any information contained in an iCalendar object
    may be changed by unauthorized persons while the object is
    in transit.

  2) Acknowledgments: s/S.Silverberg/S. Silverberg/

[Ballot comment]
Looks like you cleared up the issue raised in Erratum 1709.
(http://www.rfc-editor.org/errata_search.php?eid=1709)
You might ask your AD to close the Erratum record.

IANA comments:

- In section 3.6 you define a set of Status Replies but those values
are not put into a registry. Do you want a registry of status values?


Upon approval of this document, IANA will make the following
assignments in the "Methods" registry at
http://www.iana.org/assignments/icalendar/icalendar.xhtml

Method Status Reference
------- ------- ---------
PUBLISH Current [RFC-calsify-2446bis-09]
REQUEST Current [RFC-calsify-2446bis-09]
REPLY Current [RFC-calsify-2446bis-09]
ADD Current [RFC-calsify-2446bis-09]
CANCEL Current [RFC-calsify-2446bis-09]
REFRESH Current [RFC-calsify-2446bis-09]
COUNTER Current [RFC-calsify-2446bis-09]
DECLINECOUNTER Current [RFC-calsify-2446bis-09]

We understand the above to be the only IANA Action for this document.

PROTO WRITEUP
(1.a) Who is the Document Shepherd for this document?

Eliot Lear
        Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Yes, and Yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?

Yes.

        Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 


No.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) 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? 

Strong concurrence from a few individuals, but general consensus as a
whole from others.


  (1.f) 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
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.


  (1.h) Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

draft-ietf-calsify-rfc2445bis is in AUTH48, although we need to resolve
IPR issue.  We expect that to happen this week.


        If such normative references exist, what is the
        strategy for their completion?

Meeting occuring between interested parties this Friday.

        Are there normative references
        that are downward references, as described in [RFC3967]?

no.

        If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

Yes.

        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?

Yes.

        Are the IANA registries clearly identified?

Yes.

        If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation.

n/a


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

n/a.

  (1.k) 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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

This memo updates RFC 2446, iTIP.  While no new protocol elements
are introduced, a number are deprecated, while others are clarified.
The examples are also improved.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

There is rough consensus to move the document forward, and it wasn't
all that rough.  We had one minor issue relating to a constraint table,
as to readability, but that is editorial preference.


    Document Quality
        Are there existing implementations of the protocol?


Yes.
        Have a
        significant number of vendors indicated their plan to
        implement the specification?


Yes.

        Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues?

We gratefully acknowledge Nigel Swinson for his review of afformentioned
table.

        If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

n/a.

IANA comments:

[Note: These actions depend on draft-ietf-calsify-rfc2445bis-09.txt]

IANA has questions:

- In Section 1.4 the method is "DECLINECOUNTER" but in the IANA
Considerations Section the method is "DECLINE-COUNTER." Which is
correct?

- In section 3.6 you define a set of Status Replies but those values
are not put into a registry. Do you want a registry of status values?

Upon approval of this document, the IANA will make the following
assignments in the "Methods" registry located at
http://www.iana.org/assignments/TBD

Method Status Reference
------- -------- -------------
PUBLISH Current [RFC-calsify-2446bis-08]
REQUEST Current [RFC-calsify-2446bis-08]
REPLY Current [RFC-calsify-2446bis-08]
ADD Current [RFC-calsify-2446bis-08]
CANCEL Current [RFC-calsify-2446bis-08]
REFRESH Current [RFC-calsify-2446bis-08]
COUNTER Current [RFC-calsify-2446bis-08]
DECLINE-COUNTER Current [RFC-calsify-2446bis-08]

We understand the above to be the only IANA Action for this document.

Sorry I pushed this to Last Call too soon.  This needs to go to Last Call for real when a number of known issues are resolved.