Subject: [salud] "multiple URN vs. single URN" pros and cons (revision 1)

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 15 Oct 2010 21:53:44 -0400

[as individual]

"multiple URN vs. single URN" pros and cons (revision 1)

Introduction

This is to present a complete list of pros and cons regarding the
"multiple URN vs. single URN" issue.  I expect that it will go through
a couple of revisions, after which there will be nothing more to be
said about the issue and we can make a decision that will not need to
be reconsidered.

What is the question?

Neglecting the details of the URN syntax, there are two major ways to
approach constructing Alert-Info URNs within the framework that we
have been discussing:

"single URN" -- A single urn:alert URN can specify the value of
several "dimensions" of the alert tone/ring tone; thus only one URN is
needed to specify a tone in all the desired detail.  Such a URN
provides all of the information needed to select a particular tone to
be rendered.  If several urn:alert URNs appear in a single Alert-Info
header, the receiving element must select one of those URNs
(presumably the first of them that it understands) to determine the
tone.

"multiple URN" -- A single urn:alert URN specifies the value of one
"dimension" of the tone.  Thus, all of the urn:alert URNs that appear
in a single Alert-Info header must be considered as a group to
selecting a particular tone to be rendered.

Pros and Cons of the two approaches

1. Non-issue:  The combining algorithm

It must be noted that in both approaches the semantics of the
algorithm that combines a number of dimension values to select a
particular tone is exactly the same; the difference is how one
syntactically expresses the information that is input to the combining
algorithm.

2. "Each URN stands alone"

In can be argued that every URN's should designate the same thing
regardless of the context within which it is used.  This has been true
of all URNs defined heretofore.

Heretofore it has been assumed that if an Alert-Info header gives a
series of URIs, that the UA must choose one from among them.
(Presumably it renders the first one that it is capable of rendering.)

These principles argue for the single URN approach.

3. Simplicity of enumerating defined values

There are a considerable number of values of dimensions that we will
define in a standardized way (in addition to unlimited extension
possibilities).  In the multiple URN approach, these values can be
listed as complete URNs.  In the single URN approach, these values are
syntactic components of complete URNs, complicating the definition and
registration process.

4. Upward compatibility with 3GPP

3GPP is jumping the gun and prescribing that the following URNs
have particular uses:

    urn:alert:service:call-waiting in "3GPP TS 24.615 V8.3.0 (2010-03)"

    urn:alert:service:crs in "3GPP TS 24.183 V9.2.0 (2010-06)"

It is desirable that the full urn:alert mechanism can be used with
these values in an upward-compatible way.  We assume that the syntax
that we define will admit these two URNs as specifying the values
"call-waiting" and "crs" for the "service" dimension.  This provides
compatibility when a 3GPP element sends one of these values to an IETF
element.  The difficulty arises in the reverse direction, when an IETF
element wishes to send the values for several dimensions, and the
receiver is a 3GPP element that understands only these two urn:alert
URNs.

In the multiple URN approach, one of the above URNs would be specified
in a list along with other urn:alert URNs.  The 3GPP receiver would
ignore the other URNs and process the URN that it understands.  For
example:

    Alert-Info: urn:alert:service:call-waiting, urn:alert:locale:us

In the single URN approach, the sender would have to provide two URNs,
the first being a multi-dimension URN, and the second (lower-priority)
URN being one of the above "upward compatible" URNs.  The 3GPP
receiver would ignore the first URN and would process the second URN,
which it understands.  For example:

    Alert-Info: urn:alert:service:call-waiting/locale:us,
        urn:alert:service:call-waiting

Comments?  In particular, are there any aspects of this question that
I have overlooked?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 09:19:16 -0400

Dale,

I'm not sure I agree that it is currently necessary for a recipient of 
Alert-Info to choose one of the URNs supplied. Presumably it could 
choose more than one, so long as they don't conflict in what they 
require the recipient to do. Its just that currently there are no formal 
"combining rules".

Another potential advantage of the multiple URN approach is that it does 
not, in principle, require that all the dimensions be defined within the 
scope of a single urn scheme. While all the currently proposed 
dimensions are proposed to be expressed by a single urn scheme, it would 
certainly be possible to amend that in the future. There are of course 
pros and cons to that as well.

	Thanks,
	Paul

On 10/15/2010 9:53 PM, Worley, Dale R (Dale) wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Oct 2010 15:57:06 +0200

I don't have anything to add to Dale's list of considerations. I think the separate URNs approach probably wins by a small margin.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Kyzivat
> Sent: 18 October 2010 14:19
> To: [email-masked]
> Subject: Re: [salud] "multiple URN vs. single URN" pros and 
> cons (revision 1)
> 
> Dale,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 11:45:45 -0400

I don't have a strong bias either way, at least conceptually.
But on esthetics I think I prefer the proposed separate URNs approach of 
Dale's first swag at a single URN approach.

	Thanks,
	Paul