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

[mike amundsen <[e-mail]>]

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.

changing shared specs to match one or more existing non-compliant
implementations is rarely the right approach.



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 2:00 PM, Sam Ruby <[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
>
> 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]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>