- From: Rick van Rein <rick@openfortress.nl>
- Date: Sat, 4 Feb 2023 21:05:53 +0000
- To: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
- Cc: ietf-http-wg@w3.org
Hello Hugo, Thanks for studying the spec. > Section 2.1 and 2.2 refer to the "c2c", "c2s", "s2s" and "s2c" fields. These > are not "fields", they are *additional parameters* of the WWW-Authenticate > header field (this is the nomenclature found in rfc7235 section-4.1). Calling > them fields can be a bit confusing, especially during the first read and before > reaching the examples in Section 4. Yes, you are correct. I shall change that in the draft. > I'm not entirely sure if the intended use of the User header is fully clear, > nor how User Agents are expected to determine a value for it. Perhaps it is > best to further elaborate on this? Thanks, 1st-time reader input is really useful. It works just like the Host: header, in fact, and selects server-side resources. The text is a bit generic perhaps, will look to rephrase it. This is a protocol spec, and should avoid pinning down anything to a user agent that is not needed for interoperability, so this is not easy. > Those minor comments aside, I do find this specification quite useful and would > like to voice my support of the proposal. In particular, HTTP with SASL would > be of much use for CalDAV (rfc4791) and CardDAV (rfc6352). Currently it is > possible to use email (IMAP and SMTP) with SASL (and therefore, SASL+OAUTH), > but there is no standard mechanism to use SASL for address books and calendars. > It seems quite clear to me that this specification has a very useful impact in > the WebDav space in general. Thank you very much; that is a perfect example of the general idea behind the spec, to amalgamate authentication across protocols. I had not thought of Calendaring/Cards, but indeed: they work over generic carrier protocols. Cheers, -Rick
Received on Saturday, 4 February 2023 21:06:07 UTC