Subject: [Enum] Last Call: draft-ietf-enum-calendar-service (A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 23 Aug 2007 10:10:59 -0400

The IESG has received a request from the Telephone Number Mapping WG 
(enum) to consider the following document:

- 'A Telephone Number Mapping (ENUM) Service Registration for Internet 
   Calendaring Services '
   <draft-ietf-enum-calendar-service-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-09-06. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14544&rfc_flag=0

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 23 Aug 2007 16:34:04 +0200

>    <draft-ietf-enum-calendar-service-03.txt> as a Proposed Standard

Hi,

(yes, i know that it's _very very_ late for this, and i hate to receive
similar comments on my documents... but - better late than never?)

Two things (i start with the non-issue..)

- I seem to have overlooked that the shortcut title of the document still
says "IM Enumservice", even though this is the calendar Enumservice, seems
to be a leftover from copying the other template.

Now the harder issue: Subtypes.

- In the light of the discussions around Enumservice classification in
Chicago, i examined the type/subtype combinations, and i feel a bit unease
about not using any subtypes for this Enumservice, because this Enumservice
covers two completely different calendaring protocols (iMIP and CalDAV). I
consider being "ical" and "application class" Enumservice, according what we
added to the enumservices guide in the recent revision.

A bit more about the subtyping decision:

Keep in mind that a client is not allowed to "look" at the URI scheme for
choosing a ENUM records, so it can only guess whether the record would be
for an iMIP or an CalDAV address when there is no subtype given. Only the
type and subtype must be used to choose a NAPTR from a set of records - so a
client would not be able to find out whether a NAPTR refers to a "iMIP" or
"CalDAV" resource..

That might well lead to problems when a client finds out that the "ical"
record it has just chosen lists a iMIP address, while the client only
supports CalDAV. According to RFC3761, it can't "go back" anymore, and try
the other "ical" record, even if that would have contained a CalDAV URI. So
the client would fail to contact the calendaring resource, even though it
_would_ have been able to contact it in case it had chosen the other record
("russian ENUM roulette", anybody?)

- A second concern might be that there _could_ be calendaring protocols that
use http/https URIs as well, but don't represent CalDAV resources (who
knows?). A client would have no chance in finding out which "http-using"
calendaring protocol the NAPTR addresses without contacting the actual
calendar service.

I'd suggest to change (yes, i know, 5 mins after 12) that Enumservice
registration to two distinct registrations, both with a subtype, like:

a) Name: "iCal"
   Type: "ical"
   Subtype: "caldav"
   URI schemes: "http", "https"

b) Name: "iCal"
   Type: "ical"
   Subtype: "imip"
   URI schemes: "mailto"

That would clarify to the client which calendaring protocol is in use, would
allow other potential calendaring protocols to use http/https as well, and
generally give me a better feeling about that Enumservice than the current
document does...

Comments?

(and, again, sorry for being late!)

---
Alex Mayrhofer
enum.at

---

From: lconroy <[email-masked]>
Date: Thu, 23 Aug 2007 18:06:03 +0100

Hi Alex, folks,
   I wholeheartedly agree.
This change helps, and avoids a potential problem.
The reason for this change is well explained.
Knowing in advance whether or not there was a bullet in the chamber
would be good :). iMIP Yes, CalDAV No.

---
One related point -
Q:  Should this rationale (with or without the wonderful "russian
     ENUM roulette, anybody?" comment) be added to the existing text
     for the Enumservice framework document?

IMHO, it is A Good Idea to highlight that RFC3761 doesn't let a client
readily go back and re-evaluate the remaining RRSet. I think it would
help people trying to fathom out which option fits their requirements,
as it is not always obvious WHY a specific sub-type is used rather than
letting the client sort it out through negotiation within the protocol.
On brief re-scan, the framework doesn't quite say that yet. Maybe this
could be added to the subset sub-section (3.2.3 bullet 2) of the frame-
work draft?

all the best,
   Lawrence