Re: [apps-discuss] presumption that RFC3986 is correct

Sam Ruby <> Sat, 03 January 2015 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 745D51A9104 for <>; Sat, 3 Jan 2015 09:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8AysXZMaBrqX for <>; Sat, 3 Jan 2015 09:54:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 658E71A9100 for <>; Sat, 3 Jan 2015 09:54:14 -0800 (PST)
Received: from [] ([] helo=rubix) by cdptpa-oedge03 (envelope-from <>) (ecelerity r(Momo-dev:tip)) with ESMTP id 96/44-20729-5CC28A45; Sat, 03 Jan 2015 17:54:13 +0000
Received: from [] (unknown []) (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 3DB7B140035; Sat, 3 Jan 2015 12:54:13 -0500 (EST)
Message-ID: <>
Date: Sat, 03 Jan 2015 12:54:12 -0500
From: Sam Ruby <>
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 <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Cloudmark-Score: 0
Subject: Re: [apps-discuss] presumption that RFC3986 is correct
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jan 2015 17:54:16 -0000

On 01/03/2015 12:03 PM, Graham Klyne wrote:
> On 03/01/2015 13:09, Sam Ruby wrote:
>> 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.
> Presumption:  "An idea that is taken to be true on the basis of
> probability"
> --
> (Note: not "assumption".  I mean like "presumption of innocence")

If you wish to give me a language lesson, the please permit me to do 

Evidence: "the available body of facts or information indicating whether 
a belief or proposition is true or valid."

(Note: not "faith".  I mean like "scientific evidence")

> For precisely the reasons you state (i.e. it's been around and in use
> for a while, and it has been the primary reference source for
> implementers who care about standards) I don't think it's a big ask.
> But if you feel differently, then so be it.

It indeed has been around for a while.  As have a large number of 
implementations.  Many of which predate RFC 3986.

A large number of well-intentioned implementations do indeed give lip 
service to RFC 3986 compliance.  You may chose to accept those claims on 
face value.  As I have evidence to the contrary, sadly, I no longer do.

I intend to work with implementors, providing patches and/or new 
implementations along the way.  And I'll continue to document and 
publish findings.  One such place I have published such work is at the  W3C:

Meanwhile, I'm actively inquiring as to whether there are others who 
would be willing to help update RFC 3986 with me.  If that is not meant 
to be, so be it.

> #g
> --

- Sam Ruby