Hi Paul
[DA] Thanks for the comments, reply inline
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>
[DA] I was not sure about this one, some example I've came across have
used the URN including the sip prefix others without. I would correct
the example to the right notation.
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.*.
[DA] Right - it was also my concern, but I did not want to split the
branches to be hierarchic and non hierarchic, as it would complicate the
syntax. I would think about some better wording around this issue
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.
[DA] I understand your point, but I think there is value in both
approaches. Personally I can live with either one, so any other opinion
is appreciated.
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?
[DA] My intent was to create a definition for call-waiting in the same
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?
[DA] The tone section is just a placeholder at the moment. Any input on
the desirable values is appreciated.
Also, a typo in section 6.1: s/lables/labels/
Thanks,
Paul
[DA] Thanks,
Greetings,
Denis
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
