Alexeitsev, D wrote:
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.
With the sip prefix it is a sip URL, and must conform to that syntax.
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 think I would allow hierarchical naming for purposes of delegating the
naming authority, but without any assertion that you can infer any
meaning by trimming of trailing components.
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.
I don't have a strong opinion on it either, though I think the term
"service" is generally overworked.
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 was unclear whether 6.4 was really an initial registration or just
part of the template. If its really an initial registration, then the
RFC references should somehow be tagged with instructions that they be
replaced by the assigned RFC number for this document. Also, then you
probably want to leave out tone.xyz (unless there really is an "xyz"
tone.) But maybe it would be appropriate to add some real tones.
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.
One more thing here: the draft is very focused on ring*back* tones. But
Alert-Info is applicable to both ringback and *ring* tones. That may be
inspiration for more tones that should be defined.
It also may be the case that the same URN may be used for both a ring
and ringback, though it may be rendered differently. (The fidelity of
the ringback may be a lot better than for the ring.) I don't know if
this bears mentioning or not.
Thanks,
Paul
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
