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
> -----Original Message-----
> From: Elwell, John [mailto:[email protected]]
> Sent: Tuesday, August 04, 2009 11:02 AM
> To: Adam Roach; Liess, Laura
> Cc: [email protected]
> Subject: RE: [BLISS] Initial ringtones
> fordraft-alexeitsev-bliss-alert-info-urns
>
> 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
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Adam Roach
> > Sent: 03 August 2009 16:41
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: [BLISS] Initial ringtones
> > fordraft-alexeitsev-bliss-alert-info-urns
> >
> > [email protected] 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.
> > >
> > > Or do you see a problem with this approach?
> > >
> >
> > 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:
> >
> > >> 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.
> > >>
> >
> > 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
> > _______________________________________________
> > BLISS mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/bliss
> >
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
