IETF Logo Mail Archive

Re: Revision of RFC 7302

Pierre-Anthony Lemieux <pal@sandflow.com> Mon, 02 May 2016 20:11 UTC

Return-Path: <pal@sandflow.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 8CACC12D62D for <urn-nid@ietfa.amsl.com>; Mon, 2 May 2016 13:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandflow-com.20150623.gappssmtp.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 ZzNm521yfTy5 for <urn-nid@ietfa.amsl.com>; Mon, 2 May 2016 13:11:35 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 4AE6612D62C for <urn-nid@ietf.org>; Mon, 2 May 2016 13:11:35 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id u185so3346368iod.3 for <urn-nid@ietf.org>; Mon, 02 May 2016 13:11:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandflow-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3eYcIh+PMFfQ8dJ7J9KLgvhja0IjRz4LaIvXYj137Io=; b=qAyAwGIGcKWMWjqpHsOkIHQUaoVEhgVgM3bWph+PS/sLjfhEFj28BmwnNq8aLJBZmq N/GW1U5Djc/rlvs4gNblijkDHtwUAZ9Blt+XjuidBPYAelh+5ixArkJTToYOwwc9rP73 jw4O7zVS97o3vcmPJCNysqDG81IgH/3uX9dc+K77LJgGdi7ecE5bBfAfHYBSf+7ZwIz0 ayaznk8oeaRc6hdDJUUoyHXen59HTDg3ccsHj/4OHUdOqcwvJyI2lpJ6Tci3DbBuMiFY SyOKiuo3kFwaj7lAcfVJyAlZ5hLuf++xWtxNuejF2j4nX9s2Lltk8n1z4qfv8SBKQouT r0Uw==
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=3eYcIh+PMFfQ8dJ7J9KLgvhja0IjRz4LaIvXYj137Io=; b=R+fe0oaLEJRJP0fyCOTU91B9k5Y8rmg7TVTDUW4En66Tto5rLrv0TFhlKtQ7onyVBa 8tIMmQApEzMN+7zg9Km5JFKQu+yJflMKYwT+WijWRsPIxmAtbZHhVLl1qHDGYvRlCRTg YcauMTWfmb/UQUHIlg+866toMW72JUX5IS4uxaVJ2DvMvtlNv/iP0kALi6IcdcddlVjR VHlLuswHAKEDqKEm711tgZoVrVXKq+zWHEqosCvohecp8B5rlNVmjTViXpuATyhuHYIh mhGxl3kuVKn9CcCZEffm+/zNf63rvf94xygvBCETdvyJFNiQRC2SZmlCEbI7GSss9KTu z3aw==
X-Gm-Message-State: AOPr4FXMpW2oA+TBguWCH5BtlkbtttQkxnROG7z6VREpBIa6JUDBS0jZyi3UFWx1dEwWzw==
X-Received: by 10.107.173.158 with SMTP id m30mr15199282ioo.131.1462219894638; Mon, 02 May 2016 13:11:34 -0700 (PDT)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id 78sm228091iof.22.2016.05.02.13.11.33 for <urn-nid@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 May 2016 13:11:33 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id bi2so95924311igb.0 for <urn-nid@ietf.org>; Mon, 02 May 2016 13:11:33 -0700 (PDT)
X-Received: by 10.50.61.211 with SMTP id s19mr683366igr.86.1462219892963; Mon, 02 May 2016 13:11:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.39.148 with HTTP; Mon, 2 May 2016 13:11:13 -0700 (PDT)
In-Reply-To: <CA+9kkMD=ArH=Y+WxQ-SJ0m3Y3Ka-4pZQhtvifx5H9aAZUqv9XA@mail.gmail.com>
References: <CAF_7JxBSXo-EjC3-11Yop5W_Sgo4mWoPvb7SGxH90V9QVHPbUw@mail.gmail.com> <CA+9kkMD=ArH=Y+WxQ-SJ0m3Y3Ka-4pZQhtvifx5H9aAZUqv9XA@mail.gmail.com>
From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Mon, 02 May 2016 13:11:13 -0700
X-Gmail-Original-Message-ID: <CAF_7JxBO29RGMSwvniEqTiidOFguZ=FQU99GaYTgHvdoSjVqKQ@mail.gmail.com>
Message-ID: <CAF_7JxBO29RGMSwvniEqTiidOFguZ=FQU99GaYTgHvdoSjVqKQ@mail.gmail.com>
Subject: Re: Revision of RFC 7302
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/I6h_6iKmlBxxauvG4XDBUxx6Frs>
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:11:38 -0000

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?

[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?

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?

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)]
>>
>

v2.23.0 | Report a Bug | By Email