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

["Elwell, John" <[e-mail]>]

(I have removed the BLISS cross-post, by the way).

I agree with the points Paul makes. In addition, I am concerned about some of the values:

1. In 4.3.8, the value "short" is defined. This seems to have nothing to do with the meaning of a tone, but the way it is rendered. So in one locale, a short form of ring tone might denote low priority, say, whereas in another locale it might mean urgent, yet in a third locale it might mean some form of recall. Also, if my device renders tones visually, does displaying the alert icon or message only for a short period make sense? Finally, what does "short" mean to an automaton?

2. Given that Alert-Info is defined only for use in an INVITE request or a 180 response, how would values such as "busy", "intrusion" and "record" be used?

John

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Paul Kyzivat
> Sent: 19 October 2009 21:44
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [BLISS] [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
> 
> [e-mail] 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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of
> > [e-mail]
> > Sent: Monday, October 19, 2009 1:00 PM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> > 
> _______________________________________________
> BLISS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bliss
>