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
