Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

S Moonesamy <sm+ietf@elandsys.com> Wed, 08 January 2020 01:30 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53160120077 for <art@ietfa.amsl.com>; Tue, 7 Jan 2020 17:30:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 T5qLz56TZ89B for <art@ietfa.amsl.com>; Tue, 7 Jan 2020 17:30:30 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E8120018 for <art@ietf.org>; Tue, 7 Jan 2020 17:30:30 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.59.4]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0081UG0T024080 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2020 17:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1578447029; x=1578533429; i=@elandsys.com; bh=rcabrE1w3f252YiU3n4nNMGe9z1/yK/gWYy0Tmynky8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k/Bu21b9IvRayp72RHk9b3Hy3Rk1EZ5yYxT5uklVBnt7jdk/emzSdIbqXuyq0AzOQ xb2Lr8eHJEKozTbbtjBQvIqu+YEeGxIufYUOMBXlENGnRYZeJMRznTeg5XzlS8rGFD oKN7uXjNwZtj9SqffVXl5kC9nX+n4B0wSrG8pNCc=
Message-Id: <6.2.5.6.2.20200107163256.0f2810b8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 07 Jan 2020 17:26:07 -0800
To: Adam Roach <adam@nostrum.com>, Mark Nottingham <mnot@mnot.net>
From: S Moonesamy <sm+ietf@elandsys.com>
Cc: art@ietf.org
In-Reply-To: <a267e8d7-e88f-fe84-a3d4-eb12b88a46ad@nostrum.com>
References: <87E116C31DAF1434C3C3937F@PSB> <a267e8d7-e88f-fe84-a3d4-eb12b88a46ad@nostrum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/ewPVbE5l_XskGR26qsb8qX6QfWM>
Subject: Re: [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 01:30:31 -0000

Hi Adam, Mark,
At 08:35 AM 07-01-2020, Adam Roach wrote:
>To help with framing this conversation, the changes from RFC 7320 
>are highlighted here:
>
>https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03
>
>I have some rather extensive thoughts on the process of creating bis 
>documents [1].

I was going to comment about the document as there was an 
announcement about it.  After reading your note I wondered whether it 
was worthwhile to comment if I have to restrict my comments to what 
was changed since RFC 7302.  For what it is worth, I have very little 
interest in getting into a lengthy discussion about URNs v/s URIs.

There are some design considerations in Section 1.2 of RFC 3986, 
which is an Internet Standard.  Section 2 of the draft states that 
the section is doing an update by "advising Specifications".  First 
of all, it is convoluted when an Internet Standard is being updated 
by a "BCP".  Secondly, it does not make sense to advise 
specifications as one generally provides advise to people instead of, 
for example, RFCs.

The example in Section 2.2 references RFC 1034 for the "authority 
component" whereas RFC 3986 references RFC 1034 and RFC 1123.   Is 
Section 3.2.2 of RFC 3986 being updated and replaced by what is in this draft?

Regards,
S. Moonesamy