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

mike amundsen <mamund@yahoo.com> Sun, 18 January 2015 02:49 UTC

Return-Path: <mamund@yahoo.com>
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 D56CD1ACD97 for <apps-discuss@ietfa.amsl.com>; Sat, 17 Jan 2015 18:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level:
X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 q2pMDWe2vO9K for <apps-discuss@ietfa.amsl.com>; Sat, 17 Jan 2015 18:49:40 -0800 (PST)
Received: from nm14-vm6.bullet.mail.ne1.yahoo.com (nm14-vm6.bullet.mail.ne1.yahoo.com [98.138.91.107]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E601A9140 for <apps-discuss@ietf.org>; Sat, 17 Jan 2015 18:49:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421549379; bh=HAWUsAvQP6y5MqQslRfqhzuqISbCWj2OzD6Bikz0G5U=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=uBEbKQIO2ABe5jZVkhukBB8OeyqYw/LYB6vuxeEAEtQcSmXPepjFM/ZUhLISq3tPZYJJs2JjdAXaPNo+lhbzD5i8ONYPJicHYlu3RqsMjD+WZIFgfPz5FVS7t7m3QCccR2Y3iOzsNjOIybgVMvDVQLanT1DJlQOUsBkYQ+AeA3Y8X5TIU9tZdSx9vPehQdndh/m5zgsk5jjrjzSiV88hqCSnkZPMayEbtW8T0g9VqSdTHI9pFNEQqiX7PHp5utdi5Q0DljooCAA6HpKOYuLalJh9iPczrvkhJDVueXghbRftu+MZMmtX6RiLOSEoWeoGg5sFhSI5qUDGkPrWBdjTRQ==
Received: from [98.138.226.176] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2015 02:49:39 -0000
Received: from [98.138.226.127] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2015 02:49:39 -0000
Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 18 Jan 2015 02:49:39 -0000
X-Yahoo-Newman-Id: 748658.95798.bm@smtp206.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: pT9KVloVM1lH9o3ySUszjGyUCf9MXR3tzrElT2.DIpWvoiJ VIy7XB.YVblgOJlWV1CC6dP_w28cR_inw18XvLWacvJ7ay_J6m9CMeIvvMN3 cZRFsy4t.SwUzsDQ5Fzhrgnx5Tm4oFY9dP7cSW8nVhxx9xxMGt..ZcZm7N41 nrfc7SPvo8pHV339yZPs1wytdkGxnKx3jHnLlbLkAYDb6oZIVY93EOWl_A47 TijDtzpdNTJMpyc9xt.91srPR5OihmzDsj0Mh0u9d2EGNfw5inyhl_4MYLmA iM4wZJaeV98f.CuiREMPgZmluUQnvDeAezYQotqFM18DysYOrCCDhJ0eakuS SbTZGikrxKpM8xx53Q2tvG7C4lwUoIZ9Q2ykFZEcAZVIIHAeI8xbKakWlt4M DnJYX5LM63lnNCERMi8FdMgZvnrwS8pP1SzYmg3nRvusGMHfPHFb4feicBL6 JdQUHvud47zBWrP9HSMBrBYRDrRLo9hMZzlfRMCH8bbpWH0I.erUQmmHZQvc g0xNmyNd8MWCwEa4gACy9EtpZ5OKhE5O.q_NtI9uutANvFXUapo.ZpAkHlbB GsIoxOgvSIhQL605bdyFXZNJLkRi8NhV0gmI2hJ_3IutXE6ovyiqTtGvo0cz DvplJr4VDm6WmleI1nJcCZZoMexDBHwQK44WOhH.Vi84rZjGltmVNW_BAJf1 TjUG8B8qO0wpXy_i40xGiQyFK6RA5GOtxVSluqnjT33bYVc940BoZCcQzQSM 73.wzE_uA.csi
X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA--
Received: by mail-lb0-f175.google.com with SMTP id z11so23633763lbi.6 for <apps-discuss@ietf.org>; Sat, 17 Jan 2015 18:49:37 -0800 (PST)
X-Gm-Message-State: ALoCoQljtXDQQkWQ4jZZ9ZvNpY7TsZVzcwoaCUQWkSWOUlOomqJXq8xf2Fqj4mdMfnob8xPsAYBV
X-Received: by 10.152.228.164 with SMTP id sj4mr22182001lac.98.1421549377471; Sat, 17 Jan 2015 18:49:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.166.203 with HTTP; Sat, 17 Jan 2015 18:49:16 -0800 (PST)
In-Reply-To: <54BAC447.7030706@intertwingly.net>
References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <CAKHUCzz=jZAF-i2_pwGpkER5vNhv95CMwdBCMwigPJ0FA_t4_A@mail.gmail.com> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <f5boaq0gdw5.fsf@troutbeck.inf.ed.ac.uk> <54B806A2.8020803@intertwingly.net> <CAKHUCzzN4Eu6R_f2Sf8EtiAp-8w3ds5Yp3-PBHK+B0wGRxEtmw@mail.gmail.com> <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> <CAPW_8m6ju6QFmp_pvby72KXYAyOCOVOvhbf9VfP384=5QKFwUA@mail.gmail.com> <54BAC447.7030706@intertwingly.net>
From: mike amundsen <mamund@yahoo.com>
Date: Sat, 17 Jan 2015 21:49:16 -0500
Message-ID: <CAPW_8m6zcEV_o-Sa01C_4WD9o56eYDtaZe0C_AK6mt+LgQ6oAA@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Content-Type: multipart/alternative; boundary="001a11343716acdf3f050ce44191"
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/itEkZDfeTqbfopfoukRFzLNn3cg>
Cc: Graham Klyne <gk@ninebynine.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI?
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: Sun, 18 Jan 2015 02:49:43 -0000

<snip>
Either that term is meaningless, or I have yet to find one.
</snip>

i can only wonder...

first, these are not the only options and are not mutually exclusive.

second, the phrase "spec-compliant implementation" *is* meaningful however,
i suspect you're trying to say something else, as in "I challenge anyone to
find a single 3986-compliant implementation anywhere, ever" or something
along those lines.

finally, asserting that there exist no compliant implementations (seems
we're in Russell's teapot territory here) still does not give license to
introduce backward-incompatible changes to the spec.

again, if you are focused on *documenting* existing practices, this is all
much-needed and non-controversial work.



mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

On Sat, Jan 17, 2015 at 3:21 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 01/17/2015 02:58 PM, mike amundsen wrote:
>
>> Sam:
>>
>> i might be missing some key points but..
>>
>> <snip>
>> What is effectively being said is that documenting how things actually
>> work will break things, which is clearly untrue.
>> </snip>
>>
>> let's not confuse "changing the specification" with "documenting."
>>   documenting NEVER breaks things. changing a specification MAY break
>> things.
>>
>> if all this is about is writing *documentation*, have at it. if you want
>> to write some BCPs, no worries.
>>
>> but if the work involves changing specifications, as long as those
>> changes are made in ways that do not break existing *spec-compliant*
>> implementations, i have no problem with the work.
>>
>
> I have trouble with the words "existing *spec-compliant* implementations".
>
> Either that term is meaningless, or I have yet to find one.
>
> 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.
>
> I've taken a look at a lot of libraries that produce and consume URIs
> (some call them URLs, but lets not worry about that for the moment).  I
> have yet to find one that is spec compliant.
>
>  changing shared specs to match one or more existing non-compliant
>> implementations is rarely the right approach.
>>
>
> There are a large and growing number of non-RFC 3986 compliant
> applications today.
>
> I am working with a small and growing number of developers of these
> libraries.  I am building a shared specification to which these
> applications will be compliant.  When done I will have a large list of
> compliant applications that I can point to.
>
> I would like to see that there be an update to RFC 3986 so that I can
> build upon that as a base.  But that's merely a desire, not a blocker.
>
>  mamund
>> +1.859.757.1449
>> skype: mca.amundsen
>> http://amundsen.com/blog/
>> http://twitter.com/mamund
>> https://github.com/mamund
>> http://linkedin.com/in/mamund
>>
>
> - Sam Ruby
>
>  On Sat, Jan 17, 2015 at 2:00 PM, Sam Ruby <rubys@intertwingly.net
>> <mailto:rubys@intertwingly.net>> wrote:
>>
>>     On 01/17/2015 10:25 AM, Graham Klyne wrote:
>>
>>         On 16/01/2015 16:41, Sam Ruby wrote:
>>
>>             As to what the breakage it, that is less clear to me.  There
>>             are existing
>>             parsers that don't percent encode square brackets when they
>>             occur at
>>             some point
>>             after a question mark is encountered in the input. Perhaps
>> those
>>             parsers lose
>>             the ability to claim that they are "RFC 3986 compliant".
>>
>>
>>         Surely, it's not the role of a *parser* to %-encode, but a
>>         *generator*
>>         of URIs?
>>
>>         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.  Of course, parsers may do more than this, but the
>>         detail of
>>         such behaviour is not specified by RFC3986.
>>
>>         (I would say that a *generator* of URIs that does not %-encode
>>         square
>>         brackets in fragments is not RFC3986 compliant.)
>>
>>
>>     As many people have pointed out, nomenclature seems to be a big
>>     problem here.  I started to write a reply that spells this out, but
>>     I realized that I was repeating things that I've said before, and
>>     figured it made sense to pull it out into a separate blog post that
>>     I can point to:
>>
>>     http://intertwingly.net/blog/__2015/01/17/RFC-3986bis
>>     <http://intertwingly.net/blog/2015/01/17/RFC-3986bis>
>>
>>     TL;DR: URL parsers consume URLs and generate URIs.  Such URIs are
>>     not RFC 3986 complaint.  I’d like to fix that.
>>
>>         #g
>>         --
>>
>>
>>     - Sam Ruby
>>
>>     _________________________________________________
>>     apps-discuss mailing list
>>     apps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
>>     https://www.ietf.org/mailman/__listinfo/apps-discuss
>>     <https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>>
>>