2822upd-04 line length limits
Bruce Lilly <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Organization | Bruce Lilly |
| Message-ID | <[email protected]> |
On Sunday 27 January 2008 21:02:33 Tony Hansen wrote: > But MIME sort of blurs the lines between the identity definitions > and the encodings. Agreed to the extent that a single keyword either indicates an encoding transformation which has an implicit domain, or the domain of unencoded content. > And you sort of blurred the lines by only talking > about MIME encoding and then using that to say that "extending the line > length limits" was incorrect. No, I stated some objections to the implication that "implementations which display messages" must "handle an arbitrarily large number of characters in a line" (whereas MIME specifically limits lines using non-identity encodings to 76 characters, specifically and as explicitly stated in the MIME RFCs to provide a bound on what implementations must handle) and stated that "extend this specification" might be misinterpreted in that context. I did not use the term "incorrect" in that regard. > However, I don't think it's necessary to mention all potentially > relevant RFCs and errata. This particular paragraph was using the MIME > RFCs as examples. Agreed that it's unnecessary to mention all potentially relevant RFCs. However where normative references have errata or are amended by other RFCs, those errata and/or amending RFCs should be mentioned, as they are essential to correct interpretation of the (amended) normative references. Speaking of the particular examples chosen, two of them are media type registration procedure specifications, which are not relevant to the message format specification per se.