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

[mike amundsen <[e-mail]>]

<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 <[e-mail]> 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 <[e-mail]
>> <mailto:[e-mail]>> 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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/__listinfo/apps-discuss
>>     <https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>>
>>