Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI?

Larry Masinter <> Sun, 18 January 2015 21:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 566261ACE16 for <>; Sun, 18 Jan 2015 13:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qW7acBQv8duo for <>; Sun, 18 Jan 2015 13:09:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94A7D1ACD13 for <>; Sun, 18 Jan 2015 13:09:35 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sun, 18 Jan 2015 21:09:33 +0000
Received: from ([]) by ([]) with mapi id 15.01.0053.000; Sun, 18 Jan 2015 21:09:33 +0000
From: Larry Masinter <>
To: Sam Ruby <>
Thread-Topic: [apps-discuss] Scope of RFC3986 and successor - what is a URI?
Date: Sun, 18 Jan 2015 21:09:32 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2601:9:8380:992:ec21:132e:caaf:6bd0]
authentication-results: spf=none (sender IP is );
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0201MB0959;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0959;
x-forefront-prvs: 046060344D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(74316001)(105586002)(86362001)(99286002)(76176999)(62966003)(50986999)(54356999)(77156002)(15975445007)(97736003)(33656002)(102836002)(64706001)(2950100001)(68736005)(46102003)(54206007)(19580395003)(110136001)(93886004)(106356001)(92566002)(122556002)(40100003)(76576001)(2656002)(106116001)(101416001)(87936001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0959;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2015 21:09:32.8629 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0959
Archived-At: <>
Cc: "" <>
Subject: Re: [apps-discuss] 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: Sun, 18 Jan 2015 21:09:39 -0000

>         The primary role of a URI parser is to simply decide if a given
>         string is or is not a valid URI.  A parser can only be
>         RFC3986-compliant in the extent to which it correctly makes 
>         this determination in accordance with RFC3986.

I disagree with both these sentences, at least as I understand the
terms "primary role", "parser", "valid", "compliant".

The primary role of a parser
is to take input data and give a structural representation of the input,
while checking for correct syntax in the process.

Deciding validity is the role of a

RFC 3986 mainly defines conformance for URIs, and I don't
find any 2119-MUST/MAY/SHOULD for parsers, so 
any parser that accepts valid-per-3986 URI input and parses
it successfully could be "conforming",  even if also accepts invalid

> LDAP schemas that make use of IA5String can be said to be spec compliant 
> in that they accept all RFC 3986 compliant URIs.  But that's quite a 
> different matter than saying that they implement RFC 3986 in any 
> meaningful way.
Pass-through applications that embed URIs, and implementations
that only do minimal validation (but don't reject all invalid input)
should be counted as meaningful use cases and implementations
when considering whether changes are compatible.

RFC 3986 is an Internet Standard, see "Revising a Standard" 
Changes would be best accomplished by making a new
standard rather than update the old, unless it's clear
that the overwhelming majority of the installed base
wouldn't be affected.  I don't think your examples
meet that criterion. 
It's possible that other updates to 3986 might. We
should discuss:

* Changes that make previously invalid strings valid URIs
 (e.g., allowing additional reserved ASCII characters like #
and <>  in the fragment?)

* Changes that make previously valid strings invalid
 (e.g., disallowing as a host?) 

* Changes that affect how the structure of URI strings
  are described, the output of parsing. These might be
 OK but so many other specs make normative
  reference into 3986 that it's worthwhile being cautious.

Updating or replacing 3987 I_IRI to align with W_URLWW
is a different story because it's a different status.