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

Regards
    Brian Carpenter

On 27-Mar-23 14:37, Rob Sayre wrote:
> On Sun, Mar 26, 2023 at 6:31 PM Brian E Carpenter <[email protected] <mailto:[email protected]>> wrote:
> 
>     I 100% fail to understand what you mean.
> 
>     http://[fe80::abcd-eth0] won't parse today any better than http://[fe80::abcd%eth0]. Neither of them respects the current grammar. Whatever we do here extends the grammar.
> 
> 
> No. You can leave some things opaque. For example, your draft even covers this in Section 4 of Appendix A:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis#appendix-A <https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis#appendix-A>
> 
> It says "Simply use the 'IPvFuture' syntax left open in RFC 3986".
> 
> You could do that, right? But maybe we have an accidental production here. That's fine too. Just say it, if that's the case.

CUPS, I believe, does use IPvFuture internally, but that has no impact except on CUPS participants.

We could do, say, http://[vf.fe80::abcd%eth0]. Everybody could modify their parsers. But what would be the advantage of adding that extension rather the simpler extension already proposed?
It's the same new ABNF, but in a different place in the parse tree. This just seems to make the parser more complicated without changing the practical effect.

(Since it's still in the host part, it inherits the problems of case-folding and percent-encoding anyway, as far as I can see.)

    Brian

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