Subject: Re: [salud] Notes on the requirements

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 1 Mar 2011 21:37:48 -0500

________________________________________
From: Paul Kyzivat [[email-masked]]

If that particular semantic is what you want, then I will assert that we
must treat some agence of Hungary as the "naming authority" responsible
for subdivisions of urn:country:hu. If they (whoever "they" are) want to
carve out a subspace for carriers, then they can do so.
________________________________________

I think it can be made to work, as long as we have a mechanism for "private" subdivisions of standardized divisions.

And we already intend to have a mechanism to create private categories; my idea is that we need to generalize it to allow private subcategories of established categories.

But in a larger sense, will we admit tree-like ramifications of categories (that is, an unlimited number of layers of subdivisions), or are we going to restrict subdivision to one level?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2011 09:27:51 -0500

I don't have any conceptual problem with tree-like category partitioning.

I'm not sure about a private subdivision of country. Couldn't you get 
the same effect with a country-specific subdivision of private? E.g.

	urn:alert:locale:private:hu.cisco

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 2 Mar 2011 16:14:04 -0500

[as individual]

What is the "private" that is being subdivided first into "hu" and that is subdivided into "cisco"?

What I see is that there is a "geographic" category, which has "hu" as a subdivision, and within that, a privately-defined subdivision "cisco".

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 2 Mar 2011 16:39:01 -0500

[as individual]

> > - In section 2, REQ-7, add a clause to include that the ringback
> > indications are rendered by the caller independently of the ring tone
> > indications sent by the caller:
> >
> >   REQ-7: An indication is transmitted from a specifier to a renderer,
> >   which must base its rendering decision only on the indication.  In
> >   particular, there is no multi-message negotiation process>,<
> >   carrying of context from one indication to the next, >or carrying
> >   of context from the caller's indication of the ring tone to the
> >   rendering decision by the caller of the ringback tone<.
> >
> > This makes sure that the caller doesn't interpret the ringback
> > indication as an "answer" that is somehow based on the ring
> > indication.
> 
> [LL] John already sent a comment and proposed a new text for REQ-7:
> "The mechanism must provide only an indication capability, not a
> negotiation capability. The mechanism must not require an indication
> to depend on the context provided by a previous indication." If we add
> "in any direction" at the end of the sentence, would this cover your
> comment?

Yes, that would be a good solution.  (Although I would use the phrase
"in either direction", as there are only two directions involved.)

> > - We may not need the last sentence of REQ-10, as what it describes is
> > covered by REQ-11.  The text would become:
> >
> >   REQ-10: If the specifier and the renderer have designs that are
> >   properly coordinated, the indications must be able to reliably carry
> >   all extensions that are supported in the coordinated designs.
> >   >[delete sentence]<
> >
> > - There is a word missing in REQ-11:
> >
> >   REQ-11: In any situation, the renderer must be able to perform close
> >   to the best possible rendering that it could do even >if< the specifier
> >   had specific knowledge of the renderer's capabilities.
> 
> [LL] For both REQ-10 and REQ-11, I agree with you. John also had
> comments for these requirements and had text proposals. Looking at
> your and John's comments, I would propose following text:
> 
> "REQ-10: The mechanism will allow an indication to reliably carry
>    all extensions if the specifier and the renderer have designs that are
>    properly coordinated.
>
> REQ-11: The mechanism will allow a renderer to select a tone that
> approximates to that intended by the specifier if the renderer is
> unable to provide the precise tone indicated."
> 
> What do you think?

Yes, I think that works.

> > - We should add for completeness the possibility of service-provider
> >  specific indications:
> >
> >   3.4  Service-provider-specific ringback tone indications for the
> >   public telephone network
> >
> >   In the PSTN, different tones can be used by different service
> >   providers, even with one country.  End users are accustomed to hear
> >   the provider's specific ringback tone and would like to have this
> >   feature for SIP.
> >
> > This is technically interesting only in that it may require
> > subdivision of the country categories, or allowing an extension
> > category for indicating service providers.
> 
> [LL]  We can add this, but, in my opinion, we would not be consistent
> with the first sentence in Section 3 and with a decision taken in the
> past. During a discussion at the salud meeting in connection with
> US-specific ring tones brougt up by Adam, we agreed  include in
> Section 3 and define the identifiers only for use cases where the
> Alert-Info URN mechanism is needed today. We also agreed to require
> the mechanism to be flexible, so people can  add identifiers when new
> use cases arise.  Currently, I don't know of any SIP service provider
> requiring a specific identifier for ringback tone. If, in the future
> at&t needs such an identifier, it can either register a new identifier
> with IANA  <urn:alert:locale:country.us.at&t> or just use
> <urn:alert:locale:private.at&t-us>. My personal opinion is  to not add
> this use case. But I am open if people would like to have it in this
> specification.

Yes, if the use case is not requested at this time, it probably
excessive to describe it.  And as long as our extension mechanism is
suitably general, this use case will be covered without specific
consideration.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2011 16:52:25 -0500

