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 PROTECTED]>
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 protected]
https://www.ietf.org/mailman/listinfo/gen-art
