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:[email protected]] > Sent: Monday, August 03, 2009 7:44 PM > To: Liess, Laura > Cc: [email protected]; [email protected] > 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 > > [email protected] 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:[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 > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
