Subject: Re: draft-ietf-6man-rfc6874bis-00.txt

From: Michael Sweet <[email-masked]>
Date: Mon, 21 Mar 2022 12:56:46 -0400

Hi,

Saw this get posted and I have feedback... :)

- Section 1: For the CUPS reference, I'd add OpenPrinting CUPS since that is where all future development is happening (<https://openprinting.github.io/cups>). Also, IPP in general defines this behavior as part of the IPP (RFC 3510) and IPPS (RFC 7472) URI schemes which map from IPP(S) to HTTP(S).

- Section 2: I very must appreciate dropping the language in 6874 concerning stripping of zone identifiers, as that was one of my strongest objections to the prior RFC.

- Section 3: Extending the URI syntax in this way *will* break existing URI parsers in unfortunate ways, particularly if the zone identifier has two initial characters that are valid hex, e.g. if the zone ID is "20" on a Windows system, the newly encoded URI would look like "https://[fe80::abcd%20]/..." and existing URI parsers (which otherwise don't need to special-case percent encoding of any kind of URI) will treat that as a space in the address... For non-hex characters you'll likely trigger an error/exception when the URI is parsed.

  In the interests of interoperability, backwards compatibility, etc., it might be better for the actual URI wire encoding to stick with "%25" (still "breaks" strict RFC 3986 parsers but with fewer side-effects) and then provide some guidance to browser developers to tweak their processing of URIs in the location field (which is already done, for example for web searches). Remember that there are billions of IPP printers out there that would be affected by this, and while CUPS can certainly rewrite URIs for existing implementations, that won't help people trying to access the printer's web page to configure things...

- Section 4: It isn't specifically the request URI that is used as-is, but the address in the URI. In the case of CUPS, an IPP URI ("ipp://[fe80::abcd%zoneid]/printers/example") is re-written as a HTTP URI ("http://[fe80::abcd%zoneid]:631/printers/example"), and for some resources the path may also be changed (icons, strings files, etc.)

- Section 7.2: Please add OpenPrinting CUPS ("[OP-CUPS]", <https://openprinting.github.io/cups>), LITERAL-ZONE reference might be more useful if it pointed to the last draft that was submitted (<https://www.ietf.org/archive/id/draft-fenner-literal-zone-02.txt>).

________________________
Michael Sweet

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2022 08:56:10 +1300

> - Section 1: For the CUPS reference, I'd add OpenPrinting CUPS since that is where all future development is happening (<https://openprinting.github.io/cups>). Also, IPP in general defines this beh…

Thanks for that.

> - Section 3: Extending the URI syntax in this way *will* break existing URI parsers in unfortunate ways, particularly if the zone identifier has two initial characters that are valid hex, e.g. if t…

It *may* break some parsers in some circumstances, but I am not convinced, and I am reasonably convinced that they can be fixed, from my own investigations and from feedback we've received. These parsers are not syntax-driven parsers that blindly follow the ABNF. They are hand coded and the IPv6 literal syntax is a separate branch in the code, in the cases I have examined. If a URL happens to arrive percent-encoded, it would get decoded before parsing. So %25eth0] would become %eth0] before parsing starts. But %25] needs to stay as %25].
That's codable even if it's horrible. (I didn't do this in my patch to wget, but maybe I should...)

I agree there may prove to be cases of unfortunately named interfaces where it may be necessary to use percent-encoding in the UI anyway. But personally I'm a bit reluctant to discuss that in an RFC.

> - Section 4: It isn't specifically the request URI that is used as-is, but the address in the URI. In the case of CUPS, an IPP URI ("ipp://[fe80::abcd%zoneid]/printers/example") is re-written as a…

Ack

> - Section 7.2: Please add OpenPrinting CUPS ("[OP-CUPS]", <https://openprinting.github.io/cups>), 

Ack

> LITERAL-ZONE reference might be more useful if it pointed to the last draft that was submitted (<https://www.ietf.org/archive/id/draft-fenner-literal-zone-02.txt>).

XML2RFC does what it does...

Thanks
    Brian

---

From: Michael Sweet <[email-masked]>
Date: Mon, 21 Mar 2022 17:13:20 -0400

Brian,

> On Mar 21, 2022, at 3:56 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>> ...

Well, three things:

1. If we are defining how the URI looks "on the wire", then we definitely need to at least cover percent-encoding of the zone ID in the ABNF (whether or not we talk about user agents, etc.), otherwise we haven't really solved things...

2. The existing implementation of RFC 6874 support in CUPS will break with the proposed change since it necessarily requires percent encoding.  I can probably add code to support a bare "%" before the zone ID as long as the following two characters are not hex digits, but that doesn't seem like a reliable path forward.

3. How will I know whether to use the vFUTURE, RFC 6874, or RFC 6874bis format when communicating with a printer? FWIW, when I was at Apple we mandated vFUTURE format for AirPrint (billions of printers), so the default for CUPS is to use the vFUTURE format when talking with printers. When we became aware of RFC 6874 (after publication, sadly, since I wasn't monitoring 6man at the time) I added support for it to CUPS, but AirPrint still requires vFUTURE for compatibility reasons... :/

________________________
Michael Sweet

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2022 15:00:03 +1300

Michael,
> 1. If we are defining how the URI looks "on the wire", then we definitely need to at least cover percent-encoding of the zone ID in the ABNF (whether or not we talk about user agents, etc.), otherw…

I don't really understand that. The idea is that the % will *not* be percent-encoded on the wire and that's what the latest proposed ABNF says. That's an incompatible change from RFC 6874, which we don't care about since the browsers (except residual copies of Internet Explorer) don't support it anyway.

> 2. The existing implementation of RFC 6874 support in CUPS will break with the proposed change since it necessarily requires percent encoding.  I can probably add code to support a bare "%" before…

That problem I can certainly see. But (excuse my ignorance) does CUPS use HTTP as a substrate? Or to be more precise (after a quick look at https://openprinting.github.io/cups/doc/spec-design.html) does it *matter* whether CUPS uses the same wire format as the mainstream browsers? Does libcups use some external http library?

> 3. How will I know whether to use the vFUTURE, RFC 6874, or RFC 6874bis format when communicating with a printer? FWIW, when I was at Apple we mandated vFUTURE format for AirPrint (billions of prin…

I prefer to see you answer for point 2 before thinking about that.

    Brian

---

From: Michael Sweet <[email-masked]>
Date: Tue, 22 Mar 2022 08:43:54 -0400

Brian,

> On Mar 21, 2022, at 10:00 PM, Brian E Carpenter <[email-masked]> wrote:
> ...

Well, I guess I can deal with that in CUPS by effectively dropping RFC 6874 support.

> That problem I can certainly see. But (excuse my ignorance) does CUPS use HTTP as a substrate?

Yes, CUPS uses IPP (IETF STD 92) which is an application protocol on top of HTTP, using POSTs with a binary message format similar in spirit to CBOR, just developed 20 years earlier...

AirPrint, IPP Everywhere, Mopria, and Wi-Fi Direct Print Services, which combined cover a little over 98% of the printers sold over the last 12 years, are all profiles of IPP and so are likewise affected...

> Or to be more precise (after a quick look at https://openprinting.github.io/cups/doc/spec-design.html) does it *matter* whether CUPS uses the same wire format as the mainstream browsers?

Yes, since CUPS provides a web interface for configuration/monitoring and so do those billions of IPP printers in the wild - some of which also use parts of CUPS, as it happens, but most use other IPP/HTTP code that will also need to be updated...  IPP also provides access to resources (icons, color profiles, strings files for localization, etc.) over HTTP...

> Does libcups use some external http library?

No, I rolled my own HTTP client/server library since at the time (25 years ago) there wasn't much available.

________________________
Michael Sweet

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2022 17:13:51 +1300

Michael,

Still to help me understand:

> Yes, since CUPS provides a web interface for configuration/monitoring and so do those billions of IPP printers in the wild - some of which also use parts of CUPS, as it happens, but most use other…

OK, but the issue arises if a user sitting in front of a browser is trying to reach an HTTP server which can *only* be reached via a link-local IPv6 address. That doesn't work today anyway, but it would work if the browser people get around to supporting 6874bis. And then people would be able to reach your CGI interface who cannot do so today. But would your CGI scripts care about the incoming "host" contents?

>> I prefer to see you answer for point 2 before thinking about that.

So, in that case two CUPS components will be communicating using IPP over your own HTTP code, with no browser involved? If so I don't think it matters whether you change the format or not, does it, except for backwards compatibility?

     Brian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 23 Mar 2022 08:54:15 -0400

Brian,

> On Mar 23, 2022, at 12:13 AM, Brian E Carpenter <[email-masked]> wrote:
> ...

Yes, in cases where a request requires authentication CUPS might redirect the request to a HTTPS connection so it is necessary to construct an absolute URL using the Host: value sent in the HTTP request.

(and yes there is another whole mess to deal with how to get browsers to support encrypted IoT web connections without throwing up dire "this site will eat your children" warnings...)

> So, in that case two CUPS components will be communicating using IPP over your own HTTP code, with no browser involved? If so I don't think it matters whether you change the format or not, does it,…

Correct, I'm mainly concerned about backwards compatibility, with an interest in getting to strong interoperability even if using IPv6 link local addresses in URIs is only an edge case.

________________________
Michael Sweet

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2022 08:34:30 +1300

> Yes, in cases where a request requires authentication CUPS might redirect the request to a HTTPS connection so it is necessary to construct an absolute URL using the Host: value sent in the HTTP re…

Oh, right. But then the Host: value needs to be transcribed byte for byte, doesn't it? And specifically in the case of an IPv6 link-local literal, its value is *by definition* meaningless except in the originating host. So whatever the originating host sends is correct by definition, whether it's %25eth0 or %eth0.

> (and yes there is another whole mess to deal with how to get browsers to support encrypted IoT web connections without throwing up dire "this site will eat your children" warnings...)

Indeed, but I'm glad to say that's not my problem ;-).

> Correct, I'm mainly concerned about backwards compatibility, with an interest in getting to strong interoperability even if using IPv6 link local addresses in URIs is only an edge case.

Yes, understood.

Thanks
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 19:20:04 +0100

Brian E Carpenter <[email-masked]> wrote:
    >>>> 3. How will I know whether to use the vFUTURE, RFC 6874, or RFC
    >>>> 6874bis format when communicating with a printer? FWIW, when I was
    >>>> at Apple we mandated vFUTURE format for AirPrint (billions of
    >>>> printers), so the default for CUPS is to use the vFUTURE format when
    >>>> talking with printers. When we became aware of RFC 6874 (after
    >>>> publication, sadly, since I wasn't monitoring 6man at the time) I
    >>>> added support for it to CUPS, but AirPrint still requires vFUTURE
    >>>> for compatibility reasons... :/
    >>>

    > So, in that case two CUPS components will be communicating using IPP
    > over your own HTTP code, with no browser involved? If so I don't think
    > it matters whether you change the format or not, does it, except for
    > backwards compatibility?

Yes, usually. IPP is a killer-app for IPv6-LL in my opinion.
(It annoys me that my printer supports IPv6 really well, but has ACLs
available only for IPv4...)

The IPP client is a local daemon, and it speaks ipp:// (HTTP on port 631) to
the printer.  But, you can usually visit the printer on http://something
to get additional human information such as:
  1) toner state
  2) software/firmware updates
  3) configure ACLs
  4) buy more stuff/features from manufacturer
  5) see diagrams on how/where paper jam is

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 19:22:48 +0100

Michael Sweet <msweet=[email-masked]> wrote:
    > (and yes there is another whole mess to deal with how to get browsers
    > to support encrypted IoT web connections without throwing up dire "this
    > site will eat your children" warnings...)

This morning in IOTOPS, I talked about this exact problem.
https://datatracker.ietf.org/meeting/113/session/iotops
Secure Useable Intranet Browser (SUIB), Manysecured

{yes, that was a shameless plug}

    > Correct, I'm mainly concerned about backwards compatibility, with an
    > interest in getting to strong interoperability even if using IPv6 link
    > local addresses in URIs is only an edge case.

I wish prefer my printer would only use IPv6 LL :-)
Instead, it has a GUA with a DNS entry, and a firewall filter to make my life
easier.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 19:24:49 +0100

Brian E Carpenter <[email-masked]> wrote:
    > Oh, right. But then the Host: value needs to be transcribed byte for
    > byte, doesn't it? And specifically in the case of an IPv6 link-local
    > literal, its value is *by definition* meaningless except in the
    > originating host. So whatever the originating host sends is correct by
    > definition, whether it's %25eth0 or %eth0.

I was surprised the first time I saw /foo/bar work as a relative URL.

At some point, I thought that people wanted to make something like https:///foo/bar
work as a relative URL that changed the scheme, but kept the same Host:

I think that printers that support https likely should ignore the Host:
entry, and assume that printers don't need to be multi-tenant.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 24 Mar 2022 15:07:00 -0400

Michael,

> On Mar 24, 2022, at 2:24 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Actually, it is important for the printer to use the Host: value, otherwise it might "redirect" the browser to a hostname or address that isn't accessible to it (another subnet, mDNS hostname that isn't proxied, etc.)

________________________
Michael Sweet

---

From: Michael Sweet <[email-masked]>
Date: Thu, 24 Mar 2022 15:07:36 -0400

Michael,

> On Mar 24, 2022, at 2:22 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Looking at this now... :)

________________________
Michael Sweet

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2022 09:54:06 +1300

> Actually, it is important for the printer to use the Host: value, otherwise it might "redirect" the browser to a hostname or address that isn't accessible to it (another subnet, mDNS hostname that…

Sure. But if the initiating host uses %25eth0, that must be retained, and if it uses %eth0, that must be retained. It's no business of the server which format the client uses.

    Briann

---

From: Michael Sweet <[email-masked]>
Date: Thu, 24 Mar 2022 17:05:56 -0400

Brian,

> On Mar 24, 2022, at 4:54 PM, Brian E Carpenter <[email-masked]> wrote:
> ...

Actually, good HTTP implementations do validation of the Host: header in order to protect against well-known DNS rebinding attacks, so a server that validates an IPv6 address will need to be updated to validate all three formats...  Not onerous, but something that does require consideration.

________________________
Michael Sweet