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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Nov 2009 08:50:49 -0500

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
>>
>> [email-masked] 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

---

From: Adam Roach <[email-masked]>
Date: Fri, 06 Nov 2009 09:15:37 +0900

On 10/28/09 6:22 PM, [email-masked] wrote:
> I will take this as an open issue for the dispatch meeting slides. I
> hope Adam will be there because it was his proposal to use combinations
> of discrete items rather than hierarchy.

Sorry for not following this more closely.

At this point, I think we have two different things to tease apart: (1) 
The semantics for combining different dimensions of ringback, and (2) 
the syntax for combining these dimensions.

We really need to understand the first one before we start quibbling 
over the second one. So, while I do have some thoughts about the syntax, 
I'm not going to go into them -- even a little bit -- until we have a 
better grip on the semantic problem.

Here's an important point that Paul raises:
> It seems that what you propose is a multidimensional space, where 
> every point in that space is potentially rendered uniquely. But in 
> practice values will often be supplied for some but not all of the 
> dimensions. In that case we end up specifying some "slice" of the 
> array. I guess in this case you could look to see what you would 
> render for each point in the slice. If those are all identical, then 
> you are in good shape. But if they are not, then what? Do you pick one 
> of the points? That amounts to choosing a default value for each 
> unspecified dimension. Is that the right answer? 

I agree. We're effectively defining an n-dimensional space, and assuming 
that a point can be selected with fewer than n ordinals. And, yes, I 
think the correct answer is simply defining a default value for every 
new dimension defined -- preferably within the specification of the 
dimension itself (although some things, like country indication, would 
probably be better handled as local policy). Then, you can specify a 
value for as few as zero of the dimensions, and still have the answer be 
a point.

The other side of that coin is that clients receiving this information 
will not necessarily understand (or care to support) all of the 
dimensions being presented. I believe that this is handled on the 
recipient's part by ignoring any dimensions it does not understand.

However, I think that Paul's characterization of the difference between 
> N-dimensional matrix which is sparsely populated. That seems harder to 

I don't agree that it is sparsely populated. Many of the points might 
result in the same answer, but that doesn't mean it's sparsely 
populated. I think you could take the current draft and (modulo the 
issues with 7.3.3) pick any value from each of the three dimensions at 
random, and have a semantically sensible ringtone. Here; I'll roll the 
dice a couple of times: Internal short Brazilian ringback. External 
priority Pakistani ringback. You can play along at home -- find me an 
empty space in the matrix, and I'll concede the point.

So, quite to the contrary, I think the two approaches are *semantically* 
identical, and the only difference between what was proposed before and 
what is proposed now is a *superficial* and *syntactic* difference. If 
you need proof, I'll write a quick perl script that converts between the 
two syntactic representations. :)

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 06 Nov 2009 09:30:33 +0900

On 10/19/09 9:38 PM, [email-masked] wrote:
>     - Alert-Info URNs Indications for country-specific tones
>    

While I think this is a good dimension to have, I question the wisdom of 
replicating the entire ISO 3166-1 registry in an RFC and into IANA, for 
a variety of reasons:

   1. The initial registered list -- the one in the RFC -- will rapidly
      become out of date.

   2. The IANA registry will require constant updating to match the
      changes in ISO 3166-1. This either requires the IANA to keep up
      with changes in that registry (which is a task well beyond what we
      require of them at the moment) or it requires someone to send
      notes to IANA to update the registry whenever a change is made. We
      don't really have the structure necessary to ensure that someone
      will do that.

   3. If IANA and ISO 3166-1 do become out of sync -- which would almost
      necessarily happen from time to time -- you'll end up with
      implementations selecting at random between them (which is not a
      recipe for interoperability).

   4. The selection of country codes is highly political and rife with
      land mines -- some are forseeable (e.g. tw, fk), while others
      aren't necessarily. You can try to side-step this -- like ICANN
      tries -- by claiming that we don't take codes outside of ISO
      3166-1, and that we must accept all codes in ISO 3166-1; however,
      that hasn't kept them out of occasional hot water.

I would strongly suggest simply citing ISO 3166-1, not putting any 
values in the IANA registry, and simply giving a couple of 
representative (and politically uncontroversial) examples.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Nov 2009 10:00:02 -0500

