Laura, I am not sure that a simple statement as you suggest would be sufficient. I just read the IANA Considerations section again, and I have some comments:
1. Perhaps it is just a nit, but there seems to be some confusion concerning terminology. I understand that an alert-identifier comprises an alert-category followed by an alert-indication. Bu then in 7.1 I see: "Alert URNs identifiers and alert-indications are identified by labels managed by IANA" Should it not be "Alert-categories and alert-indications ..."? Also sometimes alert-category is used, and sometimes alert-indication category. 2. In 7.1 it states: " The policy for assigning labels to alert-indications may differ for each alert-identifier category and MUST be defined by the document describing the corresponding alert-identifier." This does not make sense. If different documents specify different alert-identifiers belonging to the same category, they would all specify the policy for assigning alert-indications to that category, leading to possible conflict. Should policy not be defined in the document specifying the category? 3. As a result of the previous comment, I believe the present document should define policies for categories 'tone' and 'service', but I failed to find such statements. This brings me back to my original concern. I think we need a policy that requires at least expert review, in order to avoid the sort of situation where an identifier is defined without clear semantics or duplicating other identifiers in the registry. John > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 03 August 2009 14:33 > To: Elwell, John > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: [BLISS] Initial > ringtonesfordraft-alexeitsev-bliss-alert-info-urns > > > 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
