Subject: Re: [salud] draft-ietf-salud-alert-info-urns-06 : <private-name> issues; Concern #1

From: Laura Liess <[email-masked]>
Date: Wed, 6 Jun 2012 10:25:02 +0200

Alfred,

For Concern #1, I tried to follow your recommendation:
 >   Defer for <label> to the IDNAbis RFCs (cite RFC 5890) and use
>   the terms LDH-label and A-label as defined there.

So, I went through the definitions for the LDH-label and A-label and
U-label in RFC 5890 and I put together a revised text. Please let me
know your opinion and comments about the proposed text changes:

Old text (in Section 4):

"The alert-indications are hierarchical identifiers.  The set of
allowable characters is the same as that for domain names [RFC1123].
Labels are case-insensitive.  Comparisons MUST be case-insensitive.
Registered URNs SHOULD be transmitted as  registered.  A new name MUST
NOT be registered if it is equal by      case-insensitive comparison
to an already registered name."

New text:
"The alert-indications are hierarchical identifiers.  The set of
allowable characters is the same as that for domain names [RFC1123].
Labels used in <standard-name> MUST comply with the syntax for Non
Reserved LDH-labels [RFC5890].  Labels used in <private-name> MUST
comply with the syntax for Non Reserved LDH-labels or for A-labels
[RFC5890]. Comparisons MUST follow the comparison rules for the
corresponding type of label.  Registered URNs MUST be transmitted as
registered. A new name MUST NOT be registered if it is equal by the
comparison rules above to an already registered name."

Thanks a lot
Laura

2012/5/4 Alfred HÎnes <[email-masked]>:
> I've been asked to review draft-ietf-salud-alert-info-urns from
> a URN perspective.  To keep the message size shorter, I split my
> comments into parts by the major concerns I have with the I-D.
>
> My primary concerns regarding the chosen namespace are still
> in off-list exploration stage, and so I start in this message with
> the second topical area I found needing work: Alert URNs with
> <private-name> components and registration requirements.
>
>
> For easy reference, I quote the ABNF in Section 4 of the I-D:
>
> |          alert-URN       = "urn:alert:" alert-identifier
> |          alert-identifier= alert-category ":" alert-indication
> |          alert-category  = name
> |          alert-indication= name *(":" name)
> |          name = standard-name / private-name
> |          standard-name = label
> |          private-name = label "." label *[ "." label ]
> |          label = let-dig [ *let-dig-hyp let-dig ]
> |          let-dig-hyp     = let-dig / "-"
> |          let-dig         = ALPHA / DIGIT
> |          ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
> |          DIGIT           = %x30-39 ; 0-9
> |
> |     Throughout this document, "<private-name>" is used as a syntactic
> |     variable for any string conformant to the "private-name" ABNF
> |     above.
>
> Editorial note:
>  The ABNF Standard, RFC 5234, actually *recommends* to enclose
>  ABNF rule names in angle brackets ("<...>") when used in prose text.
>  So the trailing clause is very redundant -- it carries some allusion
>  of doing something extraordinary while actually the recommended
>  style is bening used.
>  This visual markup is even more important in cases where rule names
>  are words in common use, with a broader meanng.
>  So I strongly recommend making use of these provisions in RFC 5234
>  and in particular also use "<name>" and "<label>" throughout the
>  draft text.
>
> The semantical restrictions on <private-name> are spelled out later
> in Section 4 ...
>
> |     The alert-indications are hierarchical identifiers.  The set of
> |     allowable characters is the same as that for domain names
> |     [RFC1123].  Labels are case-insensitive.  Comparisons MUST be
> |     case-insensitive.  Registered URNs SHOULD be transmitted as
> |     registered.  A new name MUST NOT be registered if it is equal by
> |     case-insensitive comparison to an already registered name.
>
> .... and in Section 7.2 of the draft, which says (1st paragraph):
>
> |  The <private-name>" syntax is for proprietary extensions specific to
> |  independent organizations.  The "<private-name>" is used in the form
> |  of a "reverse FQDN" of the entity that defines the extension,
> |  possibly followed by further components.  Standard URNs will never
> |  contain a ".", so proprietary extensions need no further marker.
> |  This gives a way of assigning unique names without the need for a new
> |  registry.  The namespace for each alert category is independent.
> |  Those assigning new names must ensure they are in a position to
> |  assign names uniquely for the FQDN they choose.
>
>
> Concern #1 :
>
>   Defining syntax for domain name labels is a hornets' nest.
>   Each time someone tries to specify precise rules, there is a storm
>   of messages on the IETF main list.  Recently, even attempts started
>   in ICANN to update the specification of domain name syntax from
>   STD 13 and STD 3 has failed miserably.
>
> Recommendation:
>
>   Defer for <label> to the IDNAbis RFCs (cite RFC 5890) and use
>   the terms LDH-label and A-label as defined there.
>
> Editorial hint:
>   Formatting the ABNF with columnar alignment of all "=" elements
>   would improve the readability.  There's enough horizontal space
>   here to do that painlessly.
>
>
> Concern #2 :
>
>   URNs need to be stable and unique, cannot be de-registered,
>   and MUST NOT be re-assigned.
>   Bare (fully qualified) domain names do not have these properties;
>   domain names are only delegated under commercial rules and subject
>   to legal challenges and reassignment.  (I have myself once suffered
>   from loss of a domain name, and later gained the reassignment of a
>   domain name registered by a 3rd party that collided with a
>   registered trade mark owned by my company.)
>
> Recommendation:
>
>   Other protocols in similar circumstances have observed that
>   valid fully qualified domain names actually have a precisely
>   defined valid owner at each instant in time, and so escaped to
>   combining domain names for use in a persistent identifier system
>   with a mandatory time stamp.  Since domain name ownership changes
>   do not happen frequently and need significant time (due to
>   registration / authority propagation delays and the persistence
>   of cached DNS data until their TTL expires), it suffices to
>   provide such time stamps at date granularity, e.g. with the
>   semantics that the {FQDN,date} combination uniquely identifies
>   the owner of the FQDN at 00:00 UTC of the specified date
>
>   So if you want to retain the basic scheme, but make the assigned
>   identifiers actually suitable for URNs, the reversed domain
>   names should be followed by a date, for example:
>        com.example.foo-bar-products.2012-05-03
>   might become a valid <private-name> component for an Alert URN
>   to be registered.
>
>
> Concern #3 :
>
>   The 2nd paragraph of Section 7.2 contains two examples that
>   contradict the specification from the 1st paragraph (quoted above).
>
>                                   vvvv
> |   urn:alert:service:call-waiting:abc.org.example.somecompany  and
> |   urn:alert:service:call-waiting:def.org.example.somecompany [...]
>                                   ^^^^
>   The company-specific labels within a <private-name> must not
>   precede the reversed domain name.
>
> Recommendation:
>
>   Such <private-name> components could take the form of a subordinate
>   domain name label:
>                                                          vvvv
>    urn:alert:service:call-waiting:org.example.somecompany.abc
>
>   or be specified in a subordinate <name>, as already shown in the
>   draft:
>                                                          v
>    urn:alert:service:call-waiting:org.example.somecompany:abc
>
>
> 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.
>
>   At various places, the draft uses vague phrases like
>   the last paragraph of Section 7.1:
>
> |  The process for defining new Alert-Info URNs is described in
> !  Section 6.1.  Adding new categories and adding alert-indication
> !  values other than via the "private" mechanism described in
>          ^^^^^^^^^^
> !  Section 7.2 is standards action.
>               ^^^^^^^^^^^^^^^^^^^
>
>   ... and the last paragraph of Section 7.2:
>
> |  Adding new categories and adding alert-indication values via the
> |  "private" mechanism is not a standards action.
>                          ^^^^^^^^^^^^^^^^^^^^^^
>
>   Yet, Section 6.1 also doesn't give the specification needed:
>
> |  Alert URN identifiers are identified by labels managed by IANA,
> |  according to the processes outlined in [RFC5226] in a new registry
> |  called "Alert URN Labels".  Thus, creating a new Alert-Info URN
> |  identifier requires IANA action.  The policy for adding a new alert
> |  category is 'Standards Action'.  (This document defines the alert
> |  categories 'service', 'source', 'priority', 'duration', 'delay' and
> |  'locale'. ) The policy for assigning labels to alert-indications and
> !  the rules to combine them may differ for each alert-category and MUST
> !  be defined by the document describing the corresponding alert
> !  category.  [...]
>
>   So, fine for <alert-category>s, but not for <alert-indication>s:
>   none of the Sections 6.2.* contains such text.
>
> Recommendation:
>
>   Clearly specify which of the RFC 5226 registration policies shall
>   apply to Alert URNs with <private-name> component (or define a
>   custom IANA policy if you really feel the need to undergo such
>   pain).
>
>   Keep in mind that the persistence and uniqueness requirements
>   for URNs need to be satisfied, so maybe "Specification Required"
>   might be a candidate policy with minimal requirements.
>   Other possibilities would be "Expert Review" -- which includes
>   "Specification Required" but requires the IESG appointment of
>   designated expert(s) -- or "RFC required".
>   But in the former case, when the registration document is not
>   readily available at a permanent, stable URI, you would need to
>   require IANA to archive the registration document and link to that
>   'escrow' copy from the publicly available Alert URN registry on
>   the IANA web/ftp site -- but beware that past experience has shown
>   that IANA did not like such escrow requirements very much.
>
>   Either add _common_ text to section 6.1 that specifies the IANA
>   policy for <alert-indication> assignment in all <alert-category>s
>   specified in the draft, or actually do add such text to each
>   Section 6.2.*, as promised in the current text of Section 6.1.
>
>
> Concern #5 :
>
>   The rules in Section 8.1 are not properly thought out, especially
>   for the case of <private-name> components.
>
>   In particular, the draft specifies:
>
> !  The implementation is free to ignore any or all parts of the received
> !  Alert-Info URNs.  The exact way in which a UA renders a received
> |  combination of Alert-Info URNs is left as an implementation issue.
> |  However, the implementation MUST comply to following rules:
> |
> |     a.  Each alert-info URN has precedence over all URNs that follow
> |     it, and its interpretation is subordinate to all URNs that precede
> |     it.
> |
> |     b.  If the UA cannot implement the effect of a URN (because it
> |     does not recognize the URN or the URN's effect is precluded by
> !     preceding URNs), the UA repeatedly removes either
> !
> !        (1) the final name of the URN, or
> !
> !        (2) if the final name is a private-name with three or more
> !        labels, the final label
>
>   First, I strongly suspect that by removal of a component you
>   also mean removal of the separator character that precedes the
>   component being removed (a colon or period), but the draft does
>   not say so precisely, and the separator characters (by the ABNF)
>   are not part of the components being removed per these rules.
>
>   Second, under the rules presently in the draft, removing a <name>
>   is not guaranteed to lead to a valid (registered) Alert URN:
>
>   o  according to the ABNF in Section 4, the <alert-indication>
>      is not optional, so removal of the last remaining <name> of
>      an <alert-indication> (and the separator character ":")
>      would not yield a valid Alert URN;
>      (btw: the draft provides a "default" <alert-indication> per
>      <alert-category>, which is to be assumed if no Alert URN for
>      a particular <alert-category> is indicated, but that's not the
>      same as an "Alert URN" without an <alert-indication> component;)
>
>   o  as far as I understand, the draft does not require to register
>      'truncated' versions of hierarchically subdivided
>      <alert-indication>s -- for instance, it can be imagined that
>      for a particular <alert-category>, <alert-indication>s
>            abc:variant1 ,
>            abc:variant2 , and
>            abc:variant3
>      get registered, but bare
>            abc
>      is not registered as a valid <alert-indication>.
>
>   Examples:
>   -  s6.2.1 does _not_ define "service:recall" (without an additional
>      <name> to qualify "service:recall";
>   -  s6.2.6 intentionally does _not_ define "locale:country" (without
>      an additional <name> in the form of an ISO 3166-1 country code).
>
>   Similarly, there is no requirement in the draft that partially
>   truncated forms of "private" Alert URNs be registered and valid.
>
>   Third, regarding sub-rule (2) above: browser implementers are
>   struggling with dealing with recognizing "registry type" domains
>   for the purpose of defining sensical scope boundary rules for
>   HTTP state (cookies), but all these efforts are doomed due to the
>   creative forces at work in domain registries.
>   Attaching important semantics to the bare number of domain labels
>   in an FQDN does not make sense. This will become even more critical
>   with ICANN's new sponsored TLD program, where anybody (with enough
>   $$$) can start registering an own TLD and sell sub-domains -- or
>   use the TLD only company-internally. On the other hand, a URN
>   sub-namespace also cannot be made to depend on some volatile list
>   of "registry-like" domains in use on the Internet to distinguish
>   "cut points" beyond which no organizational affiliation can be
>   inferred.
>
>   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:
>       jp.pacific.world-company.example.com
>       kr.pacific.world-company.example.com
>       de.emea.world-company.example.com
>       it.emea.world-company.example.com
>       il.emea.world-company.example.com
>       eg.emea.world-company.example.com
>   without the need to have delegated the domains:
>       pacific.world-company.example.com
>       emea.world-company.example.com
>   from world-company.example.com -- any domain can contain
>   delegations at any level of subordiante labels they seem fit
>   to need.
>   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.
>
> Recommendations:
>
>   In concert with Concern #2 above, rule b.(2) does not make sense
>   any more.  I very strongly recommend to drop it entirely.
>
>   The other corner cases explained above need to be considered and
>   properly taken care of in the I-D.
>
>   Given the definition of the Alert URNs in Section 4, specific
>   semantics are only defined for actual, registers Alert URNs,
>   not for arbitrarily truncated Alert URNs.  Therefore, I believe
>   that the sentence,
>
> !  The implementation is free to ignore any or all parts of the received
> !  Alert-Info URNs.  [...]
>
>   should perhaps better say:
>
> !  The implementation is free to ignore any or all of the received
> !  Alert-Info URNs.  [...]
>
>   If by that revised rule, all Alert URNs for a particular
>   <alert-category> are dropped, according to other parts of the
>   draft, the recipient has to assume the "default" Alert URN for
>   that <alert-category>.  From my point of view, that would just
>   be fine and match the requirements.  This seems to be confirmed
>   by the additional text above item c. of the draft (not quoted
>   above).
>
>   So it eventually looks like the draft could easily drop the entire
>   component stripping rules in favor of dropping unknown Alert URNs
>   and letting the defaults step in.
>
>   Further, the text in Section 9 seems to indicate that the actual
>   intent is to always have a default for each 'dimension' (i.e.
>   category) of alert information.  If that's correct, it would
>   IMHO be wise to request (in s6.1) that any new registration of an
>   <alert-category> also specifies at least one <alert-information>
>   to be used with that category and designates one of these as the
>   default for that category.
>
>
> Finally, a few editorial nits:
>
> *  Please clean up dangling hyphens (with spurious space), e.g.:
>   "Alert -Info URNs" , "call- waiting:"
>         ^                    ^
>
> *  Please fix various typos (some of these recurring):
>   -  s/adidition/addition/
>   -  s/calback/callback/g
>   -  s/rinback/ringback/g
>   (and maybe you better use "ring/ringback" without a single
>   space on one side of the slash character)
>
> *  In the table in s6.2.3, the 3rd table column is partially
>   misaligned by one character position for the 1st table entry row.
>
> *  In s9, I doubt that "requirements in section 7" is the proper
>   pointer -- did you mean "... in section 2" ?
>
> *  In s 1.3, 1st para, s8.1, 3rd para, and s9.1, 5th para,
>   please use the precise terminology (as anywhere else in the memo):
>       s/Alert-Info header/Alert-Info header field/
>   Similarly, in the last line of item c. in s8.1, pleas adjust:
>       s/header "Priority: urgent"/header field "Priority: urgent"/
>
> *  In s9.2.2, in one instance white space is missing after a dash:
>       s/-internal high/- internal high/
>
> *  As a matter of taste: IMO the readability would be improved
>   if in Section 9.2.* the presentation were a bit more compact,
>   with less vertical white space.
>   For instance, you might consider dropping the single blank line
>   that precedes all item lines starting with "- "
>   (using the  <?rfc subcompact="yes"?>  PI and, where needed,
>   <vspace blankLines='1' /> in xml2rfc).
>   Ex.:
>
> |  Signal 4
> |
> |     Meaning: low
> |
> |     Locations:
> !     - source
> !     - priority:low
>
>
>
> Kind regards,
>  Alfred HÎnes.
>
> --
>
> +------------------------+--------------------------------------------+
> | 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]                     |
> +------------------------+--------------------------------------------+
>

---

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

> comparison rules above to an already registered name."

That seems to make sense, but the resolution of the other concerns
regarding  <private-name>s  might necessitate re-visiting this text
again.

Kind regards,
  Alfred.

--