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

Sam Ruby <> Sat, 03 January 2015 20:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB82F1A0263 for <>; Sat, 3 Jan 2015 12:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vNNsgqeNg7jV for <>; Sat, 3 Jan 2015 12:46:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E2111A024C for <>; Sat, 3 Jan 2015 12:46:05 -0800 (PST)
Received: from [] ([] helo=rubix) by cdptpa-oedge02 (envelope-from <>) (ecelerity r(Momo-dev:tip)) with ESMTP id 27/00-08196-B0558A45; Sat, 03 Jan 2015 20:46:04 +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 0E971140128; Sat, 3 Jan 2015 15:46:03 -0500 (EST)
Message-ID: <>
Date: Sat, 03 Jan 2015 15:46:02 -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: Stephen Farrell <>
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 20:46:07 -0000

On 01/03/2015 01:56 PM, Stephen Farrell wrote:
> Hi Sam,
> On 03/01/15 17:54, Sam Ruby wrote:
>> 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:
> I have at least one question about how you (or W3C, or any of us)
> plan to head towards some reasonable level of completeness with
> that work. (This may be a bit of an aside in the current discussion,
> or maybe not, I'm not sure.)
> The draft at the URL above includes [1], which is a risibly small
> and fixed (?) subset of an IANA registry. [2] What's the plan for
> making that sensible? I would assume pointing at the IANA registry
> is the simple and obvious fix there, but am puzzled as to why that
> hasn't been done in the few years this text has been around.
> Is that just an oversight? Or is your work really only covering
> exactly that particular subset of schemes? Or something else?

This is a valid question, and the subject of an open bug:

So the short answer is: it is a known issue, and suggestions are welcome.

The longer answer isn't all that much longer.  Given that every modern 
programming language (and for that matter, every browser) will have a 
part of their runtime library a concept of either a URI or a URL, and a 
method to parse a string into such a structure, the question you pose is 
equivalent to: "how should URI.parse methods handle unknown schemes"?

Possible answers include: treat the content as hierarchical, and treat 
the content as opaque.  There may be other answers.

What there probably needs to be is a sane default, and a way to register 
new schemes.  At the moment, the URL Working Draft treats unknown 
schemes as opaque.  The bug suggests that hierarchical might be a better 

As to registration, at the moment that is undefined.  The spec literally 
says "..." at this point:

The hope is to work together with the authors of the following 

This is mentioned in bullet 3 of the following section:

Meanwhile, patches are welcome!  It may be that there are certain URI 
schemes that defy conventional classification (file: certainly comes to 
mind, there may be others) that need to be specified explicitly in the 

The easiest way to participate is to propose tests in the form of input 
strings, base strings, and expected results.  That data will be added to:

And I'll use that data to update:

Should you feel inclined to suggest changes to the URL spec, I'd 
encourage you to look at the following which contains an incomplete but 
significantly reworked parser:

That repository has a bunch of other things, including the evaluation 
scripts and a reference implementation.  More information can be found here:

> Thanks,
> S.

- Sam Ruby

> [1]
> [2]