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:[email protected]] > Sent: Thursday, July 30, 2009 3:49 PM > To: Liess, Laura; [email protected]; [email protected]; [email protected] > 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: [email protected] [mailto:[email protected]] > > On Behalf Of [email protected] > > Sent: 30 July 2009 10:26 > > To: [email protected]; [email protected]; [email protected] > > 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:[email protected]] > > > Sent: Wednesday, July 29, 2009 1:50 PM > > > To: Liess, Laura; [email protected]; [email protected] > > > 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: [email protected] [mailto:[email protected]] > > > > On Behalf Of [email protected] > > > > Sent: Tuesday, July 28, 2009 08:59 > > > > To: [email protected]; [email protected] > > > > 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 > > > > +49 6151 628-2761 (Tel.) > > > > +49 6151 628-3395 (Fax) > > > > +49 175 2961015 (Mobil) > > > > [email protected] (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: [email protected] > > > > [mailto:[email protected]] On Behalf > > > > > Of Adam Roach > > > > > Sent: Tuesday, July 28, 2009 2:30 PM > > > > > To: [email protected] > > > > > 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 > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > > > > _______________________________________________ > > > > BLISS mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > > > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
