Internet Calendaring and Scheduling Core Object Specification (iCalendar)
draft-ietf-calsify-rfc2445bis-10
Discuss
Yes
(Alexey Melnikov)
(Lisa Dusseault)
No Objection
(Cullen Jennings)
(David Ward)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 10 and is now closed.
Chris Newman Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2008-12-18)
Unknown
While this is a significant improvement over the original specification, I believe it still has many areas where it is unclear how to implement certain things, areas where the specification is inconsistent, areas where I'm there are interoperability issues and areas where it is unclear what features are mandatory-to-implement in order to have a compliant implementation of this specification. I believe this needs a revision focused on improvements in these areas. I'll include my review in the "IESG comments" field as it contains many non-discuss level issues that I feel may still be worth improvement.
Alexey Melnikov Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2008-12-17)
Unknown
I support Magnus's DISCUSS based on Lars's comment about the reference to RFC1738.
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2008-12-16)
Unknown
Section 3.2.6., paragraph 5: > Description: This parameter can be specified on properties with a > CAL-ADDRESS value type. The parameter specifies a reference to > the directory entry associated with the calendar user specified by > the property. The parameter value SHOULD be a CID [RFC2392], DATA > [RFC2397], FILE [RFC1738], FTP [RFC1738], HTTP [RFC2616], HTTPS > [RFC2818], LDAP [RFC4516], or MID [RFC2392] URI. The URI > parameter value MUST be specified in a quoted-string. What's the status of "file://" and "ftp://|? RFC1738 was obsoleted, and while "telnet://" and "gopher://" have been resurrected (RFC 4248, RFC 4266), I couldn't locate an RFC that did the same for these two. (Making this a comment, since I won't be on the call and I don't want to block.)
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2008-12-17)
Unknown
The ABNF is not formally correct: There are some multi-line rules containing empty lines, like calprops and many of the other <x>props rules. I understand that this is for readability however, it is against the ABNF rules. I guess most text editors and the XML to RFC tool are against you in that they will strip the white spaces on the empty lines. Maybe try to get the RFC-editor to ensure that there are white spaces on the empty lines within rules.
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2008-12-12)
Unknown
This minor error was caught in the Gen-ART Review by
Gonzalo Camarillo:
OLD:
This property SHOULD not be used to alter the interpretation of
NEW:
This property SHOULD NOT be used to alter the interpretation of
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown