Subject: NEW ISSUE: classifying and updating informative references

From: Julian Reschke <[email-masked]>
Date: Mon, 28 May 2007 16:14:16 +0200

Hi,

as far as I can tell, the references below are informative and should be 
classified as such. In some cases, they need to be updated as well:

     Luo1998 ("Tunneling TCP based protocols through Web proxy servers", 
also update reference to quote the expired Internet Draft properly).

     Nie1997 ("Network Performance Effects of HTTP/1.1, CSS1, and PNG").

     Pad1995 ("Improving HTTP Latency").

     RFC821 (SMTP), also update the reference to RFC2821.

     RFC822 ("STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES") 
-- but add another instance as RFC822ABNF for the cases where the 
reference if for the ABNF part (these references will later be replaced 
by references to RFC4234 (see issue abnf)).

     RFC959 (FTP).

     RFC1036 ("Standard for Interchange of USENET Messages").

     RFC1123 ("Requirements for Internet Hosts -- Application and 
Support") -- it is only used as a background reference for rfc1123-date, 
which this spec defines itself (note that note this disagrees with 
draft-gettys-http-v11-spec-rev-00 which made it normative).

     RFC1305 ("Network Time Protocol (Version 3)").

     RFC1436 (Gopher).

     RFC1630 (URI Syntax) -- there'll be a normative reference to a 
newer spec.

     RFC1738 (URL) -- there'll be a normative reference to a newer spec.

     RFC1806 ("Communicating Presentation Information in Internet 
Messages: The Content-Disposition Header").

     RFC1808 (Relative Uniform Resource Locators).

     RFC1867 ("Form-based File Upload in HTML"), also update the 
reference to RFC2388 ("Returning Values from Forms: multipart/form-data").

     RFC1900 ("Renumbering Needs Work").

     RFC1945 (HTTP/1.0).

     RFC1950 (ZLIB).

     RFC1951 (DEFLATE).

     RFC1952 (GZIP).

     RFC2026 ("The Internet Standards Process -- Revision 3").

     RFC2049 ("Multipurpose Internet Mail Extensions (MIME) Part Five: 
Conformance Criteria and Examples").

     RFC2068 (HTTP/1.1).

     RFC2076 ("Common Internet Message Headers").

     RFC2110 (MHTML), also update the reference to RFC2557.

     RFC2145 ("Use and Interpretation of HTTP Version Numbers").

     RFC2183 ("Communicating Presentation Information in Internet 
Messages: The Content-Disposition Header Field").

     RFC2277 ("IETF Policy on Character Sets and Languages").

     RFC2279 (UTF8), also update the reference to RFC3629.

     RFC2324 (HTCPCP/1.0).

     Spero ("Analysis of HTTP Performance Problems").

     Tou1998 ("Analysis of HTTP Performance").

     WAIS ("WAIS Interface Protocol Prototype Functional Specification 
(v1.5)").

Please review & confirm.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 28 May 2007 16:29:56 +0200

* Julian Reschke wrote:
>     RFC1630 (URI Syntax) -- there'll be a normative reference to a newer spec.

It is unclear to me that these should be referenced at all.

>     RFC1952 (GZIP).

Understanding these documents is required in order to understand the
coding values defined for the coding registry established and used by
the document; why would it be appropriate to cite them as informative?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 May 2007 16:42:38 +0200

> It is unclear to me that these should be referenced at all.

Understood. We have (or should have) a separate issue for cleaning up 
section 3.2 when we update to RFC3986 (URI). IMHO we should get rid of 
all the historical references, and then just point people at RFC3986, 
Section 1.

> the document; why would it be appropriate to cite them as informative?

Good point. In this case I followed 
<http://tools.ietf.org/html/draft-gettys-http-v11-spec-rev-00#section-18> 
which made these informative as well. I guess the reasoning is that 
RFC2616 compliant software does not need to support content encodings 
"gzip" or "deflate".

More feedback appreciated (and thanks for checking, Björn).

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 28 May 2007 21:01:31 +0200

>I guess the reasoning is that RFC2616 compliant software does not need to
>support content encodings "gzip" or "deflate".

But it is not optional to implement them in accordance with the relevant
specifications, and the IESG notes in [1]:

  Normative references specify documents that must be read to understand
  or implement the technology in the new RFC, or whose technology must
  be present for the technology in the new RFC to work.
  ...
  Note 1: Even references that are relevant only for optional features
  must be classified as normative if they meet the above conditions for
  normative references.

Unless we change the registry part of the draft in some way, I think the
references need to be normative.

  [1] http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 May 2007 21:38:03 +0200

> references need to be normative.

It seems to me that you're right. I'll move these for below "normative", 
and thus exclude them from this change.

More feedback still welcome :-)

Best regards, Julian