Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt

Paul,

One comment below.

Thanks,
Alan

Paul Kyzivat wrote:
> This seems to be shaping up well. I think the requirements are quite 
> clear now.
>
> I don't fully understand what is intended regarding combination of 
> multiple alert URNs for a specific situation. Section 4.5 states:
>
>>    finally, a short Albanian auto-callback tone could be indicated
>>    Alert-Info: <urn:alert:service:auto-callback>,
>>    <urn:alert:tone:short>, <urn:alert:tone:al>.
>
> while section 7.3.6 states:
>
>>    Alert URN Indications from the same group should not be combined.
>
> I could find no definition of what constitutes a "group". The first 
> thing that comes to mind is "service" vs. "tone", but the above 
> example violates that. It seems to me that you need some notion of 
> orthogonal properties in order to define what can/cannot be combined.
>
> It would be good to have more detail about how a recipient should deal 
> with multiple URNs.
>
> I'm also uncertain of what your intent is regarding top-level vs. 
> additional indications. As specified, I believe a given "additional 
> indication" name is always defined with regard to its parent, so that 
> "short" as used in "normal.short" might mean something entirely 
> different than "priority.short", or might not be defined for priority 
> at all.
>
> Yet from the registration text in 7.3.2 it sounds like the intent is 
> for priority, short, and delayed to be defined for all pbx-tones. If 
> that is the intent, then I don't think the existing text meets that 
> intent.

As it has been pointed out, short, long, and delayed are not compatible 
with the semantic approach of this draft so I think we should remove 
them as they are currently.  I need to investigate to see whether they 
have been used in the past as stand-ins for a particular service, or 
whether we need to define specific tones for them.

Priority, I still think, is useful - we just need to figure out how to 
fit it in properly.

>
> I also wonder if the existing hierarchy will work well in practice, or 
> if some other organization might not work better. For instance, it 
> might be more convenient to specify ringing.fr with the clear 
> understanding that if you don't know about ringing.fr you can just 
> treat it as ringing.
>
> I'm also confused by PBX tones vs. Public telephone tones. In what way 
> is "normal" different from "ringing"? I would think that PBX tones 
> would be a superset of common pstn tones.
>
> A nit: in 4.3.2 I would expext the forward to be indicated, if at all, 
> with a 181 rather than a 180.
>
>     Thanks,
>     Paul
>
> L.Liess@telekom.de wrote:
>>  
>> Hi,
>>
>> We've re-submitted the Alert-Info URNs draft for DISPATCH
>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns
>> -00.txt . (The previous version od the draft was in BLISS and we had a
>> presentation in BLISS at the last IETF.)
>>
>> We did some major changes, as suggested on the mailing list, e.g.:
>>  Added:    - Description of the interoperability problems for 
>> PBX-services (in
>> the Introduction chapter)   - Requirements for the Alert-Info URNs 
>> mechanism   - Alert-Info URNs Indications for country-specific tones
>>  Changed:   - Initial IANA Registration mechanism to avoid 
>> combinatorial explosion
>> of IANA values.
>>
>> Many thanks for the comments and suggestions,
>> Laura
>>
>>
>>    
>> -----Original Message-----
>> From: i-d-announce-bounces@ietf.org
>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>> Internet-Drafts@ietf.org
>> Sent: Monday, October 19, 2009 1:00 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>     Title           : Alert-Info URNs for the Session Initiation
>> Protocol (SIP)
>>     Author(s)       : D. Alexeitsev, et al.
>>     Filename        : draft-liess-dispatch-alert-info-urns-00.txt
>>     Pages           : 25
>>     Date            : 2009-10-19
>>
>> The Session Initiation Protocol (SIP) supports the capability to
>> provide a reference to the alternative ringback tone (RBT) for
>> caller, or ring tone (RT) for callee using the Alert-Info header.
>> However, the reference addresses only the network resources with
>> specific rendering properties.  There is currently no support for
>> predefined standard identifiers for ringback tones or semantic
>> indications without tied rendering.  To overcome this limitations and
>> support new applications a family of the URNs is defined in this
>> specification.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns
>> -00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>