My initial feeling was that the hierarchical names didn't work well
here. But Dale's comments have me rethinking that. Among other things,
that is a way to deal with country specific tones as well. A basic name
can identify the generic meaning (e.g. "ringing") and a lower level name
could identify a local-specific variant. If you understand the full name
then you can render that, else just render something consistent with the
higher level semantic.
That may also provide an alternative to the "service" vs. "tone"
distinction.
Thanks,
Paul
[EMAIL PROTECTED] wrote:
From: "Alexeitsev, D" <[EMAIL PROTECTED]>
I've submitted an initial ID on the URNs for use with the Alert Info.
I like the overall concept -- the original Alert-Info with a true URL
is a nice idea but unlikely to be implemented, whereas it makes sense
to define a series of alert indication *meanings*, which the UA can
choose to render as it pleases.
But that only works if the set of URNs is well-standardized, so both
ends of the dialog know without negotiation that they can be used.
Service-related URNs make sense this way, but on the other hand, "all
the various country-specific ring tones and ringback tones" do not,
since for any one of these tones, most of the phones in the world will
not implement the URN. (Country-specific tones are how a UA *renders*
standardized alert URNs.)
I do see the logic in providing a hierarchical classification,
allowing some UAs to provide finer-grained information than others.
This isn't necessarily easy to design, though, because you have to pay
attention to how the fall-backs work. E.g., having a high-level
category "service" is useless because you can't report "service" alone
as a condition to the user. But you could have "busy.CCBS-available",
because "busy" is also a state that can be usefully rendered to the
user when "busy.CCBS-available" is specified.
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
