Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?)

Graham Klyne <> Mon, 19 January 2015 14:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D94371B2A93 for <>; Mon, 19 Jan 2015 06:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TE0OmcsoMSrW for <>; Mon, 19 Jan 2015 06:35:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D7C5E1B2A8B for <>; Mon, 19 Jan 2015 06:35:58 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YDDQq-0006KG-hJ; Mon, 19 Jan 2015 14:35:56 +0000
Received: from ([] by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1YDDQq-0004Hh-Gk; Mon, 19 Jan 2015 14:35:56 +0000
Message-ID: <>
Date: Mon, 19 Jan 2015 14:35:57 +0000
From: Graham Klyne <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sam Ruby <>, Nico Williams <>
References: <> <> <> <> <012001d02d91$6ec42300$> <> <018e01d02dc6$1d03b0a0$> <> <> <> <20150116033032.GD2350@localhost> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <>
Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?)
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: Mon, 19 Jan 2015 14:36:01 -0000

On 16/01/2015 11:12, Sam Ruby wrote:
>> I don't see a need for controversy if no breaking changes are proposed.
>> If some proposed changes are breaking, we can discuss their impact and
>> possibly accept them, but there will be controversy.
>> A change that would break things on paper might not, of course, and can
>> be considered even if it did, but it would be controversial even if it
>> turned out that the change would not be breaking in actual deployments.
> Thank you, thank you, thank you for putting this so clearly!  I do believe that
> "break things on paper" is necessary given my data that valid URIs are a merely
> a Platonic ideal.  I do believe that "breaking in actual deployments" should be
> avoided.

I've been mulling this comment, as I think it goes to the heart of the debate. 
In particular, I wholly agree that "breaking in actual deployments should be 
avoided" is the crux.

The main point I want to make is that in considering actual deployments, the URI 
analyzers built into web application frameworks (such as ruby/rails, Django, 
Tomcat, Node, etc.) are an important part of the deployment landscape.  I hazard 
that these may be likely areas of breakage if incompatible changes are made to 
the URI spec as defined by RFC3986.  (If we lived in a world where all Web 
applications were built and designed along REST principles, including HATEOAS, 
then this would not be the case, but we are a long way from that, even among 
applications that claim to be RESTful.)

A second, lesser point is that while there are many parsers that are lax in what 
they accept, as shown by your data, they do not of themselves cause breakage by 
virtue of being lax.