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

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.

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
> 