> [as individual]

What is specified for "private" is that is is subdivided by "reverse 
domain names" such as is used in java for class namespaces.

In the case above, I assumed the existence of "cisco.hu" as a domain 
assigned to Cisco (which it actually seems to be), and hence 
urn:alert:locale:private:hu.cisco would be a potentially valid name 
"belonging" to Cisco.

It would of course also be possible to use:

urn:alert:locale:private:com.cisco.hu

Which to use is a matter of taste. I guess an enterprise that wanted to 
have locale & company specific alerts, and *didn't* have an assigned 
domain in every locale it cared about would prefer the latter form.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Mar 2011 17:02:53 -0500

Well, I think that the "reverse domain name" system is far too verbose.  But that's another issue.

What I'm looking for is not "a private category within which I specify Avaya", but "a private subdivision of locale:hu which is Avaya".  So it would be something like "urn:alert:locale:hu:private:com:avaya".  Its advantage is that even if you don't know the significance of "private:com:avaya", you know that it is a subset of "locale:hu".

The suspect that you're not accepting the idea of "unlimited levels of subdivision of the top-level categories".

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2011 18:34:12 -0500

I understand. Please feel free to propose something.
(But I don't promise to like it.)

My concern is that countries might want to do their own subdivision, and 
allowing carrier subdivision of the country might preempt that.

(I don't know, but sense that there are a lot of politics associated 
with locale definitions.)

Is it really necessary or appropriate to have carrier-specific 
variations on country-specific ring tones?

ISTM you can use the private mechanism to specify the carrier, and the 
locale to specify the country, and the device can decide which of those 
it prefers to honor, or to blend them in some way.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Mar 2011 13:19:52 -0500

[as individual]

My intention is to allow multiple and arbitrary subdivisions of all subdivisions, some of them standardized
and some "private".  This ensures that we don't get problems when someone decides to do it (which they will,
whether or not we define a mechanism to allow it).

The idea behind the somewhat elaborate algorithm I presented is to show that we can allow systems builders
this freedom without preventing devices from interoperating reasonably well.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2011 13:48:09 -0500

> [as individual]

Have you made a proposal for how to do that in this syntax? (I don't 
recall one.)

I introduced "private" as a way that seemed "good enough".
But I'm not opposed in principle to some more general mechanism.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Mar 2011 15:23:01 -0500

[as individual]

Here is the original version of the proposal:

Conceptual proposal for extensibility of Alert-Info URNs
http://www.ietf.org/mail-archive/web/dispatch/current/msg02011.html

It was sent to dispatch back in June, which makes it hard to find.

The essence of the algorithm doesn't depend on the particular syntax we choose.  And the algorithm really isn't that complicated in principle -- the core ideas are that there is an extensible set of top-level categories, and that all categories are subdividable.  The rendering device goes through the category values as specified by the URN(s) to be rendered, winnowing down its set of available renderings at each step, each winnowing step being to enforce as many levels of subdivision of the value as the device has renderings for.  Whatever remains at the end of the process is usable for rendering.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2011 16:59:15 -0500

Dale,

I think people have become "attached" to the current syntax.
So what I was wondering is if you had thoughts on how to remap your 
proposal onto some slight variation of this syntax.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Mar 2011 11:09:30 +0100

Sorry for lagging behind on this thread - I realise there have been lots of further posts. However, a comment on Paul's proposal below: 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Kyzivat
> Sent: 02 March 2011 14:28
> To: Worley, Dale R (Dale)
> Cc: [email-masked]
> Subject: Re: [salud] Notes on the requirements
> 
> 
> 
> > I think it can be made to work, as long as we have a 
> mechanism for "private" subdivisions of standardized divisions.
> >
> > And we already intend to have a mechanism to create private 
> categories; my idea is that we need to generalize it to allow 
> private subcategories of established categories.
> >
> > But in a larger sense, will we admit tree-like 
> ramifications of categories (that is, an unlimited number of 
> layers of subdivisions), or are we going to restrict 
> subdivision to one level?
> 
[JRE] I think a general principle is that a renderer should be able to work through the elements from left to right until it finds one it doesn't understand, and render based on the elements to the left of that element. So in this particular example, if the renderer doesn't understand any private extensions, the most it has to work with is "locale", which perhaps isn't very helpful. On the other hand, if the country, hu, appeared to the left of "private", the renderer would at least know that a Hungarian tone is needed. Does this imply an ability to insert private extensions at any point in the tree?

John

> 
> 
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2011 09:02:54 -0500

> [JRE] I think a general principle is that a renderer should be able to work through the elements from left to right until it finds one it doesn't understand, and render based on the elements to the…

I agree with you about the left to right processing for refinement of a 
particular urn. And yes, the idea I threw out here doesn't have good 
properties in that respect.

I didn't have in mind allowing private extensions arbitrarily like that, 
but I'd be interested to hear a proposal for how to do that.

	Thanks,
	Paul