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
