Re: [whatwg/url] Support IPv6 zone identifiers (#392)

Here are a few thoughts I have on this, without indicating support or opposition:

inet_pton seems to be ok with "fe80::abcd%25eth1"  and "fe80::abcd%eth1" but not "fe80::abcd-eth1".  NSURL seems to be ok with "http://[fe80::abcd%25eth1]/" and "http://[fe80::abcd-eth1]/" but not "http://[fe80::abcd%eth1]/".  "fe80::abcd%25eth1" seems to be the most parsable of those examples in my sample of 2 IPv6 host parsers.  I'm concerned that if we decide to use "%25" as the delimiter to indicate the beginning of a zone id, some software will interpret "25eth1" to be the zone id and some will interpret "eth1" to be the zone id.  All browsers currently fail to parse all of those examples.  It is clear that software will need to change if we decide to support this.  If compatibility weren't a concern, I think it would be nicest to introduce a new delimiter such as '-'.

I'm curious how someone would get a zone id to use.  Some systems might use "eth1" as a meaningful zone id, while other systems might use "en1" or "1".  If this is the case, it makes me question the uniformity of these URIs.

Your document says "However, the IPv6 Scoped Address Architecture specification gives no precise definition of the character set allowed in <zone_id>. There are no rules or de facto standards for this."  In order to be a part of the URL specification, we need a precise parsing definition for all possible input, such as "http://[fe80::abcd%25💩]/" which I imagine would need to percent-encode the emoji, or "http://[fe80::abcd%25%invalid]/" which seems to fail to parse.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/392#issuecomment-901510330