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
