[salud] Changing the syntax of private extensions

[[e-mail] (Dale R. Worley)]

[as an author]

draft-ietf-salud-alert-info-urns-12 constructs private extensions
using domain names.  For instance, in

      urn:alert:[e-mail]:long-long

"[e-mail]" is a <private-name> that is defined by the
owner of "a.example.com".  The full syntax of <private-name>s can
include a date:

    [e-mail](2013-03)

The IESG has criticized this scheme as being too complicated and as
involving the IETF in defining in detail the management of the right
to use particular domain name/date combinations in <private-name>s.
The IESG has proposed replacing this scheme with simple names that
would be registered by users in a first-come, first-served registry
managed by IANA.

The primary authors of the draft have been discussing this change.
Our current consensus on changing the draft is:

- Use a registry with a "First Come First Served" policy for
  <provider> values.  Per RFC 5226:

      First Come First Served - Assignments are made to anyone on a
            first come, first served basis.  There is no substantive
            review of the request, other than to ensure that it is
            well-formed and doesn't duplicate an existing assignment.
            However, requests must include a minimal amount of clerical
            information, such as a point of contact (including an email
            address) and a brief description of how the value will be
            used.  Additional information specific to the type of value
            requested may also need to be provided, as defined by the
            namespace.  For numbers, the exact value is generally
            assigned by IANA; with names, specific text strings can
            usually be requested.

            Examples: SASL mechanism names [RFC4422], LDAP Protocol
            Mechanisms, and LDAP Syntax [RFC4520].

- Use the syntax "provider = alert-label".  In particular, <provider>
  does not contain dots and thus can't be a complete domain name.
  This prevents registrants from choosing <provider>s that match
  domain names, disentangling <provider> from domain names.  The
  syntax becomes (with the changes marked):

         private-name      = alert-label "@" provider
    >>>  provider          = alert-label
         alert-label       = let-dig [ *let-dig-hyp let-dig ]
    >>>  [ Production <domain-label> is deleted. ]
         let-dig-hyp       = let-dig / "-"
         let-dig           = ALPHA / DIGIT

      [...]

      <alert-label>s MUST comply with the syntax for Non Reserved LDH-
      labels [RFC5890].  [deletion]
      Registered URNs and components thereof MUST be transmitted as
      registered (including case).

  That is, <providers> have the syntax of ordinary ASCII DNS labels.
  We expect that in practice organizations will select <provider>
  values that resemble the first component of their domain names.

- The right to define <private-name>s using a particular registered
  <provider> remains an intellectual property right, but because it is
  similar to many other such rights defined in RFCs, we do not need to
  document that.

- Trademark infringement questions can be left to the same legal
  mechanisms organizations now use to resolve trademark infringement
  questions regarding domain names and other identifiers, so we do not
  need to document that either.

Before we go to the work of writing the detailed textual changes, we
want to present this proposal to the working group to solicit your
comments.

Dale