Subject: [salud] Private values, subtrees, and trees

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 2 Sep 2011 15:16:13 -0400

[as individual]

Let me float a proposal for handling private values:

There are various places where we want to allow organizations to create
private values or sub-values for various categories.  These values are defined
and "owned" by particular vendors, etc.  For instance, we have

urn:alert:service:call-waiting:<private sub-value>

or 

urn:alert:service:<private value>

There have been a number of proposals for the private values.  The -02 draft
currently gives the format "private.<private-name>", where "private-name" is
given in reverse FQDN format, based on an FQDN registered by the organization
that defines the value.

But given that we can replace "." with ":" for separating the components of
the "alert-indication" (in the BNF), I think we can shorten the private name further,
making them easier to use:  Just use the organization's FQDN (or perhaps a reverse
FQDN) -- the distinguishing feature being that none of the standard values contain
".", so the private values are distinguished without any further qualification.

So for example, Avaya (my employer) could use:

urn:alert:service:call-waiting:avaya.com

urn:alert:service:avaya.com

as privately defined values.  (The first of them is a sub-value of "service:call-waiting",
so the recipient knows something about the value even if it doesn't know the meaning
of the private sub-value.  The second is a value of "service" which can only be interpreted
if you know what the private value means.)

Various elaborations that create additional private values and subvalues thereof
can be made without adding too many more characters.  For instance, Avaya can have
several distinct private versions of call-waiting:

urn:alert:service:call-waiting:abc.avaya.com
urn:alert:service:call-waiting:def.avaya.com
(these are siblings in the tree under service:call-waiting)

or it can subdivide its private version of call-waiting:

urn:alert:service:call-waiting:avaya.com:abc
urn:alert:service:call-waiting:avaya.com:def
(these are siblings in the tree under service:call-waiting:avaya.com)

Etc.

This (small) change in approach has a number of positive features:

- Private values are tied to domain names, and so name collisions are avoided.

- Domain names are reasonably short, so the URNs using private values are
not excessively long.

- Private values are syntactically marked by using ".", so they can always
be recognized.

- No characters beyond the domain name are needed to introduce the
private value name.

Relative to -02, the changes are small:
Replace "." with ":" in alert-indication and remove the "private." prefix
from the private name definitions.

This idea works equally well with the private values being forward
FQDNs or reverse FQDNs (which is what -02 uses).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Sep 2011 17:10:52 -0400

Dale,

This proposal works for me.

I can go with either forward or reversed fqdns. The reversed ones have 
the benefit of providing a consistent left to right specialization. The 
forward ones have the benefit of being more what people expect.

Would you expect that the rules for interpreting URNs that are only 
partially understood would apply to components of fqdns as well? If so 
then I think we should use reversed fqdns. If an fqdn component must be 
understood in full, or not at all, then the forward fqdns are probably ok.

	Thanks,
	Paul

On 9/2/11 3:16 PM, Worley, Dale R (Dale) wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 7 Sep 2011 15:09:14 -0400

[as individual]

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

Esthetically, I favor forward FQDNs.

> understood in full, or not at all, then the forward fqdns are probably ok.

I hadn't though of the possibility of understanding *part* of an
FQDN-as-private-value.  I suppose an element could understand
"avaya.com" without understanding "aura.avaya.com".  ("Avaya Aura" is
an Avaya product.)  In practice, a vendor should really use ":foo" for
subdividing any private namespace.  But they would be allowed to use
"foo.bar.example.com" under any set of rules that I can imagine us
setting.

I suppose these considerations (along with not changing what -02 does)
put the choice in favor for reversed FQDNs over forward FQDNs.

Dale