Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt

[Paul Kyzivat <[e-mail]>]

Alan,

Sorry to be slow in responding. Comments inline.

	Thanks,
	Paul

Alan Johnston wrote:
> Paul,
> 
> Thanks for your comments on the draft.  See mine below.
> 
> Thanks,
> Alan
> 
> 
> Paul Kyzivat wrote:
>> responses inline
>>
>> [e-mail] wrote:
>>> Paul,
>>> Thank you very much for taking the time to look and comment the draft.
>>> After the changes we did shortly before the submission deadline, there
>>> are some inconsistecies and open items. We are aware of some of them and
>>> probably there are some we are not aware of. For the problems we are
>>> aware of, there are alternative solutions. In some cases, we did not
>>> have a clear opinion which way to go and we would like to hear others
>>> opinions.
>>>
>>>
>>> Please find comments inline:
>>>     >     > This seems to be shaping up well. I think the 
>>> requirements are
>>> quite     > clear now.
>>>
>>> It's good to hear that we have achieved at least a smal stepp in the
>>> right direction :-).       >     > I don't fully understand what is 
>>> intended regarding
>>> combination of     > multiple alert URNs for a specific situation. 
>>> Section 4.5
>>> states:
>>>     >     > >    finally, a short Albanian auto-callback tone could be
>>> indicated
>>>     > >    Alert-Info: <urn:alert:service:auto-callback>,
>>>     > >    <urn:alert:tone:short>, <urn:alert:tone:al>.
>>>     >     > while section 7.3.6 states:
>>>     >     > >    Alert URN Indications from the same group should not be
>>> combined.
>>>
>>>
>>>
>>> To avoid the combinatorial explosion of IANA values as Adam pointed out
>>> in his comment
>>> http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html  ,  we
>>> decided to abandon the usage of sub-indications for  the use cases we
>>> have in the draft and to register only discrete tokens as top-level
>>> registrations.  (With county-specidfic ring and busy tones, we almost
>>> got the problem Adam talked about.) The sub-indications are no longer
>>> used in the current version of the draft. 
>>
>> So, maybe that is the confusion. I didn't understand that from reading 
>> the text.
>>
>>> We thougt about changing the template in chapter 3 from
>>>                 alert-indication = top-level *("." sub-indication)
>>>         top-level        = let-dig [ *25let-dig-hyp let-dig ]
>>>         sub-indication   = let-dig [ *let-dig-hyp let-dig ]
>>>
>>> to just
>>>            alert-indication= let-dig [ *let-dig-hyp let-dig ]
>>>
>>> But we are not sure if everyone would agree with this, so we would like
>>> to have feedback from the WG on this issue.  
>>
>> I don't know yet. The alternative is apparently to have multiple URNs 
>> and interpret the combination. I'm having difficulty imagining how 
>> that would work. I have always assumed that in the end a URN would be 
>> "looked up" locally by the UA and resolved to *something* that it 
>> could render.
>>
>> I will keep an open mind, but I'll need a better explanation of how 
>> multiple URNs are to be combined into *something* that can be looked up.
>>
>>> There is an inconcistency concerning the alert indications "priority",
>>> "short" and "delayed": In chapter 4, they are now  top-level indications
>>> in the alert-category "service", therefore in the same group eith
>>> "auto-callback".     In chapter 7 there is a dedicated group for them
>>> "Additional Indications for PBX-tones" in the "tones" alert-category.
>>> We must have to decide which alternative to take. If we decide for the
>>> chapter 4 alternative, we must change either the combination rule or the
>>> example you complained about.
>>>
>>>     > I could find no definition of what constitutes a "group". The
>>> first     > thing that comes to mind is "service" vs. "tone", but the 
>>>     > above example     > violates that. It seems to me that you need 
>>> some notion of
>>> orthogonal     > properties in order to define what can/cannot be 
>>> combined.
>>>
>>> It's true, it's quite impossible to guess from the text what I meant
>>> here. A group consists of the indications in one sub-chapter 7.3.1 to
>>> 7.3.5. I just looked for a way to avoid combinations of contradictory
>>> URNs, e.g.   that <urn:alert:tone:internal> is combined with
>>> <urn:alert:tone:external>   or  <urn:alert:tone:us> is combined with
>>> <urn:alert:tone:de> .   If we agree that this kind of groups makes sense
>>> and we keep it, some definition needs to be added.  But maybe there are
>>> better proposals in the WG about how to avoid combinations of
>>> contradictory indications?
>>
>> It seems like what you must be doing is replacing a hierarchy with an 
>> N-dimensional matrix which is sparsely populated. That seems harder to 
>> deal with.
>>
> 
> Perhaps, or perhaps not. 

When I said "seems harder" that's what I meant. I'm not *sure* its 
harder. Mostly I'm trying to understand the implications.

> Remember that this is just a suggestion, 
> rather than a command about a ring or ringback.  It is perfectly 
> reasonable for UAs to simply ignore the Alert-Info.  So, the sparse 
> scenario, where a server puts in as much information as possible, 
> possibly via multiple URNs, and the UA uses the ones it knows and 
> ignores the rest.

Yup. But there really isn't much point if everybody just ignores the 
info. So what is important is to make clear what the *intended* behavior 
is, when not overridden by policy. I think that intended behavior isn't 
very clear if there is just a bunch of values for multiple "dimensions" 
and no notion of how they might then be turned into something 
perceptible by a person.

>> I have a sip pbx phone on my desk. I don't have any distinction for 
>> internal vs. external, and have no clue how "normal" would be 
>> different from one or the other of those. I don't really desire any 
>> distinction on any of those terms.
> 
> Remember, the use case for normal is driven by shared appearances - we 
> want to insert an appearance number parameter into the Alert-Info but we 
> do not want to convey any particular Alert, so we use normal as a no-op.

Ah. So maybe its just a matter of my not understanding what connotation 
you meant me to get from the name. You mean it to be like "unspecified".

>>> I would keep the two worlds disjunct. E.g. , I have a sip handy which is
>>> attached sometimes to the pbx and sometimes to my public carrier at
>>> home, I may want the pbx ringing tone to be different from the ringing
>>> tone at home. 
>>
>> I don't really have any objection to a bunch of "names" for extra 
>> arbitrary ring types. The real issue is deciding when to use one or 
>> another. Is the assumption here that these will typically be inserted 
>> by some agent acting on behalf of the phone acting on them, rather 
>> than being inserted by "the other" party? IOW, *my* pbx decides that 
>> an incoming call from you is "internal" or "external" and inserts a 
>> suitable value by its policy, rather than *your* phone deciding the 
>> call is internal or external and inserting the value that I then render.
> 
> I wonder if some of the confusion we are having is because we are not 
> cleanly separating ring tones from ringback tones.  I'm going to think a 
> bit how we would structure this if we had separate registries or trees 
> for these.  For instance, the country specification would only make 
> sense for ringback tones.  Also, things like priority would only apply 
> to ring tones, etc.

My original thinking was that there need not be any difference.
But maybe there is, at least in common practice.

While it isn't common practice, I can imagine it might be interesting to 
have the ring tone match the country of origin of the caller. But of 
course many would not like that, and would insist that their choice of 
ring tone(s) be honored.

I agree its worth considering splitting up the namespace into separate 
sections for ring alerts and ringback alerts.

	Thanks,
	Paul