Re: [apps-discuss] character repertoire for fragment identifiers

[Sam Ruby <[e-mail]>]

On 01/11/2015 04:41 PM, Julian Reschke wrote:
> On 2015-01-11 19:54, Sam Ruby wrote:
>> ...
>> At some point, I would like to discuss what characters should be allowed
>> in a fragment, and would like RFC 3986 either to match the set we come
>> up with, or for RFC 3986 to be obsoleted by a specification that does.
>>
>> I've been proceeding by testing actual implementations and actually
>> talking to at least two authors of RFC 3986.  And, trust me, I plan to
>> have conversations with the third author.
>>
>> Each time I try to have this discussion, you keep returning to what RFC
>> 3986 currently says as of this moment.
>> ...
>
> I keep returning to URIs as things consisting of ASCII code points.

Indeed you do.  :-(

> If you want to talk about URI-like identifiers that can contain
> non-ASCII characters, we'll need to discuss RFC *3987*. As far as I can
> recall, there's more or less agreement that this needs to happen, but
> that's IMHO a different conversation than the one about RFC 3986.

Let me compare what you suggest should happen with what Roy Fielding 
suggests should happen.  For whatever reason, Roy's post didn't make the 
web archive, but my reply did, so I will Roy quote from:

https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0088.html

 >>> The problem with RFC3987 was that it tried to define a new
 >>> addressing format instead of simply defining an arbitrary
 >>> reference and how to get from there to an interoperable URI. It
 >>> did not work because it wasn't written to handle arbitrary input
 >>> and could not keep up with changes in IDNA.

and

 > This does not mean there isn't value in coming up with a consistent
 > reference parsing model for HTML that reflects the browser
 > environment and results in a consistent URL DOM and address display.
 > It simply doesn't change what is in RFC3986, nor does it escape the
 > fact that a browser is still dependent on RFC3986 to produce a valid
 > URI out of whatever it happens to parse when it eventually chooses to
 > use that URI in an IETF protocol like HTTP.

I'd like to explore what Roy is suggesting: layering URLs on URIs, 
without going through a URL layered on IRI layered on URI approach. 
Doing so may require changes to both the definition of URLs and URIs.

In particular, I'd like to see how close we can come to a goal where the 
output of URL parsing followed by URL stringification is always a valid URI.

There is no question that a change to the "ASCII-ness" of schemes is 
clearly a non-starter.  But I would hope that we could discuss whether a 
change to the "ASCII-ness" of fragments is a possibility.  In 
particular, I don't believe that there is any reason why a URL parser 
(in a browser or elsewhere) needs to percent encode fragments.

It may come to pass that Roy is the only person who shares the goals 
that he described.  In which case, the end result will be an appendix to 
the URL standard which describes the real world use cases that RFC 3986 
does not address which prevent a proper layering.  Additionally, there 
would be a description of what the set of outputs from a URL 
parse/stringification process does produce, i.e., a description of what 
RFC 3986 should have said.

- Sam Ruby