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

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

On 23 Aug 2007, at 15:34, Alexander Mayrhofer wrote:
> The IESG wrote:
>> 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
>
> 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
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum