Subject: [salud] Currently known technical issues

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 8 Jul 2011 14:54:03 -0400

[as chair]

Given that nobody has suggested any further technical issues, I am repeating the list, but giving a short description of the benefits of the various alternative choices.  Please weigh in!

- Shall we combine all the characteristics into one URN, or specify each characteristic in a separate URN?

The first alternative leads to a very large set of possible URNs, but leaves each URN interpretable in isolation.  The second alternative uses a small set of URNs (possibly finite), but requires that they be used in groups for complex renderings.  The ultimate logic for combining the specified facets of the rendering is exactly the same, but the way the complexity is expressed differs.

- In regard to extensibility, shall we arrange for each characteristic value to be subdividable into more narrowly-defined values, which are themselves subdividable, etc.?

Allowing for infinite subdividability is good in abstract, but makes the system more complex.  Are there practical requirements to be met?

- In regard to extensibility, what proprietary or non-standard extensions will be possible?

- How will non-standard extensions be designated?  (Will they be consistently marked by a particular prefix?  Will they be constructed from domain names?)

There may be practical requirements as well -- How common will private extensions be?  Do we need to worry about explicit "namespaces" for extensions?

- How does the "legacy" URN <urn:alert:service:normal> fit into the new system?

This is sort of an after-thought, in that once we decide on the above questions, the detailed syntax will be devised to make the legacy URN valid.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2011 15:22:55 -0400

While its interesting to dice the issues this way, from a practical 
perspective I have trouble answering them independently. Ultimately it 
is an engineering problem to come up with a solution that balances the 
tradeoffs between these things into usable mechanism.

For instance, in principle it would be good to have hierarchical URNs 
that are extensible privately and publicly at every level. But something 
less than that is probably ok, and may be preferable if its easier to 
use and understand.

IMO what we need are complete mechanism proposals. The items you list 
below can be evaluated as attributes of the candidate mechanisms and 
used to contrast one with another. They can also be used to suggest 
avenues for improvement for a particular mechanism.

At the moment we have the mechanism proposed in 
draft-ietf-salud-alert-info-urns, and an alternative proposed by Dale. I 
have't seen any evidence that anybody is interested in proposing another 
distinct approach.

	Thanks,
	Paul

On 7/8/11 2:54 PM, Worley, Dale R (Dale) wrote:
> - How does the "legacy" URN<urn:alert:service:normal>  fit into the new system?
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Laura Liess <[email-masked]>
Date: Mon, 11 Jul 2011 15:12:54 +0200

Paul,
My understanding is that you propose to go,  for both approaches,
through Dale's issues list and try to answer the issues.
Is this correct?

Laura

2011/7/8 Paul Kyzivat <[email-masked]>:
> perspective I have trouble answering them independently. Ultimately it is an
> engineering problem to come up with a solution that balances the tradeoffs
> between these things into usable mechanism.
>
> For instance, in principle it would be good to have hierarchical URNs that
> are extensible privately and publicly at every level. But something less
> than that is probably ok, and may be preferable if its easier to use and
> understand.
>
> IMO what we need are complete mechanism proposals. The items you list below
> can be evaluated as attributes of the candidate mechanisms and used to
> contrast one with another. They can also be used to suggest avenues for
> improvement for a particular mechanism.
>
>> Given that nobody has suggested any further technical issues, I am
>> repeating the list, but giving a short description of the benefits of the
>> various alternative choices.  Please weigh in!
>>
>> The first alternative leads to a very large set of possible URNs, but
>> leaves each URN interpretable in isolation.  The second alternative uses a
>> small set of URNs (possibly finite), but requires that they be used in
>> groups for complex renderings.  The ultimate logic for combining the
>> specified facets of the rendering is exactly the same, but the way the
>> complexity is expressed differs.
>>
>> - In regard to extensibility, shall we arrange for each characteristic
>> value to be subdividable into more narrowly-defined values, which are
>> themselves subdividable, etc.?
>>
>> Allowing for infinite subdividability is good in abstract, but makes the
>> system more complex.  Are there practical requirements to be met?
>>
>> - How will non-standard extensions be designated?  (Will they be
>> consistently marked by a particular prefix?  Will they be constructed from
>> domain names?)
>>
>> There may be practical requirements as well -- How common will private
>> extensions be?  Do we need to worry about explicit "namespaces" for
>> extensions?
>>
>> This is sort of an after-thought, in that once we decide on the above
>> questions, the detailed syntax will be devised to make the legacy URN valid.
>>
>> Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jul 2011 13:26:46 -0400

> through Dale's issues list and try to answer the issues.

yeah, I think that is a way to acknowledge the issues and use them in a 
productive way.

Basically we then end up with a table of two columns (one for each 
approach) and a bunch of rows (one for each of Dale's issues).
Then we can score them against one another.

	Thanks,
	Paul

> 2011/7/8 Paul Kyzivat<[email-masked]>:

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 15 Jul 2011 16:50:55 -0400

[as individual]

There are (IMHO) only 4 significant design points right now, in the
vague state that crosses between requirements and design.  I think at
this time we can decide on the more requirement-like aspects of the
problem. -- Such as, will there be many or a few extension URNs
defined?

First, going through the points and looking at the advantages of
alternatives.  There are interactions between the points, which
suggest some choices which I will discuss at the end of this message.

> leaves each URN interpretable in isolation.  The second alternative
> uses a small set of URNs (possibly finite), but requires that they be
> used in groups for complex renderings.  The ultimate logic for
> combining the specified facets of the rendering is exactly the same,
> but the way the complexity is expressed differs.

Advantages of the single-URN approach:  Each URN can be interpreted
alone, and code that considers Alert-Info as a simple list of URNs
works by examining the URNs until it finds one that it can
understand.  The ordering of the list only expresses the sequence in
which the UA should check the URNs in order to find one it
understands, and we do not have to suffer the conceptual problem that
the interpretation of a list of URNs depends on their order.

Advantages of the multiple-URN approach:  Each URN is simpler to
understand.  In effect, we press the COMMA of the Alert-Info list into
service as the major-level divider of the Alert-Info information.  In
strict logic, this makes little difference, but it may be a significant
human-factors difference.  As a result, the syntax of URNs is simpler,
and in many practical situations, may be reduced to a fixed, finite
list.

>   value to be subdividable into more narrowly-defined values, which
>   are themselves subdividable, etc.?
> 
> Allowing for infinite subdividability is good in abstract, but makes
> the system more complex.  Are there practical requirements to be met?

Advantages of multiple-level extensibility:  Reduced risk that vendors
will decide they need to extend Alert-Info but can't do so within our
framework, and so add some ugly hack.

Advantages of simple extensibility:  The syntax of the URNs is simpler
-- this is particularly so in the single-URN approach; in the
multiple-URN approach, the simplification is fairly small.

>   extensions will be possible?

If we have multiple-level extensibility, this question is answered
automatically:  Any characteristic value can be subdivided by any
vendor in any way.

If extensibility is limited, then we have to plan where extensibility
is admissible.

>   consistently marked by a particular prefix?  Will they be
>   constructed from domain names?)
> 

There seem to be three approaches for building extension names:
reversed domain names (a la Java packages), a prefix like "v-" or
"[vendor name]-", or free-for-all.

Advantages of reversed domain names:  Name organization is clearly
delineated.

Advantages of simple prefixes:  Names are shorter, but collision
should still be rare.

Advantages of free-for-all:  Easy transition of a vendor extension
into standard usage.

----------

There is particular complexity introduced when combining the
single-URN approach and extensibility that allows a characteristic to
be specified by a variable number of words.  I think that there will
be more need for extensibility than we see right now, as vendors have
a lot of legacy features to bring in.  So let me propose as a debating
point:

- multiple-URN
- multiple-level extensibility

To ease extensibility:

- every defined URN can be extended by subdividing it

I am undecided on what syntax is best for extension names.

----------

Relative to draft-ietf-salud-alert-info-urns-02, this leads to changes
like this:

   service                        RFC XXXX  Alert-category for "service"
                                            alert-identifiers.
   service:normal                 RFC XXXX  Normal ring /rinback
                                            rendering (default value).
   service:call-waiting           RFC XXXX  Call waiting was
                                            initiated at the other side
                                            of the call.
   service:forward                RFC XXXX  Call has been forwarded.
   service:recall.calback         RFC XXXX  Recall due to callback.
   service:recall.hold            RFC XXXX  Recall due to call hold.
   service:recall.transfer        RFC XXXX  Recall due to callback.
   service:private.<private-name> RFC XXXX  Reserved for private
                                            extensions.

Remember that "service:normal" in this table means a URN
<urn:alert:service:normal>.

The "service:recall.xxx" group is turned into an additional level of
qualification:  service:recall.callback becomes
service:recall:callback, etc.  The reason for changing "." into ":"
here is that I'm converting to a simpler syntax that is allowed by
using the multiple-URN approach.

service:private.<name> remains as is, assuming that "private." is the
prefix for all private names.  (See the 4th major issue.)  Although it
seems to me to be excessively long.  Note that "." functions as a
letter here, that the various "private.a", "private.b", etc. are not
child nodes of the node service:private, they are siblings of
service:forward, etc.

But in addition, we would allow "private.<name>" children of all the
standard URNs, e.g., service:forward:private.<name> is a private
variant of service:forward in the same way that service:private.<name>
is an entirely private service-type designation.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Jul 2011 11:36:32 -0400

I'm still inclined toward the multiple urn approach, which Dale now 
seems to be favoring as well.

I'm pretty much neutral about the changes to that approach Dale is 
suggesting.

I think we need to talk about how easy we want private extensions to be. 
The use of these leads to dialects that present some barriers to 
interop. However this is minimized as long as the private extensions are 
always subdivisions of some existing URN, since those that don't 
understand the extension can just ignore it and used the unsubdivided 
version.

Its worse with new top-level URNs. Maybe we shouldn't allow private ones 
at the top level.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jul 2011 11:12:12 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Kyzivat
> Sent: 16 July 2011 16:37
> To: [email-masked]
> Subject: Re: [salud] Currently known technical issues
> 
[JRE] That's my inclination too.

> Its worse with new top-level URNs. Maybe we shouldn't allow 
[JRE] This is a good point. If a top level extension is not recognised, what would you fall back too? Of course, you might not recognise a top level value that has been introduced by subsequent standards action, so that is a problem in any case. I guess you just have to disregard a URN whose top level value you don't recognise. Even so, it might be good to remove "private" from this top level, to discourage non-standardized top levels.

John

---

From: Laura Liess <[email-masked]>
Date: Mon, 18 Jul 2011 17:10:59 +0200

Hi,
Thank you for the elaborate and constructive input.
I also favor the multiple-URN with multiple-level extensibility. For
the multiple-URN approach we have orthogonal categories. Only one urn
of each category is allowed in a SIP-message. With this approach, we
can see the URNs of a category as nodes of a tree. With the
multiple-level extensibility, each tree can allways be extended by
adding new leaves (standardized or private). We have in principle a
separate tree for each category. We have to register each tree level
and each node with IANA. This is acceptable.

For the single-URN approach we don't have such a simple structure. We
have a very large set of of combinations, many of them do not make
sense. Maybe there are ways to restrict this large set of
combinations, but it seems to me that this approch is more problematic
than the multiple-URNs approach.

Also I am fine with using ":" instead of "." as separator and
restricting the usage of private extensions to the lower levels.

Thanks
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 18 Jul 2011 15:32:20 -0400

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

I favor the single-URN approach *in principle*.  But the multiple-URN
approach makes things easier on humans in several ways.  In
particular, it makes the syntax problems much simpler.  And while the
specifications are executed by computers (which won't be affected
much), the software is designed (and debugged) by humans.

In particular, it becomes so much easier to arrange for:

	urn:alert:service:recall:hold:level4:level5:avaya:foo

without it being confusing to someone trying to debug a system.

> Its worse with new top-level URNs. Maybe we shouldn't allow private ones

Yes, I think that is key:  "this is minimized as long as the private
extensions are always subdivisions of some existing URN"

I suspect there will be points where private top-level categories
would make sense -- but that will not be common.  The problem is that
vendors will frequently *think* they need a private top-level
category.

Can we enforce some sort of "expert review" requirement on vendor
extensions?

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 18 Jul 2011 15:51:49 -0400

[as individual]

[BTW -- If I forget to mark a message, it means I am posting as an individual.]

> From: Laura Liess [[email-masked]]
> 
> of each category is allowed in a SIP-message.

I think we do not want to limit a set of URNs to have only one of each
category.  Instead, I think we want a rule that the earlier URNs are
to be given higher priority when two URNs conflict, but an arbitrary
sequence is allowed.  This allows implementing a number of actions
very simply:

- If you put a URN at the beginning of a sequence, its effect will be
  carried out if at all possible, regardless of the following URNs.
  E.g., if you put "urn:alert:service:recall" at the beginning of the
  string, the UA will indicate "recall" if it possibly can, and then
  beyond that, it will indicate whatever of the original URNs it can.

- If you put a URN at the end of a sequence, its effect will be added
  to the indication, as long as it is compatible with what was
  specified earlier.

- If you put two URNs in a sequence, and one is an extension of the
  other, they both have full effect (which is the same as the effect
  of the longest one).  So you can write this sequence without an
  error:

  urn:alert:service:recall,
      urn:priority:high,
          urn:alert:service:recall:private:avaya:X

  and get the effect "urn:alert:service:recall:private:avaya:X"

And in general, resolving these sorts of contradictory specifications
will be necessary because UAs won't have renderings for all
combinations of the values that they support.  E.g., a UA may have
renderings for:

#1   urn:alert:A:1, urn:alert:B:1
#2   urn:alert:A:1, urn:alert:B:2
#3   urn:alert:A:2, urn:alert:B:2

but no rendering for

     urn:alert:A:2, urn:alert:B:1

So if I send it "urn:alert:A:2, urn:alert:B:1", there is a
contradiction -- but the sender couldn't have predicted the
contradiction, because it isn't obvious from the syntax.

The concept is that

    Alert-Info: urn:alert:A:2, urn:alert:B:1

gives priority to the "A:2" part, and so the UA would choose rendering
#3 above.  But

    Alert-Info: urn:alert:B:1, urn:alert:A:2

gives priority to the "B:1" part, and so it would choose rendering #1
above.

Once you can handle this sort of contradiction, it's easy to handle
contradictory specifications of the same characteristic -- use the
first of them.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2011 16:41:14 -0400

> Can we enforce some sort of "expert review" requirement on vendor

We can specify any of the standard mechanisms that we want, including 
expert review.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2011 16:43:50 -0400

Dale,

I agree with the approach you are suggesting below.
But I think it requires some fairly careful specification of how these 
are to be interpreted if we are to get consistent implementation.
You already wrote some words about something similar in your earlier 
post on the single url approach, which could probably be adapted to fit 
here.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 20 Jul 2011 15:14:03 -0400

[as individual]

> From: Paul Kyzivat
> > sequence is allowed.

Let me write another version of the algorithm I described some months
ago.  I'm sure that I can make it much clearer what the processing is
doing.  Then people can discuss whether that is a workable approach.

Dale