[apps-discuss] presumption that RFC3986 is correct (was: New Version Notification for draft-kerwin-file-scheme-13.txt)

Sam Ruby <rubys@intertwingly.net> Sat, 03 January 2015 13:09 UTC

Return-Path: <rubys@intertwingly.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52A31A1A75 for <apps-discuss@ietfa.amsl.com>; Sat, 3 Jan 2015 05:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 81VUykK0kxhx for <apps-discuss@ietfa.amsl.com>; Sat, 3 Jan 2015 05:09:10 -0800 (PST)
Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id ECFD81A1A76 for <apps-discuss@ietf.org>; Sat, 3 Jan 2015 05:09:09 -0800 (PST)
Received: from [98.27.51.253] ([98.27.51.253:9868] helo=rubix) by cdptpa-oedge03 (envelope-from <rubys@intertwingly.net>) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C4/89-20729-5F9E7A45; Sat, 03 Jan 2015 13:09:09 +0000
Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 902CC140E10; Sat, 3 Jan 2015 08:09:08 -0500 (EST)
Message-ID: <54A7E9F4.80406@intertwingly.net>
Date: Sat, 03 Jan 2015 08:09:08 -0500
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Graham Klyne <gk@ninebynine.org>
References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <EAACE200D9B0224D94BF52CF2DD166A425A68A90@ex10mb6.qut.edu.au> <CACweHNBEYRFAuw9-vfeyd_wf703cvM3ykZoRMqAokRFYG_O7hQ@mail.gmail.com> <DM2PR0201MB09602B351692D424A49C6B0DC3650@DM2PR0201MB0960.namprd02.prod.outlook.com> <CACweHNBN_Bv=jeXQ_VwXi2HzHKNEwZJ1NiF-BJJo_9-mhO60gQ@mail.gmail.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org>
In-Reply-To: <54A7DC46.2020708@ninebynine.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RR-Connecting-IP: 107.14.168.142:25
X-Cloudmark-Score: 0
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dM9hcNG4Ft5zz6SjEIe6f5aAe_g
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] presumption that RFC3986 is correct (was: New Version Notification for draft-kerwin-file-scheme-13.txt)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jan 2015 13:09:13 -0000

On 01/03/2015 07:10 AM, Graham Klyne wrote:
>
> 3. Where there is divergence between implementations and RFC3986, these
> indeed should be considered on a case-by-case basis, but with (IMO) the
> presumption that RFC3986 is correct.  I.e. it is for those who think
> there is a problem with RFC3986 to make the case.

You ask me to presume that RFC 3986 is correct.  That's a big ask. 
Particularly given that there is no clear path provided for updating RFC 
3986.  For context, that's a decade old spec that I did not participate 
in the development of, and I have clear data that shows that popular 
parsing libraries -- client, sever, and everywhere in the middle -- 
don't implement.

>     You ask me to spend time with your data.  That's a big ask.  If some
> implementers think there is a problem with RFC 3986 then I think it is
> they who should be making the specific arguments about where RFC3986 is
> problematic.  I accept that UTS-46 host names is such an area,
> concerning which there should be a considered and focused debate (and
> about which I have insufficient knowledge to make a meaningful
> contribution).

I'm looking for people who are willing to look at data and work with 
implementors and document the result.  I am open to the possibility of 
some or all of that resulting documentation residing at the IETF.

I'll note that I neither created these test cases nor implemented any of 
the libraries (other than my reference implementation which is an 
attempt to track the evolving specification) in question.  I'm not going 
into this with any per-conceived notion as to who is right or who is 
wrong.  I am open to working with everybody, including people who 
believe that their preferred implementation or their preferred 
specification is right.

This is my starting point:

   https://url.spec.whatwg.org/interop/test-results/

Feedback on pretty much everything on those pages is what I am looking 
for.  Examples would be: tests that should be added, implementations 
that should be added, bugs in how I am interpreting the results, 
different ways to present the results, changes to one or more specs that 
should be made based on these results, and changes that should be made 
to implementations based on these results.

- Sam Ruby