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

[Paul Kyzivat <[e-mail]>]

Hmm. For some reason I have not received Dale's reply that Laura is 
replying to below. So I'm responding here.

	Thanks,
	Paul

Laura Liess wrote:
> 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".)

I don't see a problem there. In the general case, if there are multiple 
URIs then the recipient has to decide how to rationalize them into 
something to be done. So what is wrong with giving some guidance in that 
regard?

Requiring all the categories to be specified in one URN has the downside 
that all category values need to be standardized as part of a single URN 
spec. Conversely, consolidating multiple URNs gives the potential to 
define a new category via an entirely new URN scheme. (I guess we should 
discuss if that is a good thing or a bad thing.)

> 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.

OK. You have convinced me this isn't a problem. Good!

>>> 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
>>
>