IANA Registration of Enumservices for Internet Calendaring
draft-ietf-enum-calendar-service-04
Yes
(Jon Peterson)
(Lisa Dusseault)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Lars Eggert)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 04 and is now closed.
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Lisa Dusseault Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-01-10)
Unknown
Review by Christian Vogt: Draft-ietf-enum-calendar-service-03 registers ENUM mappings for use by calendaring applications. The document is clear and concise, and includes a thorough security analysis. It should hence be considered for publication. One small addition that I propose for the document's introduction is examples of the prospective use cases for the mapping specified by this document. Where would it be desired to address a calendaring application with a telephone number? One use case may be to enable users to control calendaring applications via SMS.
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-01-08)
Unknown
[This is more of a question than a comment, but it just doesn't rise to the level of a discuss discuss. Regardless of the answer, I see no value in blocking or slowing this document.] As specified, the ical service registration is overloaded, supporting both iCalendar/iMIP and CalDAV. Resources are differentiated according to the URI scheme. This makes sense as long as there is no prospect of supporting the mailto: scheme for CalDAV or http(s): scheme for iCalendar. If such work is being contemplated, overloading the registration seems like a bad idea. RFC 3283 specifically mentions http for iCalendar as "non-standard methods", the webdav wg has concluded, and I couldn't find a ID with email and CalDAV so perhaps this a reasonable strategy. Still, two separate registrations seemed like a more reasonable strategy to me. Is there something I am missing - some convergence of iCal and CalDAV in common implementations, for example - that makes this overloaded registration a good idea?