Subject: [Gen-art] Gen-ART review of draft-ietf-calsify-2446bis-08.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 11 Nov 2008 14:53:41 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-calsify-2446bis-08.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2008-11-11
IETF LC End Date: 08-11-18
IESG Telechat date:

Summary: The document is ready for publication as a standards track RFC.

Comments: The document is clear and well written. I have some comments 
that you may want to take onboard to improve readability and be a bit 
more accurate.

- I like the numerous tables included in the draft. But I wish they would 
  all have a table number (perhaps a caption too), so that it would be 
much precise to refer to, e..g, "Table 5" rather than "the table below". 
It also makes very easy for other drafts (and future RFCs) to refer to 
"Table n in RFC xxx" rather than "the second table in Section yyy of RFC 
xxx".

- Section 2.1.4: the text reads:

    The "Organizer"
    CUA MUST increment the sequence number whenever it makes changes to
    properties in the calendar component that the "Organizer" deems will
    jeopardize the validity of the participation status of the
    "Attendees".

I don't understand the "MUST" strength in connection to a fluffy sentence 
that is subject to interpretation. I would understand that the Organizer 
MUST unconditionally do an action, or he MUST conditionally do it, 
whenever the condition is measurable. But this is not the case here, 
where the condition "will jeopardize the validity of the participation 
status of Attendees" is totally up to interpretation of the Organizer and 
therefore, not measurable.

Furthermore. It is not possible to test compliance of the MUST strength 
in a test sequence.

- Section 3.2.2. Bad syntax in the sentence:

    For the "REQUEST" method, multiple "VEVENT" components in a single
    iCalendar object are only permitted when for components with the same
    "UID" property.

Most likely you need to delete the word "when".

- Section 3.2.3: In the first paragraph, there are a couple of "SHOULD" 
for which I couldn't easily justify an exception for not using a "MUST" 
strength. I suspect these should be "MUSTs", or the exceptional condition 
should be hinted. This is the text:

    The "REPLY" method in a "VEVENT" calendar component is used to
    respond (e.g., accept or decline) to a "REQUEST" or to reply to a
    delegation "REQUEST".  When used to provide a delegation response,
    the "Delegator" SHOULD include the calendar address of the "Delegate"
    on the "DELEGATED-TO" property parameter of the "Delegator's"
    "ATTENDEE" property.  The "Delegate" SHOULD include the calendar
    address of the "Delegator" on the "DELEGATED-FROM" property parameter
    of the "Delegate's" "ATTENDEE" property.

- I noticed that the examples Section 4 contains quite a lot of normative 
text. I think an example section is not the best place to write normative 
text, and this text should be written elsewhere in the normative part. 
Take as an example Section 4.2.5 on page 79, where there are three 
instances of "MUST". Of Section 4.2.8, where there are instances of 
"SHOULD NOT" and "MAY".

- RFC 2822 has been obsoleted by RFC 5322.

- If you make a new revision of the document, notice that there are new 
boilerplate rules in force, so you will need to change the boilerplate.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art