Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns

[<[e-mail]>]

Paul,

I agree with you. We should try to define only URNs that define a semantic and are valid in the Internet. I think the subindications defined in the draft, maybe excepting "short", define a semantic.    

 The mapping between semantic and rendering is can be different in different domains. Maybe URNs that define rendering e.g. Short-Short-Long should be defined for particular domains and registered with the domain owner? 
 
Laura

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: Monday, August 03, 2009 7:44 PM
> To: Liess, Laura
> Cc: [e-mail]; [e-mail]
> Subject: Re: [BLISS] Initial 
> ringtonesfordraft-alexeitsev-bliss-alert-info-urns
> 
> When I first started talking about using URNs for this (some 
> years ago),
> I expected that there might be URNs that were defined by their 
> semantics, without regard to how rendered, and others that were 
> associated with a particular rendering - to some degree of fidelity.
> 
> In general I would prefer to see the representation at least 
> start out 
> using a URN that defines a semantic. It could then perhaps be 
> translated 
> into one more related to form in cases where there is 
> compelling reason 
> to do so. Ideally that translation would be as late as possible.
> 
> This becomes especially important as we get devices with more diverse 
> rendering capabilities than was the case in the early days of 
> telephony.
> 
> The obvious use case is the widespread use of custom ring 
> tones. These 
> are typically selected near or at the callee, not by the caller. How 
> should the use of custom ring tones by the callee be rationalized 
> against an Alert-Info URN supplied by the caller? Ideally, if the 
> Alert-Info includes the URN for the "normal ring tone", then 
> the callee 
> should feel comfortable in using its configured choice for ring tone.
> If the incoming Alert-Info contains something else, it will take more 
> policy to decide what to render.
> 
> Customized alerts get especially important if the UAS is for a deaf 
> person. Then vibrators or lights are more likely to be used. 
> Similarly, 
> custom rendering of ringbacks are also important in such cases. 
> Understanding the semantics is especially important is such cases, 
> because a definition that is directly in terms of the audio rendering 
> isn't useful if you aren't rendering it using audio.
> 
> Semantic alerts are also helpful when the device has a video display, 
> since then it gets easier to display something meaningful.
> 
> 	Thanks,
> 	Paul
> 
> [e-mail] wrote:
> > John,
> > 
> > I agree with you.  Maybe we should add some new text with 
> recommendations about how new alert-identifiers should/ 
> should not be defined.  E.g. we could insert following text 
> at the end of chapter 7.1: "When defining new 
> alert-identifiers, names that reflect the meaning, rather 
> than the representation of a tone should be used. "  What do 
> you think? 
> > 
> > Laura
> > 
> >> -----Original Message-----
> >> From: Elwell, John [mailto:[e-mail]] 
> >> Sent: Thursday, July 30, 2009 3:49 PM
> >> To: Liess, Laura; [e-mail]; [e-mail]; 
> [e-mail]
> >> Subject: RE: [BLISS] Initial 
> >> ringtonesfordraft-alexeitsev-bliss-alert-info-urns
> >>
> >> We should at least try to avoid having two or more URNs with 
> >> the same semantics, coming from different countries. 
> >> Furthermore, we should try to register names that reflect the 
> >> meaning, rather than the representation, of a tone, so that 
> >> it can be rendered in the appropriate way for the locale 
> >> concerned. For example "internal.short-short-short" tells me 
> >> nothing about the meaning (other than that it is internal). 
> >> If it is intended to denote three short bursts of tone, this 
> >> could convey different meanings (or confusion) to a user 
> >> outside the locale where it originated.
> >>
> >> John
> >>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]] 
> >>> On Behalf Of [e-mail]
> >>> Sent: 30 July 2009 10:26
> >>> To: [e-mail]; [e-mail]; [e-mail]
> >>> Subject: Re: [BLISS] Initial 
> >>> ringtonesfordraft-alexeitsev-bliss-alert-info-urns
> >>>
> >>>
> >>> Francois,
> >>>
> >>> They would have to use the alredy registered alert urn 
> >>> template and to register new alert-URN indications for "tone" 
> >>> or "service" , e.g. internal.short-short-short. It's a 
> >>> similar process as for the Emergency Service URN (5031). 
> >>>
> >>> My personal opinion is that many of the tones defined in 
> >>> national documents will be not longer used when PSTN 
> moves to VoIP. 
> >>>
> >>> Regards
> >>> Laura
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Francois Audet [mailto:[e-mail]] 
> >>>> Sent: Wednesday, July 29, 2009 1:50 PM
> >>>> To: Liess, Laura; [e-mail]; [e-mail]
> >>>> Subject: RE: [BLISS] Initial ringtones 
> >>>> fordraft-alexeitsev-bliss-alert-info-urns
> >>>>
> >>>> It seems to me that if a specific national body requires the use
> >>>> of national-specific ringback tones, they would then have 
> >>> to register
> >>>> their own URN space for it.
> >>>>
> >>>> Hopefully we wouldn't go that route, but the option is 
> >> definitively
> >>>> there if required. 
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail] [mailto:[e-mail]] 
> >>>>> On Behalf Of [e-mail]
> >>>>> Sent: Tuesday, July 28, 2009 08:59
> >>>>> To: [e-mail]; [e-mail]
> >>>>> Subject: Re: [BLISS] Initial ringtones 
> >>>>> fordraft-alexeitsev-bliss-alert-info-urns
> >>>>>
> >>>>> Adam,
> >>>>>
> >>>>> The intent of the draft is to provide a general mechanism, to 
> >>>>> register the template and to do initial registration for 
> >>>>> tones and service tones which we know that people intend to 
> >>>>> use now and have interoperability problems. I don't think we 
> >>>>> should now register every tone in every national 
> >>>>> specification, which possible nobbody intends to use.  
> >>>>> If, over time, people need additional tones or service tones, 
> >>>>> they can use the general mechanism and template are free to 
> >>>>> register their own tones.  
> >>>>>
> >>>>> Or do you see a problem with this approach?
> >>>>>
> >>>>> Thanks a lot
> >>>>> Laura
> >>>>>
> >>>>>
> >>>>> Mit freundlichen Grüßen
> >>>>> Laura Liess
> >>>>>
> >>>>> Deutsche Telekom Netzproduktion GmbH
> >>>>> Zentrum Technik Einführung
> >>>>> Laura Liess
> >>>>> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt 
> >>>>> [phone] (Tel.)
> >>>>> [phone] (Fax)
> >>>>> [phone] (Mobil)
> >>>>> [e-mail] (E-mail)
> >>>>> http://www.telekom.com 
> >>>>>
> >>>>> Deutsche Telekom Netzproduktion GmbH
> >>>>> Aufsichtsrat: Timotheus Höttges (Vorsitzender)
> >>>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), 
> >>>>> Albert Matheis, Klaus Peren
> >>>>> Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der 
> >>>>> Gesellschaft: Bonn
> >>>>> USt-IdNr.: DE 814645262
> >>>>>
> >>>>>  
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail] 
> >>>>> [mailto:[e-mail]] On Behalf 
> >>>>>> Of Adam Roach
> >>>>>> Sent: Tuesday, July 28, 2009 2:30 PM
> >>>>>> To: [e-mail]
> >>>>>> Subject: [BLISS] Initial ringtones for 
> >>>>>> draft-alexeitsev-bliss-alert-info-urns
> >>>>>>
> >>>>>> There are a number of additional tones that are 
> >> probably worth 
> >>>>>> considering as part of the initial set of symbols. If 
> >>> you look at 
> >>>>>> TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone 
> >>>>>> designations that are used in other standards.
> >>>>>>
> >>>>>> A.S0014 defines:
> >>>>>>
> >>>>>>    1. Normal Alerting
> >>>>>>    2. Inter-group Alerting
> >>>>>>    3. Special/Priority Alerting
> >>>>>>    4. Ping Ring (abbreviated alert)
> >>>>>>    5. Abbreviated intercept
> >>>>>>    6. Abbreviated reorder
> >>>>>>
> >>>>>> I think #1 and #4 are covered in the current document, but 
> >>>>> the others 
> >>>>>> aren't clearly represented.
> >>>>>>
> >>>>>> If you throw in the TIA/EIA values, you also have things like:
> >>>>>>
> >>>>>>    1. Long (Normal)
> >>>>>>    2. Short-Short
> >>>>>>    3. Short-Short-Long
> >>>>>>    4. Short-Short2
> >>>>>>    5. Short-Long-Short
> >>>>>>    6. Short-Short-Short-Short
> >>>>>>    7. PBX Long (Normal)
> >>>>>>    8. PBX Short-Short
> >>>>>>    9. PBX Short-Short-Long
> >>>>>>   10. PBX Short-Long-Short
> >>>>>>   11. PBX Short-Short-Short-Short
> >>>>>>
> >>>>>>
> >>>>>> Additionally, A.S0014 allows indication of pitch (high, 
> >>>>> normal, low) 
> >>>>>> as part of the ringtone designation. It would be nice if we 
> >>>>> could tack 
> >>>>>> this pitch data on to the end of the existing tokens (e.g., 
> >>>>>> "normal.short.low"). I note that this points to a 
> >> combinatorial 
> >>>>>> explosion of IANA values -- perhaps we need to re-think 
> >>> how we're 
> >>>>>> representing the registry.
> >>>>>>
> >>>>>> /a
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> BLISS mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/bliss
> >>>>>>
> >>>>> _______________________________________________
> >>>>> BLISS mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/bliss
> >>>>>
> >>> _______________________________________________
> >>> BLISS mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/bliss
> >>>
> > _______________________________________________
> > BLISS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bliss
> > 
>