[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
