RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Reported (2)

RFC 2387, "The MIME Multipart/Related Content-type", August 1998

Source of RFC: mhtml (app)

Errata ID: 5048
Status: Reported
Type: Technical

Reported By: Adrian Kennard
Date Reported: 2017-06-22

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.

Errata ID: 5578
Status: Reported
Type: Technical

Reported By: Sloane Bernstein
Date Reported: 2018-12-18

Section 3.4 says:

     related-param   := [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        [ ";" "type"  "=" type "/" subtype ]
                        ; order independent

It should say:

     related-param   := [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        ( ";" "type"  "=" type "/" subtype )
                        ; order independent

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).

Status: Held for Document Update (4)

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

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

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: 3389
Status: Held for Document Update
Type: Editorial

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

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".

Report New Errata