I agree. It would be even better is there were already an URN 
designating country code. Then it could simply be referenced.
But there doesn't seem to be one right now.

Perhaps this doc could define one, and cite ISO 3166-1 for the 
definition of the values it can contain. It could then be used anywhere 
one wants to reference a country by URN, not just in Alert-Info.

	Thanks,
	Paul

Adam Roach wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: <[email-masked]>
Date: Fri, 6 Nov 2009 16:59:28 +0100

It's a good proposal. I fully agree. 
 
Laura

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adam Roach
	Sent: Friday, November 06, 2009 1:31 AM
	To: Liess, Laura
	Cc: [email-masked]; [email-masked]; Jesske, Roland
	Subject: Re: [dispatch] New version for the Alert-Info
URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt

		   - Alert-Info URNs Indications for country-specific
tones

	While I think this is a good dimension to have, I question the
wisdom of replicating the entire ISO 3166-1 registry in an RFC and into
IANA, for a variety of reasons:

	1.	The initial registered list -- the one in the RFC --
will rapidly become out of date.

	2.	The IANA registry will require constant updating to
match the changes in ISO 3166-1. This either requires the IANA to keep
up with changes in that registry (which is a task well beyond what we
require of them at the moment) or it requires someone to send notes to
IANA to update the registry whenever a change is made. We don't really
have the structure necessary to ensure that someone will do that.

	3.	If IANA and ISO 3166-1 do become out of sync -- which
would almost necessarily happen from time to time -- you'll end up with
implementations selecting at random between them (which is not a recipe
for interoperability).

	4.	The selection of country codes is highly political and
rife with land mines -- some are forseeable (e.g. tw, fk), while others
aren't necessarily. You can try to side-step this -- like ICANN tries --
by claiming that we don't take codes outside of ISO 3166-1, and that we
must accept all codes in ISO 3166-1; however, that hasn't kept them out
of occasional hot water. 

	I would strongly suggest simply citing ISO 3166-1, not putting
any values in the IANA registry, and simply giving a couple of
representative (and politically uncontroversial) examples.
	
	/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 7 Nov 2009 04:22:54 +0800

I agree with Adam's point here (matrix isn't sparse, but a lot of the 
n-dimensional points are really boring because they have the same value as 
other n-dimensional points).

I was seeing this the way Paul was seeing it previously, so this was a 
helpful insight.

Thanks,

Spencer

> The semantics for combining different dimensions of ringback, and (2) the 
> syntax for combining these dimensions.
>
> We really need to understand the first one before we start quibbling over 
> the second one. So, while I do have some thoughts about the syntax, I'm 
> not going to go into them -- even a little bit -- until we have a better 
> grip on the semantic problem.
>
>> It seems that what you propose is a multidimensional space, where every 
>> point in that space is potentially rendered uniquely. But in practice 
>> values will often be supplied for some but not all of the dimensions. In 
>> that case we end up specifying some "slice" of the array. I guess in this 
>> case you could look to see what you would render for each point in the 
>> slice. If those are all identical, then you are in good shape. But if 
>> they are not, then what? Do you pick one of the points? That amounts to 
>> choosing a default value for each unspecified dimension. Is that the 
>> right answer?
>
> that a point can be selected with fewer than n ordinals. And, yes, I think 
> the correct answer is simply defining a default value for every new 
> dimension defined -- preferably within the specification of the dimension 
> itself (although some things, like country indication, would probably be 
> better handled as local policy). Then, you can specify a value for as few 
> as zero of the dimensions, and still have the answer be a point.
>
> will not necessarily understand (or care to support) all of the dimensions 
> being presented. I believe that this is handled on the recipient's part by 
> ignoring any dimensions it does not understand.
>
> result in the same answer, but that doesn't mean it's sparsely populated. 
> I think you could take the current draft and (modulo the issues with 
> 7.3.3) pick any value from each of the three dimensions at random, and 
> have a semantically sensible ringtone. Here; I'll roll the dice a couple 
> of times: Internal short Brazilian ringback. External priority Pakistani 
> ringback. You can play along at home -- find me an empty space in the 
> matrix, and I'll concede the point.
>
> what is proposed now is a *superficial* and *syntactic* difference. If you 
> need proof, I'll write a quick perl script that converts between the two 
> syntactic representations. :)
>
> /a