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)] > >> > > >
- Revision of RFC 7302 Pierre-Anthony Lemieux
- Re: Revision of RFC 7302 Ted Hardie
- Re: Revision of RFC 7302 Pierre-Anthony Lemieux
- Re: Revision of RFC 7302 Ted Hardie
- Re: Revision of RFC 7302 Pierre-Anthony Lemieux
- Re: Revision of RFC 7302 Ted Hardie
- Re: Revision of RFC 7302 Paul Kyzivat
- Re: Revision of RFC 7302 Pierre-Anthony Lemieux