Re: [IPv6] Link-local URI status (rfc6874bis)

[Brian E Carpenter <[e-mail]>]

> 
>> Also, the format for non-global addresses might conflict with the URI
>> syntax [13], since the syntax defines the delimiter character (`%')
>> as the escape character.  […]
> 
> Why???  Was the decision to be incompatible forced by anything?

It was a mistake. Possibly there was running code using the '%' sign before RFC 4007 was published; it goes back to https://datatracker.ietf.org/doc/html/draft-ietf-ipngwg-scoping-arch-02.txt in March 2001.

However, mitigating that mistake (by agreeing to use a different symbol in URIs) is only one of the three problems that are holding up the draft.

Regards
    Brian

On 01-Nov-23 22:30, Carsten Bormann wrote:
> Hi Brian,
> 
> I am not sure I can contribute much of anything at this point, but I think we can learn from this specification, so I’ll try to write up as much as I understand.
> 
> First, I recognize this as a textbook (sic) example of falling prey to the attraction of text-based formats.
> Of course, the text-based URL was the major innovation that made the Web possible, and of course we need a way for humans to interact with the network, based on IP addresses.
> 
> But what happened here was that the IP address format was simply embedded in the URL format, and, when it inevitably was extended (to cover IPv6), the extension chose a character (“:”) that is not fully transparent in that embedding.  The brackets serve as a workaround for this specific issue (published 1999 in RFC 2732 after the Web was built on RFC 2396, published 1998, finally published to the Web community in RFC 3986 in 2005).
> We didn’t think that inevitably the address format would need to be extended again (well, there is IPvFuture, but that was never used AFAIK and is framed as support for a new IP version, which I hope won’t happen so quickly).
> 
> Enter RFC 4007 (also published in 2005), the inevitable next extension of the text-based address format.
> Amazingly, this did *not* define how this extension would be used in a URI:
> 
>> Hence, this document does not specify how the format for non-global
>> addresses should be combined with the preferred format for literal
>> IPv6 addresses. In any case, it is recommended to use an FQDN
>> instead of a literal IPv6 address in a URL, whenever an FQDN is
>> available.
> 
> Worse, the reason given before the “Hence” is that the wrong delimiter was chosen:
> 
>> Also, the format for non-global addresses might conflict with the URI
>> syntax [13], since the syntax defines the delimiter character (`%')
>> as the escape character.  […]
> 
> Why???  Was the decision to be incompatible forced by anything?
> 
> Obviously, when a text-based format is extended by using new lexical features, embeddings into other text-based formats that might be using these lexical features for something else will break.  So it behooves the embedded text-based format to be a bit careful about causing this breakage, even if that should really be none of its job (a layer violation of the worse kind).
> 
> Anyway, this problem was explained away, and as we have learned, the lexical issue served as an interoperability problem, a block to implementation, and ultimately (together with vague security issues) as a convenient excuse for not implementing the extension.
> 
> Now we have the unclean situation with two interpretations of the % extension, plus the purported security issues that make it convenient to just point to the unclean situation and do nothing.
> 
> How do we get out of the corner that we have painted ourselves into?
> 
> Taking one side (the opposite one to the previous RFC) and hoping that everyone will follow creates interoperability problems (and possibly even real security issues) with implementations that are on the other side.
> It is never clear in a debugging situation whether the new standard is prevailing or the old one is still in effect.
> Instead of creating a dilemma, we should create a path forward.
> 
> Choosing a delimiter that is more compatible with the URI format (*) would be one such way forward.
> Yes, that makes copy/paste a bit more awkward (OK, I’d simply add the new syntax to, er, telnet, too).
> But it would create a clear target that is the “new way” of doing this, without question marks and caveats.
> 
> We can’t reduce the pain of doing this, though.
> Maybe we can reduce the pain of being stuck in that corner by finally leaving it.
> But please let’s choose that delimiter (or maybe even better the format in general) carefully this time (**)...
> 
> Grüße, Carsten
> 
> (*) And other embeddings that are in use out there!
> 
> (**) (What is the next extension we need to make to IPv6 addresses?)
> 
> PS.: A fun side story about extending text-based formats by adding lexical features is happening in JOSE right now.  JOSE represents its data usually not in JSON, but in a “.”-delimited sequence of base64url-encoded byte string blobs (one of which actually is a JSON text).  New extensions for Selective Disclosure need to extend this structure with a substructure, so what do we do?  Use “~” as a delimiter for the elements of that substructure!  (The only character that allows all existing embeddings of this text-based format in URIs to continue.  At least we think so...)
>