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

[<[e-mail]>]

Hi John,

Thank you very much for reading the draft and for the comments. 

Please  see answers inline:

	> -----Original Message-----
	> From: Elwell, John [mailto:[e-mail]]

	> Sent: Tuesday, October 20, 2009 9:41 AM
	> To: Paul Kyzivat; Liess, Laura
	> Cc: [e-mail]; Jesske, Roland; [e-mail]
	> Subject: RE: [BLISS] [dispatch] New version for the 
	> Alert-Info URNs
draft:draft-liess-dispatch-alert-info-urns-00.txt
	> 
	> (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?

I am not very familiar with PBXs, this is Alan's part, but my
understanding is that the PBX tones URNs are inserted by the local PBX
system (Proxy, Application server, maybe a UA directly connected to the
PBX) and rendered  by one UE of the same enterprise, so that, in
generally, there is a common understanding about the meaning of "short".
Maybe we could add a description about how itshould be used? 


> 
> 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?

This is true. I just did not think about it when I wrote this part. We
should define only country ringing tones. 

Thanks a lot
Laura


> 
> 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
> > 
>