IMO this is off to a good start, but I do have a few comments:
In section 2, the example is inconsistent with the syntax of the URN. It
appears that the character following "service" should be a ".", not a
":". Also, "sip:" doesn't belong in the example. I think the example
should look like:
Alert-Info: <http://www.exmple.com/sound/moo.wav>,
<urn:alert:service.call-waiting>
Also, perhaps too much has been cut and pasted from the service URN
draft. Specifically:
For any given service URN, service- identifiers can be removed right-
to-left; the resulting URN is still valid, referring to a more
generic service. In other words, if a service 'x.y.z' exists, the
URNs 'x' and 'x.y' are also valid service URNs.
For one thing, this is defining the "alert" URN, not the "service" URN,
so the language is at least confusing. Also, this hierarchical
interpretation is most likely not appropriate in all cases. E.g. while
it may be clear what to do when receiving
<sip:urn:alert:service.call-waiting>, what should one do with
<sip:urn:alert:service> ???
And in the case of urn:alert:tone.foo.bar its hard for me to imagine a
hierarchical naming scheme that makes any sense. If the hierarchical
approach applies at all, it likely only applies to urn:alert:service.*.
I'm also slightly dubious of "service" as the appropriate
characterization for named alerts that are more generic than names for
tones. I think these are likely names for concepts, but I'm not
convinced the concepts are necessarily "services", though in some cases
they might be. Perhaps it would be better to consider them as "states".
E.g. urn:alert:state.on-a-call instead of urn:alert:service.call-waiting.
Did you intend to create a definition for service.call-waiting as part
of this document? Or is that only an example, and the actual definition
will come in some other document?
It would also be helpful to discuss urn:alert:tone a bit more. I'm
thinking there needs to be more in the registration template for a tone,
defining which tone it represents in some way. This could be a bit
tricky, since the goal is to avoid giving a specific encoding. Somehow
it needs to identify the equivalence class that includes all acceptable
renderings of the tone while excluding renderings of things that are
*not* of the tone. And I think it would be helpful to give some examples
of tones. Would it make sense to extablish some substructure under
alert:tone? E.g. some country-specific structure?
Also, a typo in section 6.1: s/lables/labels/
Thanks,
Paul
Alexeitsev, D wrote:
Hi,
I've submitted an initial ID on the URNs for use with the Alert Info.
The draft extends the usage of the Alert-Info header to include URNs
that have a predefined meaning. For example specific types of ringback
tone or specific indication that something happens at the callee side
during alerting like call-waiting.
http://www.ietf.org/internet-drafts/draft-alexeitsev-bliss-alert-info-ur
ns-00.txt
Comment and commentars are warmly welcomed.
Greetings,
Denis
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
