Re: [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

On Mon, Mar 27, 2023 at 7:12 PM Roy T. Fielding <[email protected]> wrote:

> But actual implementations vary in where, or at what point, they show that
> as an
> error, or even attempt to work around them by replacing %xx with UTF-8 or
> punycode. [E.g., the location bar in a browser is not a URI -- it's a
> UTF-8 search
> string, and 3986 doesn't apply to it until the sausage gets sent on the
> wire.
> The same is true of links in email -- how your client decides that a given
> string
> is a reference instead of plain text is an art, undefined by any standard.]
>

I think this part is wrong, at least in practice. You can use the Twitter
rules and get it right most of the time. It is definitely not a standard,
but most things are close.

The reason is because tweets are allowed to contain all languages, mixed
together, and all sorts of unusual Unicode. The location bar is also not a
regular place. It sounds like a weirdly strong opinion, but you do learn
this stuff if you work on the location bar.

What tweets introduce is something called a "URL without protocol"', so the
"scheme" part of the URI spec is elided. If that sounds like a mess to you,
you would be right. So, here, we can look into IPv6 zones and tweets. I
think they're going to break it, but I saw the Java code and figured it
might not matter.

What you really need to do is look at scheme-less URI authorities and how
that might work. There's no right answer, but I can tell you that there are
many disallowed leading characters. Maybe the easiest case to consider is
something like ietf.org

That works in English, but it doesn't work in Japanese, for example. This
is because they have different whitespace rules.

thanks,
Rob

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art