xCal: The XML Format for iCalendar
RFC 6321

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 -)
No email
send info
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 -)
No email
send info
(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 -)
No email
send info
- 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."

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection