Re: [pkix] [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

[Sean Leonard <[e-mail]>]

[Adding pkix@]
On the two intertwined points:

On 1/11/2015 8:28 AM, Julian Reschke wrote:
> On 2015-01-11 17:19, Sam Ruby wrote:
>> ...
>>> Now suffering from information overflow.
>>>
>>> We were discussing RFC 3986. Which *ASCII* characters that are 
>>> currently
>>> forbidden in fragment identifiers do you want to allow?
>>
>> We seem to be in a loop.
>>
>> To you, RFC 3986 (including potential errata and/or bis work) implies
>> ASCII.
>>
>> I point out that that restriction does not seem to make sense for
>> fragments.
>
> Actually, you did not. Instead you pointed to lots of material 
> somewhere else that I didn't want to parse just to find out what 
> you're proposing.
>
>> You return back to asking about ASCII.
>
> Because that's what RFC 3986 is concerned with.
>
>> To help break this loop, permit me to turn this question around.
>> Restricting the scope of the conversation to fragments, why do you
>> believe it makes sense to limit such to ASCII only?  What problems do
>> non-ASCII characters in fragments cause?
>
> I fail to see how fragments are special here compared to, say, the path.
>
> I fully agree that work on what we used to call IRIs is something that 
> needs to be done. However right now I'm trying to figure out what's 
> wrong with RFC *3986*.
>
> I hear you saying that URIs should allow non-ASCII characters in 
> certain places. This may break code where these characters are put on 
> the wire (such as HTTP) or stored in places that do not allow 
> non-ASCII characters (say, a database column).
>
> The fact that it's hard to extend the URI character repertoire beyond 
> ASCII is why the IETF attempted to do it in a separate spec/construct. 
> I'm not convinced that the situation has changed sufficiently to 
> invalidate that approach.
On 1/11/2015 8:45 AM, Sam Ruby wrote:
> On 01/11/2015 11:29 AM, Julian Reschke wrote:
>> On 2015-01-11 17:25, Mark Nottingham wrote:
>>> I and others have brought that up. What’s interesting is that they say
>>> it’s reasonably interoperable with deployed implementations.
>>>
>>> Cheers,
>>> ...
>>
>> Let me guess: "deployed implementations" == "what current browsers do".
>
> Your sarcasm is not appreciated.
>
> I encourage you to actually look at test results:
>
> https://url.spec.whatwg.org/interop/test-results/7b83ef3682

***

I fully agree with Julian on the matter of US-ASCII for URIs. URIs (RFC 
3986) are only made of US-ASCII characters.

If someone wishes to extend URIs (as opposed to IRIs or whatever) to 
include non-US-ASCII characters, that's a problem for web browsers and 
all other Internet software alike. This goes exactly to my point about 
protocol slots.

Certificates, CRLs, and other security objects are just as fundamentally 
a part of the Web (and web browser) infrastructure as HTML. In 
X.509/PKIX security objects, the GeneralName uniformResourceIdentifier 
construct is US-ASCII only (IA5String). If you extend "URIs" to be 
beyond US-ASCII, RFC 5280 has to be updated...and all the security 
libraries that depend upon it. Just because HTML(5) can be served as 
UTF-8 or use & encoding or whatever, doesn't make the problem go away.

Does the URL Interop test-results explicitly test for certificates? I 
suggest attempting to put some non-US-ASCII characters in a GeneralName 
protocol slot (say, for revocation) and see what happens.

HTML 4.01 is at least consistent in saying (for its time) that hrefs and 
other things are URIs. For interoperable behavior, use US-ASCII 
characters only and stick with % encoding.

The security angle brings up another problem: the interoperable 
transcription of URIs across systems. The ASCII range is a limited 
repertoire, so it is easy to write it out unambiguously on paper, 
display it on a TV screen, say it over the radio or a public service 
announcement, or memorize it on your smartphone, in order to type it 
into your web browser, the command-line, or any other system of choice.

If you allow the enormous (and ever-expanding) range of Unicode 
characters in "URIs", all of those use cases become fundamentally 
ambiguous, inviting homograph attacks. Which smiley face out of nearly a 
hundred smiley emoji do you mean when you say "http://foo.com/😋" ?? How 
about an URI containing "ῗ" (U+1FD7 GREEK SMALL LETTER IOTA WITH 
DIALYTIKA AND PERISPOMENI)--what composition or decomposition mode? What 
if the combining accent mark code points are in a different order?

***
I have empathy for what Sam/the W3C wants, since the HTML protocol slots 
basically beg to be filled with Unicode strings like <a 
href="http://zh.wikipedia.org/wiki/巴泰勒米·波岡達"> (instead of <a 
href="http://zh.wikipedia.org/wiki/%E5%B7%B4%E6%B3%B0%E5%8B%92%E7%B1%B3%C2%B7%E6%B3%A2%E5%B2%A1%E9%81%94">).

But maybe the more interoperable approach is to define a format and 
mechanism (e.g., IRIs, or something like IRIs v2) to map /from ///the 
Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 URI 
format.

My 2¢.

Sean