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

[Sam Ruby <[e-mail]>]

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>
>
>