- From: Justin Richer <jricher@mit.edu>
- Date: Sat, 11 Mar 2023 01:08:07 +0000
- To: Michael Sweet <msweet@msweet.org>, Julian Reschke <julian.reschke@gmx.de>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <DM6PR01MB4444C16E1789409BF5407D84BDBB9@DM6PR01MB4444.prod.exchangelabs.com>
Point taken. We've tried to anchor all of the items to specific definitions from the HTTP semantics spec here, what can we do to make that more precise so that other url types are fully covered or excepted in an unambiguous way? I don't see why this couldn't be used on other url types as it stands but I could be wrong. ________________________________ From: Michael Sweet <msweet@msweet.org> Sent: Friday, March 10, 2023 9:47 AM To: Julian Reschke <julian.reschke@gmx.de> Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org> Subject: Re: Artart last call review of draft-ietf-httpbis-message-signatures-16 Julian, > On Mar 10, 2023, at 3:01 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > > On 07.03.2023 18:39, Justin Richer wrote: >> ... >>> All of section 2.2 seems to assume that we’re dealing only with HTTP >>> URLs. This >>> assumption should be made explicit. >> >> This specification is signing for HTTP messages. What other URLs would >> there be at play here? It seems redundant to call it out, especially >> because we’re using the terms from the HTTP semantics specification to >> define the components. >> ... > > HTTP can in theory also be used to access resources with non-HTTP(s) > URIs. In HTTP/1.1, you can use the absolute form of the request target > for that. > > Is it common? No (I believe). IPP uses this mechanism (ipp: and ipps: URIs specify IPP over HTTP/HTTPS), and with billions of IPP printers out there I think we can call it common. :) (but I doubt IPP will use this mechanism for ensuring message integrity...) ________________________ Michael Sweet
Received on Saturday, 11 March 2023 01:08:32 UTC