Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs

[Laura Liess <[e-mail]>]

Dale,
Please see comments inline.

2010/6/16 WORLEY, Dale R (Dale) <[e-mail]>:
>> From: Paul Kyzivat
>
>> IIUC, in what Dale has proposed the "indication" includes a prioritized
>> list of capability-values. If we followed the syntax of the current
>> draft, then the prioritization would probably come by considering the
>> order of URNs in the Alert-Info header to be significant.
>
> I would very much like to avoid having different URNs within the
> Alert-Info header interact; that seems to me to be against the concept
> of each URN being a distinct name.  (Which is why I am assuming that
> the syntax allows one URN to contain multiple "values".)

We had URN to contain multiple "values" in the initial proposal, see
http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt,
but only to some degree. We had there duration and priority in one
URN, but for combining call-waiting and duration we still needed two
URNs because they were different categories. For this version, we got
following comment from Adam:
http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . For
the next version of the draft,  Alan and I agreed to change to
combinations of discrete tokens.
So upto now we discussed two alternatives:
1) Return to URNs which contain multiple values, maybe with a modified
syntax to avoid multiple URNs. Problem: We have to find a way to avoid
the problem Adam pointed out to.
 2) Or we can stay with the current model of different interacting
URNs within the Alert-Info header. Problem: We need to define proper
combination and rendering rules.

I think both could work fine if we can solve the corresponding problem.


>> One thing that *isn't* covered by Dale, or the above, is what to do if
>> the "renderer" disagrees with the "specifier" about the priorities. I
>> don't (yet) have an opinion if that is a problem that needs solving.
>
> Well, strictly speaking, the renderer doesn't have to follow the
> algorithm -- the normative part of the RFC will spell out what the
> intention of the URN is and what the constraints on renderers are, and
> we will put the algorithm in a non-normative appendix to prove that
> conforming renderers can be implemented straightforwardly.
>
>> From: Laura Liess
>
>> the problem I have with this is that we have
>> urn:alert:service:call-waiting already implemented and already
>> specified in 3GPP.
>
> If that is the *only* such URN defined and implemented in 3GPP, I
> expect that we can adjust the new syntax to give that one URN the
> intended interpretation while still implementing the semantics we
> agree upon within the whole namespace.
>
> Even if the syntax we decide upon is completely incompatible with this
> one URN, we can explicitly define it as a special case.  In the most
> extreme case, the RFC would define a *different* URN namespace, and we
> would specify that urn:alert:service:call-waiting maps to a specific
> URN in the new namespace.

I would prefer this to fit in the general scheme we are going to define.
>
> The harder situation is if the specifier wants to indicate some
> particular variant of the call-waiting signal.  What URN does it
> provide that include the variant information while still appearing to
> be "urn:alert:service:call-waiting" to 3GPP-only renderers?

I hope understand your question correctly.
Within 3GPP, there are no variants of the call-waiting signal. I am
not aware of any being used or needed by the DT.
This is probably a issue for PBXes, e.g. a short and  delayed
call-waiting signal. (Is this what you mean by "particular variant of
the call-waiting signal"?)  With both syntax alternatives we have up
to now, we would need at least two URNs. What you look for is getting
this all in only one URN, right?  Then we probably need a completely
new syntax. Maybe it's possible. We just have to be carefull to get
the problem Adam pointed out to solved.

Laura

>
> Dale
>