Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?)

[Larry Masinter <[e-mail]>]

On Thu, Jan 15, 2015 at 07:12:50AM -0500, Sam Ruby wrote:
> I proposed that the set of characters allowed in a fragment be
> changed to match the following:
> https://specs.webplatform.org/url/webspecs/develop/#url-code-points

My opinion:

What characters are allowed in 'a fragment' depends on the context. Fragment 
Of a "URI": My opinion: no, not a good idea, it would break ascii-only slots that now take URI only. 
Of an "IRI": Worth discussing, likely; need to review against 3987 and update where experience dictates.
                 Certainly IRI fragments can have non-ASCII characters, it's just second # and < > for example.
Of a "URL": Depends on what you mean:
-  If you mean the thing IETF now calls "IRI" was now (also) called a "URL", then see "IRI" above.
-   If you mean by "URL" some previous definition, like:
   *   "a URL is a URI that doesn't start with 'urn:'" or (alternatively)
   *  "a URL  is a URI that doesn't act like a URN".
    Then see "URI" above.

I think the nomenclature issue is the primary cause of people talking past each other or getting sarcastic.

One major change I had been trying to make in 3987bis was to change the processing model so that IRI -> URI mapping happened by parsing first, and then (only if reassembling into a URI) doing UTF-8-%xx-hex-encoding second on each of the (Unicode) parsed components. Would this possibly allow IDNA for mailto:nonascii@nonascii?subject=nonascii other slots?

> > When I did so, people freaked out, piled on, and generally made
> > points unrelated to what was actually proposed.  

This can happen when the same words are used with different meanings.

> > My takeaway: this mailing list is not a receptive place for people who identify specific problems and proposing specific updates.  

Your problems and updates might  not have been as specific as you thought.