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

[<[e-mail]>]

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