xCal: The XML Format for iCalendar
RFC 6321

Note: This ballot was opened for revision 11 and is now closed.

(Peter Saint-Andre; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2011-05-25 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (2011-05-23 for -** No value found for 'p.get_dochistory.rev' **)
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."

(Ralph Droms; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2011-05-26 for -** No value found for 'p.get_dochistory.rev' **)
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? 

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info