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

[Sam Ruby <[e-mail]>]

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

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