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

From: <[email-masked]>
Date: Mon, 3 Aug 2009 15:32:56 +0200

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 Aug 2009 10:41:29 -0500

[email-masked] wrote:
> 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.  
>

I'm okay with that for the specific ringtone names (with the caveats 
raised by John Elwell about not wanting two strings that effectively 
have the same semantic meaning).

However, I think this is of considerably more importance:

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

I'll reiterate that the registry can become very, very full if we 
continue down this path. I would strongly suggest that you instead 
consider a scheme that defines discrete tokens, and then talks about how 
they can be combined. For example, instead of registering:

   1. normal
   2. normal.priority
   3. normal.short
   4. normal.delayed
   5. internal
   6. internal.priority
   7. internal.short
   8. internal.delayed
   9. external
  10. external.priority
  11. external.short
  12. external.delayed

I think you should register:

   1. normal
   2. internal
   3. external
   4. priority
   5. short
   6. delayed

And then define rules about how these can be stacked. In particular, one 
of the first things I'd be likely to try to add to the registry would be 
the pitch designations of A.S0014, but I don't think we *really* want a 
registry that looks like this:

   1. normal
   2. normal.high
   3. normal.medium
   4. normal.low
   5. normal.priority
   6. normal.priority.high
   7. normal.priority.medium
   8. normal.priority.low
   9. normal.short
  10. normal.short.high
  11. normal.short.medium
  12. normal.short.low
  13. normal.delayed
  14. normal.delayed.high
  15. normal.delayed.medium
  16. normal.delayed.low
  17. internal
  18. internal.high
  19. internal.medium
  20. internal.low
  21. internal.priority
  22. internal.priority.high
  23. internal.priority.medium
  24. internal.priority.low
  25. internal.short
  26. internal.short.high
  27. internal.short.medium
  28. internal.short.low
  29. internal.delayed
  30. internal.delayed.high
  31. internal.delayed.medium
  32. internal.delayed.low
  33. external
  34. external.high
  35. external.medium
  36. external.low
  37. external.priority
  38. external.priority.high
  39. external.priority.medium
  40. external.priority.low
  41. external.short
  42. external.short.high
  43. external.short.medium
  44. external.short.low
  45. external.delayed
  46. external.delayed.high
  47. external.delayed.medium
  48. external.delayed.low

And that's just with the three pitches that I want to add. If someone 
adds another semantic dimension, the size of the registry continues to 
grow exponentially.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Aug 2009 13:44:04 -0400

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Aug 2009 09:56:01 +0100

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

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 03 August 2009 14:33
> To: Elwell, John
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> 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
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Aug 2009 10:02:02 +0100

Adam,

I am not necessarily disagreeing with this combinatorial approach, but I
do have concerns about some of the examples. "Short" seems to stray into
the territory of rendering rather than meaning. The "high", "medium",
and "low" pitch designations certainly stray into that territory, and
how would I render these on a visual, as opposed to audible, user
interface?

John

> On Behalf Of Adam Roach
> Sent: 03 August 2009 16:41
> To: [email-masked]
> Cc: [email-masked]
> > The intent of the draft is to provide a general mechanism, 
> to register the template and to do initial registration for 
> > 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.  
> >

---

From: <[email-masked]>
Date: Wed, 5 Aug 2009 15:18:40 +0200

I like Adam's proposal to consider a scheme that defines discrete tokens
which can be combined. I also agree with John that we should avoid pitch
designation and use the semantic approach.  

For the use-cases currently defined in the draft the definitions in
chapters 3 and 4 already follow this approach. 

We could change chapter 7 and register: 
	-the alert-categories "service and "tones". 
      -for the "service"  alert-category the top-level alert-indications
call-waiting, forward, transfer-recall, auto-callback, hold-recall and
crisis. 
      -for the "tones"  alert-category the top-level alert-indications (
"normal", "external", "internal") and the 1st-level sub-indications
"priority", "short" ( or maybe "abreviated"?) and "delayed"    

We could in principle add also 1st-level and 2nd-level sub-indications
for A.S0014 tones if anybody knows the semantic. Other people can add
later values for the different levels of sub-indications. 

Maybe we should change the the ABNF syntax for the alert-category which
is "tone"/"service" in let-dig [ *25let-dig-hyp let-dig ] to allow other
people to add new alert-categories later ?

Laura 

> Sent: Tuesday, August 04, 2009 11:02 AM
> To: Adam Roach; Liess, Laura
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Wed, 5 Aug 2009 15:48:54 +0200

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, August 03, 2009 7:44 PM
> To: Liess, Laura
> Cc: [email-masked]; [email-masked]