Subject: [salud] URN syntax, including private values

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

[as individual]

This is a proposal combining a number of elements which we seem to
have a degree of agreement on, along with some new proposals, so that
we can see the various details of the proposal together.  I've pointed
out the places where it differs from -02.

----

Each URN describes one aspect of the ring/ringback, so a complete
"indication" will often consist of several URNs (in a particular
order).

Each URN contains two or more components, separated by ":".  E.g.,
<urn:alert:source:internal>, <urn:alert:service:recall:hold>.  [This
differs from -02 in that the second and later components (the "name"s
within the "alert-indication" in the ABNF of -02) are separated by ":"
rather than ".".]

Standardized names consist of letters, digits, and hyphens, and must
conform to <label> in RFC 1035.  [This differs slightly from -02, in
that a name must start with a letter and not end with a hyphen.]

The following URNs are initially standardized:

    urn:alert:service:normal
    urn:alert:service:call-waiting
    urn:alert:service:forward
    urn:alert:service:recall   [added for completeness]
    urn:alert:service:recall:callback
    urn:alert:service:recall:hold
    urn:alert:service:recall:transfer
    urn:alert:source:unclassified
    urn:alert:source:internal
    urn:alert:source:external
    urn:alert:source:friend
    urn:alert:source:family
    urn:alert:priority:normal
    urn:alert:priority:low
    urn:alert:priority:high
    urn:alert:duration:normal
    urn:alert:duration:short
    urn:alert:duration:long
    urn:alert:delay:none
    urn:alert:delay:yes
    urn:alert:locale:default
    urn:alert:locale:country:<ISO 3166-1 country code>

[These differ from -02 as described above.]

Private names are reversed FQDNs of two or more <labels> (from RFC
1035) that must be registered by the entity that defines the use of
the private name.  Since all private names contain ".", they can be
syntactically distinguished from standardized names.  [This differs
from -02 in removing the "private." prefix.]

Open question:  How do we want to handle internationalized domain
names?  Do we allow Unicode characters to appear in the URNs, or do we
use the mechanisms that are/will be established to encode Unicode
labels into the current label syntax?

I am leaning toward allowing extensions on easier terms than -02.
Viz.:

- URNs with private names as the third or later name and which when
  truncated before the private name are a standardized URN, may be
  defined without restriction by users.  E.g.,
  <urn:alert:service:forward:com.avaya:special>

- URNs with private names as the first or second name require IETF
  expert review.
  E.g., <urn:alert:service:com.avaya:special>,
  or even <urn:alert:com.avaya:special-feature>

- Additional URNs composed of standardized names require standards
  action.

This set of choices supports my preference for "infinite
subdividability", and a great deal of vendor extensibility, but
prevents vendors from easily defining extensions that are semantically
much different from the standard URNs.  I do think we need a great
deal of extensibility, as there are many features in existing systems
that vendors will want to map into Alert-Info.

----

Of course, this doesn't address the "interpretation algorithm"
problem.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Sep 2011 19:51:14 -0400

Dale,

I'm happy with this extension mechanism. Its better than "private.".
I don't know about internationalization - I'm not up on what has been done.

	Thanks,
	Paul

On 9/7/11 3:54 PM, Worley, Dale R (Dale) wrote:
> <urn:alert:source:internal>,<urn:alert:service:recall:hold>.  [This
> conform to<label>  in RFC 1035.  [This differs slightly from -02, in
> Private names are reversed FQDNs of two or more<labels>  (from RFC
>    E.g.,<urn:alert:service:com.avaya:special>,
>    or even<urn:alert:com.avaya:special-feature>
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>