Subject: [salud] A number of related questions from Alfred Hoenes

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 6 Jun 2012 16:48:53 -0400

[as an individual]

This message is to discuss a number of design points related to a
number of Alfred's concerns.  I fear that the design concepts are not
explained plainly in the draft, leading to some confusion.

> From: Afred Hoenes

> Concern #4 :
>
>   The registration rules for <alert-identifier>s, in particular for
>   Alert URNs containing a <private-name> component, are not
>   specified clearly and unambiguously in the draft.

URNs containing <private-name>s aren't to be registered at all, as
their purpose is to provide a sufficient variety of URNs for private
use, rather than to interoperate between different vendors'
implementations.

> Concern #5 :
> [...]
>   Second, under the rules presently in the draft, removing a <name>
>   is not guaranteed to lead to a valid (registered) Alert URN:
> [...]
>   Similarly, there is no requirement in the draft that partially
>   truncated forms of "private" Alert URNs be registered and valid.
> [...]
>   Further, in the DNS, there can be "empty non-terminals" :
>   similarly as shown above for <alert-indication>s, in the DNS,
>   subordinate domains/zones can be registered without the need to
>   also register/populate "intermediate" domains -- for instance
>   there might be the following, regularly delegated domains:
>   [...]
>   So by removing the "least significant" domain label, you might
>   arrive at a domain name without an owner, which could not be
>   used to construct a valid Alert URN for registration.

In various cases, a URN can be truncated by the processes in section
8.1, and there is no assurance that the resulting URN is registered
(if it contains no <private-name>), the <private-name> is a legitimate
domain name, the private URN is meaningful under its interpretation by
the owning organization, or even syntactically correct.

However, in all of these cases, the resulting URN cannot be
"recognized" by the implementation, and the resulting URN must be
reduced again, that is, the loop must be executed again.  Eventually
the URN must be reduced to a point where:  if all the
<alert-indication>s are removed, the exit condition (ii) is activated;
otherwise, the URN is eventually reduced to a form that "is recognized
and can be given effect".

(From the nature of your concerns, you may have overlooked the word
"repeatedly" in "the UA repeatedly removes" in item (b).)

> Concern #5 :
> [...]
>   Attaching important semantics to the bare number of domain labels
>   in an FQDN does not make sense.

That is generally true, but it is not true in this particular use.
The rule here is stated as "if the final name is a private-name with
three or more labels", but the more meaningful interpretation is, "if
removing the final label would leave two or more labels".  The reason
for this rule is that <private-name>s are distinguished syntactically
from <standard-name>s by the presence of ".", and thus removing the
last label from a name with two labels would transform a
<private-name> into a <standard-name>.

In all other instances, the only "risk" is creating a <private-name>
that does not correspond to an organization's domain name.  But as
discussed above, such a <private-name> will (after a number of
iterations) be removed from the URN, and the remainder of the URN is
examined again.

The limitation this scheme imposes is that a legitimate domain that
has only one label cannot be used to create a <private-name>, but that
is extremely unlikely to happen.  (However, I have talked to a fellow
whose e-mail address was <[name]@se> for a while.)  Such an
organization would have to add a dummy second label to create a
<private-name>.

Dale

---

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

At Jun 06, 2012, Dale Worly wrote:

> number of Alfred's concerns.  I fear that the design concepts are
> not explained plainly in the draft, leading to some confusion.

That indeed is an indication that the draft should be clarified.

> use, rather than to interoperate between different vendors'

Ouch!  That seems to be in direct conflict with the basic requirements
for URNs as spelled out in RFC 1737: global scope, global uniqueness,
and persistence.

If you really want unregistered private identifiers (without
delegation of responsibility for the sub-namespace from IANA to the
(current) domain name owner, you might better seek for another kind
of namespace, for instance a URI scheme.

> "repeatedly" in "the UA repeatedly removes" in item (b).)

I haven't.  But the algorithm calls for certain tests at each stage,
and without a registry and resolution process covering all assigned
'alert' NSS values, I don't see how that can be done as written in
the draft.

> organization would have to add a dummy second label to create a

So it at least remains to be clarified how IANA (which you want to
task with the management of the namespace) can point to the sub-
registries delegated to private branches.

E.g.  is   com.example.somecompany.fc3
the authority for assigning subordinate "private" identifiers
of is that an identifier assigned by  com.example.somecompany ?
If there isn't hierarchical sub-delegation at each label boundary,
how can the sub-registry be located?

And if "somecompany" stops operating some day and some other
company becomes the owner of the domain name and also wants to start
assigning 'alert' identifiers, how will the distinction between
legacy and new ones be managed?
Will the former com.example.somecompany 'alert' identifier sub-
registry be re-parented to IANA , e.g. to persistently ensure
identifier uniqueness?

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