Re: IETF Last Call for HTTP 'core' documents

On Aug 25, 2021, at 9:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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

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

Received on Wednesday, 25 August 2021 20:14:11 UTC