Subject: [salud] Regarding <private-name>s

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 4 Jun 2012 17:27:26 -0400

[as an individual]

This message is to explain the ideas behind the choices for the syntax
of <private-name> in draft-ietf-salud-alert-info-urns.

Per Alfred's suggestion, Laura has updated the syntax to handle
internationalized domain names.  Unfortunately, while SIP allows full
Unicode, URNs are restricted to ASCII, so internationalized domain
names generate <private-name>s using their punycode form.

The primary purpose of <private-name>s is to provide a means for
telecommunication equipment manufacturers (PBX makers) to represent
their proprietary schemes for alerting signals.  We think it is
necessary to provide such a mechanism because PBX makers already have
schemes for alerting and will want to support those schemes using the
new mechanism, including aspects of their schemes that are not
standardized in the new mechanism.  If they cannot completely
incorporate their schemes into the new mechanism, the will extend the
mechanism with various poorly-organized proprietary extensions.

The extensions, URNs containing <private-name>s, are expected to only
be useful when the device that inserts the URN (a UA or proxy) and the
device that renders it are from the same PBX maker.  In all other
situations, we expect the renderer to simply ignore the extension URN.

The extension URNs are seen as a set of tokens that can be used by the
PBX maker with any meaning that they want.  We see no reason that the
PBX maker should register their extension URNs, as no other PBX maker
will want to interpret them.

We expect the PBX makers to be large companies that are capable of
maintaining ownership of a domain name for a long time.

The extension URNs are not needed as stable names of objects that have
a long existence.  In use, they are interpreted by the renderer within
seconds of being sent by another element.  Their only "storage" is in
the firmware of the SIP elements that generate and render them, which
we expect to have a lifetime of at most a few years.

If one device sends a URN that is incorrectly interpreted by another
device, the cost is low.  At worse, the call has an incorrect alerting
signal.

Because of this, we don't think it is necessary to add a
date-qualifier to the domain-name part of <private-name>s, as the
benefit of more stability in <private-name>s would be small but
millions of SIP messages would be lengthened.

Dale

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 29 Jun 2012 10:38:08 +0200 (MESZ)

Apologies again for the delay in responding to your messages.

> names generate <private-name>s using their punycode form.

That's no problem, since the generic syntax/encoding rules for URNs
hold: first normalize in Unicode, then encode in UTF-8, then perform
percent-encoding.

On the other hand, for the sake of brevity and clarity, URN Namespace
owners are well advised to restrict the possible syntax as they seem
fit.

> mechanism with various poorly-organized proprietary extensions.

"provide a means ... to represent ..." in the context of a URN
Namespace simply means that _either_
o  the owner/manager of the URN Namespace allocates and registers
   the URNs on behalf of the PBX makers (i.e., since you want to
   establish IANA as the ownaer and maintainer of the namespace,
   the BPX makers request IANA to assign URNs),  _or_
o  that IANA delegates a part of the URN Namespace to the PBX maker,
   thereby handing over responsibility for the management of that
   part of the namespace and to provide for URN resolution for it.

But if you want to support the latter case, your draft needs
to define such delegation process for IANA.

> situations, we expect the renderer to simply ignore the extension URN.

Nevertheless, if that shall be done within a URN Namespace,
the generic URN requirements from RFC 1737 (in particular the
first 3 bullets in Section 2 there: global scope, global uniqueness,
and persistence) need to be fulfilled.
Otherwise, you would likely need to seek for an alternate solution,
for instance a URI scheme for SALUD.

> PBX maker with any meaning that they want.  ...

Agreed.

>                                        ...  We see no reason that the
> PBX maker should register their extension URNs, ...

Well, _that_ IMO would be incompatible with the managed nature of a
URN Namespace.  (See above.)

> ... as no other PBX maker will want to interpret them.
>

As I have explained in the past, expectation alone does not matter;
in practice under most applicable, contractual and legal conditions,
domain names are simply leased by the next higher domain owner for
a potentially limited time (subject to paying fees, absense of
legal litigations of the domain name, etc.).
So to avoid legal risk for IANA, domain names can only be used
as components of eternally persistent identifiers like URNs
if they are structurally combined with a distinguishing component.

> we expect to have a lifetime of at most a few years.

Again: If the identifiers used are drawn from a framework for
persistent identifiers like URNs, they have to be persistent.
That does not mean that the "support" of the identifier needs to be
guaranteed eternally, but that the meaning assigned to the name
is unambiguous, is unique, and will never change.

> millions of SIP messages would be lengthened.

In an off-list conversation with Laura, I already have suggested
alternatives to full date-qualifiers:
IANA could delegate a branch of the salud namespace to a domain name
owner using a past year alone (that is related to activity of the
domain owner in this field), or a simple sequence number, as a
disambiguating component in the naming scheme.

> Dale

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+