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

[Rohan Mahy <[e-mail]>]

Hi Alex,

I think this change will make the document better, so I would like to  
include it.

I want to point out another area of potential confusion so we can  
have it out in the open sooner rather than later.  There are really  
three distinct operations that you can do with calendaring:  
manipulating one of your calendars, viewing someone else's free/busy  
status, and scheduling (proposing an event).  Whether we should have  
subtype for protocol, or a subtype for the "operation" you are trying  
to perform.

thanks,
-rohan

On Aug 23, 2007, at 7:34 AM, 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum