RFC Errata
Found 6 records.
Status: Verified (1)
RFC 2387, "The MIME Multipart/Related Content-type", August 1998
Source of RFC: mhtml (app)
Errata ID: 5578
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sloane Bernstein
Date Reported: 2018-12-18
Verifier Name: Barry Leiba
Date Verified: 2020-05-05
Section .4 says:
related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
It should say:
related-param := ( ";" "type" "=" type "/" subtype )
[ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
; order independent, "type" is required
Notes:
The "type" parameter is specified by the rest of the document to be mandatory, but the ABNF in section 3.4 indicates that it is optional. Even though the ABNF is specified somewhat informally (and arguably should be formalized if this RFC is ever re-issued), it should not be giving information that contradicts the formal part of the specification (e.g., section 2).
===== Verifier notes =====
As the reporter says, the ABNF here needs more work, and that should be held for document update. This particular item, though, does, indeed, contradict the normative text. I have also moved the required item to the top of the parameter list for clarity.
Status: Held for Document Update (5)
RFC 2387, "The MIME Multipart/Related Content-type", August 1998
Source of RFC: mhtml (app)
Errata ID: 3386
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-18
Held for Document Update by: Barry Leiba
Section 5.1 says:
The example below, uses a single data block.
Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
It should say:
The example below, uses a single data block.
Content-Type: Multipart/Related; boundary=example-1;
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord";
start-info="-o ps"
<OR>
The example below, uses a single data block.
Content-Type: Multipart/Related
;boundary=example-1
;start="<950120.aaCC@XIson.com>"
;type="Application/X-FixedRecord"
;start-info="-o ps"
Notes:
Missing ";"s in parameter list.
RFC 2045 says:
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
Errata ID: 3387
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-18
Held for Document Update by: Barry Leiba
Section 5.2 says:
Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>"
type="Text/x-Okie"
It should say:
Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>";
type="Text/x-Okie"
<OR>
Content-Type: Multipart/Related
;boundary=example-2
;start="<950118.AEBH@XIson.com>"
;type="Text/x-Okie"
Notes:
Another missing ';' [see erratum for Section 5.1].
Errata ID: 5048
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian Kennard
Date Reported: 2017-06-22
Held for Document Update by: Barry Leiba
Date Held: 2019-04-30
Section 3.4 says:
related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
It should say:
Unsure of best way to express this, but this syntax does not seem to allow for the values to be in quotes. e.g. type="text/html" rather than type=text/html
Notes:
Basically, the examples all have quotes around the values, e.g. type="Application/X-FixedRecord" rather than type=Application/X-FixedRecord
It appears that Yahoo email cannot accept type=text/html as per "syntax" in 3.4, but will accept type="text/html" which is consistent with the examples
The examples in the RFC currently do not comply with the RFC.
----- Verifier Notes -----
I think the last sentence in the submitter's notes is the correct one: it's the examples that are wrong, not the ABNF -- the values are not intended to be in quotes. In any case, this needs to be dealt with in a revision of the document, so we're sure we get it right and consider what multiple implementations are doing.
Errata ID: 3389
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-10-18
Held for Document Update by: Barry Leiba
Section 6 says:
MIME User Agents that do recognize Multipart/Related entities but are unable to process the given type should give the user the option of suppressing the entire Multipart/Related body part shall be.
It should say:
MIME User Agents that do recognize Multipart/Related entities but are unable to process the given type SHOULD give the user the option of suppressing the entire Multipart/Related [some grammatically well-formed English].
Notes:
Capitalize the keyword SHOULD.
the entire Multipart/Related body part? the entire Multipart/Related body? all the Multipart/Related content? the entire Multipart/Related body, or just the particular body part of unrecognized type? I'm not sure what this was originally intended to say, just that what's there is a typo.
Errata ID: 3574
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Lee
Date Reported: 2013-03-29
Held for Document Update by: Barry Leiba
Date Held: 2013-03-29
Section 6.4 says:
It is suggested that MUAs that use configuration mechanisms, see [CFG] for an example, refer to Multipart/Related as Multi- part/Related/<type>, were <type> is the value of the "type" parameter.
It should say:
It is suggested that MUAs that use configuration mechanisms refer to Multipart/Related as Multipart/Related/<type>, where <type> is the value of the "type" parameter. See [CFG] for examples of configuration mechanism usage in MUAs.
Notes:
Changed "were" to "where". Also reworded the "CFG" reference to be easier to read.
=== Verifier notes ===
Minor typos and insignificant rewording -- goes into "held for document update".