Re: Revision of RFC 7302

Ted Hardie <ted.ietf@gmail.com> Mon, 02 May 2016 20:34 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6112D63F for <urn-nid@ietfa.amsl.com>; Mon, 2 May 2016 13:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3vq6LWx6o0jx for <urn-nid@ietfa.amsl.com>; Mon, 2 May 2016 13:34:42 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C49112D63C for <urn-nid@ietf.org>; Mon, 2 May 2016 13:34:41 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id x201so206057971oif.3 for <urn-nid@ietf.org>; Mon, 02 May 2016 13:34:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X2qIfwx7HvZQWc4Hzbnw0i/Lest82vtfEyx/7uo59uQ=; b=XbLHY1BPdPXbn1YLB5RWb5nm0LtpioxaQoxcy179H5NB/k+iY5Shnqa805LQSfvW7q kf0L1A+0v/xN8dYE8tQhMEuagPwwhSAhTW14UxmZyEsZRnOIdQmdPKge1tOHIySRuMGs reorWr2U2NoBfI/bQpTkNgS5HvTlv5Y+NHZTla8QNsOPNFf0XRs8EHgFlaHnyCHXW0bA 3ff3mga/TTSdo+CWYOlHhzQCPwDuXpDglDKWPeY+PsUcMl9EAtm/NkNbQ1rWjKSPcY7V DjVYMnO6fVLFz0HjpI1mumLDnwbmmrpa/a1zieEE9OQoSFrFuBWg+cJKNW2vNI05Kr55 QDyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X2qIfwx7HvZQWc4Hzbnw0i/Lest82vtfEyx/7uo59uQ=; b=P8ekguu/OZmx3rLq0HpjcivzMX+rWbcFkGu+6g09o3EDIK+sNhJCKyXDk1nWhGz1ZE dpzP/ghSOamxJEoIK9bYXS3YRCDZQgIygGPfmgSkZEcIVYkPGyTWkW6WRK5UxFKihri4 f6eBcl3OncJFsT6UvqHaDIpQTYOT61uNCqnOPJjLGNwBsHlbPrczGUtjydqlden3t1ST sObZSE6XMQaFuKQqTeS262/Ywte1hFoEEIVNX1gRiMTn2iE9fV06OAf0NR1fvVSG3KEr 2XC9pwWfXA9dgsaUHusZC+NKg0KoZadJJDYYykNaaFCT5gvhnqqhv3pwKFFVuRSkMDGE 4VKQ==
X-Gm-Message-State: AOPr4FU0KsrTmk2FOl06lrR/tTy458QCPqujpdiYHg8ij1bCWuuKeI8AnjQeRIoqtXqGKBORG3Tlv4tb1PE9wg==
X-Received: by 10.157.38.229 with SMTP id i34mr14898248otd.12.1462221280863; Mon, 02 May 2016 13:34:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.22.186 with HTTP; Mon, 2 May 2016 13:34:21 -0700 (PDT)
In-Reply-To: <CAF_7JxBO29RGMSwvniEqTiidOFguZ=FQU99GaYTgHvdoSjVqKQ@mail.gmail.com>
References: <CAF_7JxBSXo-EjC3-11Yop5W_Sgo4mWoPvb7SGxH90V9QVHPbUw@mail.gmail.com> <CA+9kkMD=ArH=Y+WxQ-SJ0m3Y3Ka-4pZQhtvifx5H9aAZUqv9XA@mail.gmail.com> <CAF_7JxBO29RGMSwvniEqTiidOFguZ=FQU99GaYTgHvdoSjVqKQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 02 May 2016 13:34:21 -0700
Message-ID: <CA+9kkMBCSp+PHnBOnu+Tim+DTK8j7vfNC1sXVTB2P_VxXqPhxw@mail.gmail.com>
Subject: Re: Revision of RFC 7302
To: Pierre-Anthony Lemieux <pal@sandflow.com>
Content-Type: multipart/alternative; boundary="001a11393f36076d290531e1ecc8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/GwtPfheDWjBiaWBN_iOtZCDCErc>
Cc: "urn-nid@ietf.org" <urn-nid@ietf.org>
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 20:34:46 -0000

On Mon, May 2, 2016 at 1:11 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Ted,
>
> I appreciate the quick review.
>
> > Looking through this, it appears that only the process for identifier
> resolution has changed.
>
> Yes.
>
> > Given that, a much shorter document updating RFC 7302 noting the change
> might be simpler.
>
> This would require the reader to consult two documents -- not sure
> this is fatal however.
>
> If the "updates" approach is chosen, would IANA [1] continue to
> reference RFC 7302, or would instead reference the updated RFC?
>
> It would reference them both; see the dvb entry for an example.


> [1] http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>
> > But given the general stability requirements for URNs, highlighting that
> the only
> > changes are to resolution might be useful.
>
> If the "obsolete" path is chosen, perhaps there is a way to explicitly
> highlight the (very limited) changes, beyond the short description in
> the abstract?
>
> You can include an appendix with a list of the changes.  That's
non-normative,
but it would likely be consulted by anyone who wanted to simply check on the
relationship between the two.


> IMHO it would be ideal to update RFC 7302 in place, since the changes
> do not impact identifier semantics, but this is not possible, right?
>
> That's correct; once issues, RFCs don't change in place.

regard,

Ted Hardie



> Best,
>
> -- Pierre
>
> On Mon, May 2, 2016 at 11:02 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> > Thanks for the pointer.  The RFC series allows a document to update a
> > previous document, as well as along one to obsolete a previous document.
> > Looking through this, it appears that only the process for identifier
> > resolution has changed.  Given that, a much shorter document updating RFC
> > 7302 noting the change might be simpler.
> >
> > Generally speaking this is a stylistic choice, and there is certainly no
> > requirement to take that path.  But given the general stability
> requirements
> > for URNs, highlighting that the only changes are to resolution might be
> > useful.
> >
> > regards,
> >
> > Ted Hardie
> >
> > On Sat, Apr 30, 2016 at 2:23 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Good morning/evening,
> >>
> >> Please find at the link below a proposed revision of RFC 7302. This
> >> revision adds support for confidential resolution of EIDR Identifiers
> >> using HTTP over TLS -- addressing a known limitation of RFC 7302.
> >>
> >> https://www.ietf.org/id/draft-pal-eidr-urn-2016-00.txt
> >>
> >> Very much looking forward to your comments and feedback. Let me know
> >> if you need additional information.
> >>
> >> Best,
> >>
> >> -- Pierre [on behalf of MovieLabs (http://movielabs.com)]
> >>
> >
>