Subject: [salud] Why have a new URN namespace?

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

[as an individual]

We could, in a somewhat natural way, incorporate alert URNs into the
urn:ietf tree, or any other tree for that matter.  I think that would
not be a good idea because we need to define some very detailed rules
for how alert URNs are interpreted.  And although we could simply
define that those rules applied to all URNs that start
"urn:ietf:foo:bar", that would be rather unnatural.

In order to ensure that alert URNs become widely used in the market,
we need to allow manufacturers of existing PBXs to map their current
alerting schemes into the alert URNs -- without losing any
distinctions that their current alerting schemes now make.  Thus, we
need a well-developed extension mechanism that does not interfere with
interoperation between different manufacturer's devices.

The syntax of <private-name>s, the rules for extensions (section 7),
and the rules for combinations (section 8) are all driven by the
requirements of the extension mechanism.  Indeed, it would be
difficult to satisfy the extensibility requirements with rules that
are much different than the ones that are given in the draft -- many
of those rules are *derived* from the extensibility requirements.

Thus, the specific rules for alert URNs are intrinsic to the needed
semantics of the alert URNs.  Because of this, it is clearest and most
natural if the alert URNs are in a namespace of their own.

Dale

---

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

Apologies for the delay in responding to your messages.

> "urn:ietf:foo:bar", that would be rather unnatural.

That doesn't seem to be a problem.

The hierarchical structure of  urn:ietf  and urn:ietf:params
is very well suited to accommodate specific rules for branches
(and that is not uncommon for some other URN Namespaces as well).

I don't think you need to consider other URN Namespaces as a home
for salud identifiers:  You want IANA to maintain and manage that
namespace, and urn:ietf is just the proper, already established
framework for that; IMHO, it does not make sense to cause IANA
to host another URN Namespace whose purpose in fact is covered
already by the dedication of the urn:ietf:params branch.

> interoperation between different manufacturer's devices.

Agreed, so far.

But if you want/need URNs, that extension process needs to be managed
and guarantee the uniqueness and persistence of all assigned URNs.

> natural if the alert URNs are in a namespace of their own.

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]                     |
+------------------------+--------------------------------------------+