Re: Fwd: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

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

Ted,

Below...

On 06-Jul-21 19:47, Ted Hardie wrote:
> Hi Brian,
> 
> In-line below
> 
> On Mon, Jul 5, 2021 at 9:50 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 06-Jul-21 03:28, Michael Richardson wrote:
>     >
>     > First, I think that this work is really important, and I'd like to proceed.
>     >
>     > Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>     >     > The new draft proposes to update the RFC accordingly. The changes
>     >     > are relatively small but significant. There's a diff between the
>     >     > RFC and this draft at:
>     >     > https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html <https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html>
>     >
>     > I read the diff, and I was unable to actually figure out what had 
changed :-(
>     >
>     >     > Comments welcome. If we want to go ahead with this fix, we will need to
>     >     > reach out to the URI specialists and the browser community, to be
>     sure
>     >     > it isn't a waste of time.
>     >
>     > Does the zoneid go into the Host: header or not?
>     > I can't tell at this point.
> 
>     As I understand the HTTP/1.1 spec, the Host: header is required to include
>     the complete URI, 
> 
>  
> This is not correct.  Please see RFC 7230, Section 5.4.  The full URI would include scheme and the path, which are not included in the 
host header. 

Correct, i.e.

  Host = uri-host [ ":" port ]

and if we follow the breadcrumbs to uri-host

  uri-host = <host, see [RFC3986], Section 3.2.2>

where

   host        = IP-literal / IPv4address / reg-name

and of course it's IP-literal that we redefine in RFC6874 and the present 
draft.
In the ideal world, RFC7230 should IMHO have cited RFC6874 as well as RFC3986.

However, what I was getting at is that a browser that mangles the IP-literal by
*removing* the ZoneID, as required by RFC6874, would be violating the behaviour described by RFC7230. Since we propose to delete that requirement anyway, the
issue is moot for the present draft. Sorry about my lack of clarity.

   Brian

> 
> regards,
> 
> Ted
>  
> 
>     so RFC6874 was wrong anyway because it did not claim
>     to update HTTP :-). So yes, and furthermore at least one deployed
>     protocol (CUPS) relies on it.
> 
>        Brian
> 
>     >
>     >
>     > --
>     > Michael Richardson <[e-mail] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>     >            Sandelman Software Works 
Inc, Ottawa and Worldwide
>     >
>     >
>     >
>     >
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
<https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>