Subject: IETF Last Call for HTTP 'core' documents

From: Mark Nottingham <[email-masked]>
Date: Sat, 21 Aug 2021 12:03:39 +1000

Hi everyone,

IETF LC has completed for the 'core' documents, and we've integrated all of the feedback in the -18 drafts.

One of the things we intended for this document set was to promote them to 'full' IETF Standards, rather than Proposed Standard (which they've been in various forms for more than two decades). However, to do that, we'll need to go through an additional IETF Last Call, since the right bits weren't set when the previous LC was run.

That second IETF LC will be called by our AD, and like all IETF LCs, should last for two weeks. 

Cheers and thanks for your patience,

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Aug 2021 13:12:49 +0200

> Cheers and thanks for your patience,

FWIW, below are the links for the drafts relative to -16 (the IETF LC
version):

https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-messaging-18.txt&url1=draft-ietf-httpbis-messaging-16.txt

https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-semantics-18.txt&url1=draft-ietf-httpbis-semantics-16.txt

https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-cache-18.txt&url1=draft-ietf-httpbis-cache-16.txt

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Aug 2021 18:06:55 +0200

> Cheers and thanks for your patience,

Checked for downrefs given the new intended status... (with
<https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>).

Messaging:

 > Normative References:
 > CACHING: not checked
 > HTTP: not checked
 > RFC1950: [INFORMATIONAL] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC1951: [INFORMATIONAL] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC1952: [INFORMATIONAL] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
 > RFC5234: [INTERNET STANDARD] (-> STD0068)
 > RFC7405: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC8174: [BEST CURRENT PRACTICE] (-> BCP0014)
 > RFC8446: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC3986: [INTERNET STANDARD] (-> STD0066)
 > USASCII: not checked
 > Welch: not checked

Semantics:

 > Normative References:
 > CACHING: not checked
 > RFC1950: [INFORMATIONAL] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC1951: [INFORMATIONAL] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC1952: [INFORMATIONAL] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC2046: [DRAFT STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
 > RFC4647: [BEST CURRENT PRACTICE] (-> BCP0047)
 > RFC4648: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC5234: [INTERNET STANDARD] (-> STD0068)
 > RFC5280: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC5322: [DRAFT STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC5646: [BEST CURRENT PRACTICE] (-> BCP0047)
 > RFC6125: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC6365: [BEST CURRENT PRACTICE] (-> BCP0166)
 > RFC7405: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC8174: [BEST CURRENT PRACTICE] (-> BCP0014)
 > RFC0793: [INTERNET STANDARD] (-> STD0007)
 > RFC8446: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC3986: [INTERNET STANDARD] (-> STD0066)
 > USASCII: not checked
 > Welch: not checked

Caching:

 > Normative References:
 > HTTP: not checked
 > RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
 > RFC5234: [INTERNET STANDARD] (-> STD0068)
 > RFC7405: [PROPOSED STANDARD] -- intended standards level of internet
incompatible with this document's standard level!
 > RFC8174: [BEST CURRENT PRACTICE] (-> BCP0014)

Looking at the details:

RFC1950, RFC1951, RFC1952: [INFORMATIONAL] -- specs for the compression
codings, have been a downref before

RFC2046: [DRAFT STANDARD] -- Media Types. ?

RFC4648: [PROPOSED STANDARD] -- Base 16/32/64 ?

RFC5280: [PROPOSED STANDARD] -- Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile ?

RFC5322: [DRAFT STANDARD] -- Internet Message Format ?

RFC6125: [PROPOSED STANDARD] -- Representation and Verification of
Domain-Based Application Service Identity within Internet Public Key
Infrastructure Using X.509 (PKIX) Certificates in the Context of
Transport Layer Security (TLS) ?

RFC7405: [PROPOSED STANDARD] -- these are ABNF extensions, so I'll
assume that the downref will be permitted

RFC8446: [PROPOSED STANDARD] -- TLS - Martin T. is already looking into
this.

So we have a few downrefs that were downrefs before, a few to specs that
really should be full standards as well (Base16/32/64), and some more
where the answer is not clear, and the IESG would need to sanction the
downref.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 25 Aug 2021 13:13:43 -0700

> where the answer is not clear, and the IESG would need to sanction the

FWIW, these are all cases where the technology itself is stable but the
specs might progress on the standards track at some future date.

Changes to those specs are unlikely to impact HTTP because they
are orthogonal technologies used by reference (e.g., media types,
codings, TLS, PKIX) or the reference is to a specific grammar defined
by that RFC (e.g., ABNF, Base 16/32/64, IMF). Hence, they should all
be approved as downrefs.

In contrast, I've lost count of the number of IETF specs that are
entirely dependent on HTTP.  Somebody has to go first (or in this
case second, since URI [STD66] was published in 2005).

Cheers,

....Roy