Re: I-D Action: draft-schinazi-httpbis-link-local-uri-bcp-00.txt

Hi Brian, responses inline.
David

On Tue, Feb 20, 2024 at 6:09 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> David,
>
> (Second attempt, with the correct address for httpbis.)
>
> Thanks for this. I think several WGs need to have a word to say about it,
> obviously including 6MAN. (I am not on httpbis.) I don't much care which
> document obsoletes RFC6874, but that certainly needs 6MAN agreement.
>

I agree, since 6874 involves both URIs and IPv6, it would need to involve
at least the HTTPBIS and 6MAN working groups, probably other groups too.
Let's make sure we involve everyone early on instead of relying on
directorate reviews during IETF last call.

I think this paragraph mischaracterises our draft:
>
> > Later, another attempt was made to allow Web browsers to communicate via
> IPv6 link-local addresses: [DRAFT-ZONE-UI]. In this attempt, the zone
> identifier is no longer encoded in the URI. Instead, client applications
> are requested to offer UI to allow selecting the zone identifier. While
> that document does not mention the Web or browsers directly, its
> publication could be used to help convince browsers to implement support
> for IPv6 link-local addresses. Similarly, this proposal does not seem to be
> gaining support from browser vendors.
>
> The draft is not aimed at browsers; it is intentionally generic. The
> discussion on 6man has been informative, and we'll modify the text
> accordingly. It isn't for the http/browser community to stamp on a draft
> that isn't aimed specifically at them. It's also rather soon to assert that
> the proposal is or isn't gaining support.
>
> A more fair statement would be:
>
> Later, an attempt has been made to address the generic question of how
> users should enter IPv6 link-local addresses into software interfaces
> [DRAFT-ZONE-UI]. In this model, the zone identifier is considered
> independently of the IPv6 address itself, and thus in the case of a browser
> would not be considered part of a URI. However, this does not in itself
> resolve all the difficulties in considering the zone identifier as part of
> the HTTP origin model [RFC6454]. Therefore, this approach does not resolve
> the issue of how browsers should support link-local addresses.
>
> (And that last sentence will probably pop up in the next version of
> [DRAFT-ZONE-UI].)
>

My apologies, I agree that I could've done a better job there. I've taken
inspiration from your text to replace this paragraph in -01. The updated
paragraph reads: <<Later, an attempt was made to address the generic
question of how users can input IPv6 link-local addresses into software
interfaces [DRAFT-ZONE-UI]. In this model, the zone identifier is
considered independently of the IPv6 address itself. In the case of Web
browsers, the zone identifier would not be considered part of a URI.
However, this does not in itself resolve all the difficulties in
considering the zone identifier as part of the Web security model, as
described in the next section.>>

Regards
>      Brian Carpenter
>
> On 21-Feb-24 14:06, internet-drafts@ietf.org wrote:
> > Internet-Draft draft-schinazi-httpbis-link-local-uri-bcp-00.txt is now
> > available.
> >
> >     Title:   Best Practices for Link-Local Connectivity in URI-Based
> Protocols
> >     Author:  David Schinazi
> >     Name:    draft-schinazi-httpbis-link-local-uri-bcp-00.txt
> >     Pages:   11
> >     Dates:   2024-02-20
> >
> > Abstract:
> >
> >     Link-local IP connectivity allows hosts on the same network to
> >     communicate with each other without the need for centralized IP
> >     addressing infrastructure.  The IP prefixes 169.254.0.0/16 and
> >     fe80::/10 were reserved for this purpose.  However, both IP versions
> >     have limitations that make link-local addresses unideal for usage
> >     with URI-based protocols.  This document provides guidance for how
> >     best to enable link-local connectivity in such protocols.  This
> >     document also obsoletes RFC 6874, a previous attempt at solving this
> >     issue.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> >
> https://datatracker.ietf.org/doc/draft-schinazi-httpbis-link-local-uri-bcp/
> >
> > There is also an HTML version available at:
> >
> https://www.ietf.org/archive/id/draft-schinazi-httpbis-link-local-uri-bcp-00.html
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> >
>