xCal: The XML Format for iCalendar
Note: This ballot was opened for revision 11 and is now closed.
(Peter Saint-Andre) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Comment (2011-05-25 for -)
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.
(Stephen Farrell) No Objection
Comment (2011-05-26 for -)
(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?
(Russ Housley) (was Discuss) No Objection
(Pete Resnick) No Objection
Comment (2011-05-23 for -)
- 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."