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

[Larry Masinter <[e-mail]>]

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

I disagree with both these sentences, at least as I understand the
terms "primary role", "parser", "valid", "compliant".

The primary role of a parser http://en.wikipedia.org/wiki/Parsing#Parser
is to take input data and give a structural representation of the input,
while checking for correct syntax in the process.

Deciding validity is the role of a http://en.wikipedia.org/wiki/Validator.

RFC 3986 mainly defines conformance for URIs, and I don't
find any 2119-MUST/MAY/SHOULD for parsers, so 
any parser that accepts valid-per-3986 URI input and parses
it successfully could be "conforming",  even if also accepts invalid
input. 



> 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.
 
Pass-through applications that embed URIs, and implementations
that only do minimal validation (but don't reject all invalid input)
should be counted as meaningful use cases and implementations
when considering whether changes are compatible.

RFC 3986 is an Internet Standard, see "Revising a Standard"
https://tools.ietf.org/html/rfc2026#section-6.3 
 
Changes would be best accomplished by making a new
standard rather than update the old, unless it's clear
that the overwhelming majority of the installed base
wouldn't be affected.  I don't think your examples
meet that criterion. 
It's possible that other updates to 3986 might. We
should discuss:

* Changes that make previously invalid strings valid URIs
 (e.g., allowing additional reserved ASCII characters like #
and <>  in the fragment?)

* Changes that make previously valid strings invalid
 (e.g., disallowing 258.258.258.258 as a host?) 

* Changes that affect how the structure of URI strings
  are described, the output of parsing. These might be
 OK but so many other specs make normative
  reference into 3986 that it's worthwhile being cautious.

Updating or replacing 3987 I_IRI to align with W_URLWW
is a different story because it's a different status.

Larry
--
http://larry.masinter.net