I'm not an expert in this area, but it seems that these points can be made: 1. RFC 4007 is rather comical because it says in section 6 "The actual representation to encode the scope is implementation dependent and is out of the scope of this document." but section 11 has 7 subsections discussing how to represent zone indexes. 2. It doesn't seem to be a philosophical problem that we define a type of URI that can only be properly interpreted within a very small part of the Internet. There's no requirement that URIs be universally interpretable; "U" stands for "uniform" as in uniform syntax. Or for that matter, that they might be interpreted differently in different places. There is vast elasticity regarding what it means to "identify" a "resource". (I've been involved in a working group that defined URNs that were abstract properties, and would only be realized by comparing a prioritized sequence of URNs against the signals that a device was capable of producing.) 3. Given #2, it's not a problem that many implementations would be unable to parse these URLs because their syntax is not upward-compatible, as long as the beneficial use cases are generally implemented. 4. There seems to be concern that this could introduce situations where a single URL would refer to different resources when resolved in different locations, or that the same resource would be referred to by two different URLs. But there are plenty of situations now where those are true. Presumably security implementations default to rejecting URLs that they don't understand the significance of. 5. There's a significant amount of trouble because RFC 4007 chose "%" as the delimiter for zone indexes but "%" has a special syntax in URLs. In principle, this shouldn't be a problem. "%" is used as the first character of "%xx" escapes, but within URLs, that's just a constraint on the contexts in which "%" may be used. Unfortunately, many people are sloppy and e.g. consider the URL "http://example.com/foo-bar"; to be equivalent to "http://example.com/foo%2dbar";, which leads to a lot of software attempting to "normalize" URIs that contain "%". But the fact that such software would choke on URLs containing zone indexes doesn't seem to be important, as we expect zone indexes to have limited use. The unfortunate circumstance is that RFC 4007 has pretty much frozen "%" as the delimiter character. If we could change that, life would be easier. But there's a lot of deployed software and current practice that would have to be changed. 6. To get full usage of the new syntax, both the browsers and servers that would be accessed by link-local addresses need to be changed. In practice, the browsers are likely to be general-purpose but the servers are likely to be resident on a small subset of devices that are self-consciously network devices. Dale -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
