xCal: The XML Format for iCalendar
draft-daboo-et-al-icalendar-in-xml-11
Yes
(Peter Saint-Andre)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 11 and is now closed.
Peter Saint-Andre Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-05-25)
Unknown
I have no objection to the publication of this document altough I raise a point below that seems to me to be a potntial issue. --- I'm not convinced that this document is completely future-proofed. I understand how future components, properties, and parameters will be converted into XML elements using a designated naming convention. But it seems to me that more complex entities (such as multi-valued properties) cannot be simply and automatically handled. Indeed, the need to present a schema in Appendix A (rather than simply define the rules for how it is automatically created) seems to imply that there is a little more work that will be needed when future extensions to iCalendar are made. In view of this, I think we need a section specifically discussing extensions to iCalendar. I think that the current Section 5 is a subset of this new section. --- Nit Section 1 "semantic meaning" One of the words is redundant.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2011-05-23)
Unknown
- You claim that round-tripping is a design goal. I'm wondering about the base64 and folding round-tripping. The document clearly takes into account cases of iCalendar objects that have unnecessary base64. Is it at all problematic that this will not round-trip according to the rules you set out? - Instead of "the table is a non-normative reference", how about "the table gives examples of ...". The words "non-normative reference" have a specific meaning in RFCs and there is no "referencing" going on here. If you really need to call out that these tables are not normative, say something in section 2 like "The examples given in the tables throughout this document, along with the schema in Appendix A and examples in Appendix B, are not authoritative, and if there is a conflict between these and the definitions given in sections 3 and 4, the definitions in section 3 and 4 are to be taken as authoritative."
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-05-26)
Unknown
(1) In 3.6.5 can the date-time element value include TZ offsets? I think it'd be worth being explicit about this and adding a 2nd example with an offset if that's allowed. (It looks from the later examples like this is allowed.) (2) In 3.6.8 is INTEGER can be negative, then it'd be worth adding a 2nd example with a negative number. (3) In 3.6.11, if UTF8 characters are allowed, then it'd be good to add an example like that, or if that's hard in an RFC, then just say so and if they're not allowed, then just say that to make a coder's life easier. (4) In 4.2 when it says "IANA, non-standard, inline encoding..." should there be a reference to make it easier for an implementer to figure out what this means?
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown