[salud] Changing the syntax of private extensions

worley@ariadne.com (Dale R. Worley) Thu, 12 June 2014 22:23 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53FB1A02A2 for <salud@ietfa.amsl.com>; Thu, 12 Jun 2014 15:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESfEtWedy600 for <salud@ietfa.amsl.com>; Thu, 12 Jun 2014 15:23:01 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id DC8281A0271 for <salud@ietf.org>; Thu, 12 Jun 2014 15:23:00 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id Da2i1o0021ap0As54aP03i; Thu, 12 Jun 2014 22:23:00 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id DaNz1o00v1KKtkw3iaP0l4; Thu, 12 Jun 2014 22:23:00 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5CMMx30020000; Thu, 12 Jun 2014 18:22:59 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5CMMx9k019999; Thu, 12 Jun 2014 18:22:59 -0400
Date: Thu, 12 Jun 2014 18:22:59 -0400
Message-Id: <201406122222.s5CMMx9k019999@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1402611780; bh=zwznsf5eHobZOTkO919QTwlCIKMvmJlkVo4RPxl3hy4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=b8NK23NNWU5ZTqWISfwI7FLlCktfmHb54+2gv60nlU+eAbzAPb4tZOs64tliguzkJ VunfIjvpnOVNDT3wZAflSY/7VLCWAyRM3Pgn7XSIE6a7rR2fJbwifn5rFwbGSj5E7+ X6paItkBjcrR0bmtnKIco0jXqr3AAf+KYEDzLqFQpLhud3Wgad5/YWQvFqQC/dxO85 Jo8cZvGjykXWBiooS3ua2ngL+CZVFx9hftn2EsCRTtt9reiprc10N453L8sIAmZyDu Oj0UVeEU6VtGAX3Ao+hRMLtPGF229YgkmBtVyNtqNwt+bUMw23K9Xu7SwANPJLaR4/ LCheOTiF5kKcg==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/eNzZnsKZ7bGXURVnvzrjlx5G-KQ
Subject: [salud] Changing the syntax of private extensions
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2014 22:23:02 -0000

[as an author]

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

      urn:alert:distinctive@a.example.com:long-long

"distinctive@a.example.com"; 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:

    classification@army.mil(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