Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986

Sean Leonard <dev+ietf@seantek.com> Tue, 31 May 2016 19:22 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6312D7E9 for <urn@ietfa.amsl.com>; Tue, 31 May 2016 12:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 ULSydwalPWfB for <urn@ietfa.amsl.com>; Tue, 31 May 2016 12:22:07 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E686312D7EE for <urn@ietf.org>; Tue, 31 May 2016 12:22:06 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA5ED509B6; Tue, 31 May 2016 15:22:05 -0400 (EDT)
To: Andrew Newton <andy@hxr.us>
References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com> <CAAQiQRfDdxFO8bKLDt4uP10GmQGim=inMxKgKh9kKo6SpdePcw@mail.gmail.com>
From: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <087583fc-0523-d28e-53ba-a864bc4a4c82@seantek.com>
Date: Tue, 31 May 2016 12:20:52 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CAAQiQRfDdxFO8bKLDt4uP10GmQGim=inMxKgKh9kKo6SpdePcw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/CWTs5H-DpFJ9tjf12mbxyeqfgbA>
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 19:22:08 -0000

On 5/31/2016 11:02 AM, Andrew Newton wrote:
> On Tue, May 31, 2016 at 4:32 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>> This is a thread about urnbis-semantics-clarif-03 in the context of updating
>> RFC 3986, as requested.
>>
>> draft-ietf-urnbis-semantics-clarif-03 originally started out as (John's)
>> polemic against using the URI framework ("syntax and high-level semantics of
>> URLs" -- see draft-ietf-urnbis-urns-are-not-uris-00 Section 1) for URNs.
>> That draft has a Section 3, which states:
> The definition of "polemic" is: a strong verbal or written attack on
> someone or something.
> The key words being "strong" and "attack" which connote discourse not
> becoming of the IETF. I believe this is a mischaracterization of both
> John and his work. Let's try to avoid such words in the future.

John has been doing good work and the work is appreciated.

When I wrote the term "polemic", it is because "Names are Not Locators 
and URNs are Not URIs" (the title, and the document, see, e.g., section 
1, draft-ietf-urnbis-urns-are-not-uris-00) *are* strong written attacks 
on something: namely, on the seemingly antagonistic relationship between 
URNs and URIs (specifically URN is attacking URI because it wants to 
secede from the URI country and set up its own republic of URN). There 
is nothing wrong in John's writing or in the characterization of it. Far 
from it--we need more strong opinions so we can clearly say "okay, we're 
going to go this way", or "no, we discussed it, we have decided we are 
not going to go that way".

>
>> That verbal formulation (including the typo...) has survived through the
>> drafts into Section 4 of draft-ietf-urnbis-semantics-clarif-03.
>>
>> Other stuff that purports to get updated: stuff about queries; stuff about
>> fragments; and...that's about it. Oh, it also says stuff about how RFC 3401
>> and RFC 2483 apply but don't apply and we aren't talking about them.
> The references to 2483 and 3401 are in regard to scope of the changes
> and seem completely appropriate.
>
>> ******
>>
>> Overall, the problems that need to be addressed are:
>>
>> draft-ietf-urnbis-semantics-clarif-03 doesn't actually *do anything*. I view
>> it as a lot of hot air...either that hot air gets into 2141bis, or blow it
>> away. I see nothing implementable here in Internet software or protocols.
> "hot air"... again, let's dial it down.

There is genuine frustration among implementers that this URN work has 
taken too long and is far too nebulous. Polemics etc. are fine for 
generating and stirring debate (the original urns-are-not-uris). But we 
seem to be continuing to have debates without resolutions...

What matters is that people write software that interoperates with other 
software. There is no grand theory of URIs or what have you, apart from 
the fact that two people write software a particular way that uses some 
sequence of characters to do similar things. Whether urn:isbn:1234 
identifies a book, pages in a book, some stream of bits, or abstract 
notions of fair play and substantial justice, *does not matter*, as long 
as we agree on them. URIs can do anything, or nothing, that we want them 
to as software engineers. Ditto for URNs.

Maybe this is a process issue. It's hard for me (and not to raise 
others' hands, but I think Julian is raising this point too) to see how 
RFC 3986 is getting updated, when RFC 3986 is not really getting 
updated, you're just creating a urn: string that only "partially" adopts 
RFC 3986 things. Maybe it's just better in rfc2141bis to say that URNs 
are syntactically URIs (whatever verbal formulation you want), and where 
they differ, to point out *in rfc2141bis* those specific differences. No 
"Updates: RFC3986" necessary in the header. And hopefully, the need for 
the clarif document will be obviated.

Regards,

Sean