Skip to main content

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