RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 2683, "IMAP4 Implementation Recommendations", September 1999

Source of RFC: Legacy

Errata ID: 3129

Status: Verified
Type: Technical

Reported By: Karl Fenech
Date Reported: 2012-02-19
Verifier Name: Pete Resnick
Date Verified: 2012-03-29

Section 3.2.1.3 says:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20001.20000>
       S: * 3 FETCH (BODY[1]<20001> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40001.20000>
       ...etc...

It should say:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS (\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20000.20000>
       S: * 3 FETCH (BODY[1]<20000> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40000.20000>
       ...etc...

Notes:

The main erratum is an off-by-one error. The starting index of an IMAP partial body fetch is zero-based. A request for BODY[1]<0.20000> would fetch octets 0 to 19999 (inclusive). A request for BODY[1]<20001.20000> would fetch octets 20001 to 40000 (inclusive). As a consequence, octet 2000 is skipped in the original suggested implementation, with the strong possibility of leading to data corruption if the message body is reconstructed by concatenating the retrieved substrings.

There is a secondary erratum: There should be a mandatory space between the "FLAGS" string and the parenthesized list of flags. Refer to the definition for msg-att-dynamic in the Formal Syntax of RFC 3501.

Status: Held for Document Update (1)

RFC 2683, "IMAP4 Implementation Recommendations", September 1999

Source of RFC: Legacy

Errata ID: 3165

Status: Held for Document Update
Type: Editorial

Reported By: Christian Ketterer
Date Reported: 2012-03-23
Held for Document Update by: Barry Leiba

Section 3.4.12 says:

If the client chooses to try to take
advantage of this possibility it must be prepared to use the other
method in the even that the more convenient one fails.

It should say:

If the client chooses to try to take
advantage of this possibility it must be prepared to use the other
method in the event that the more convenient one fails.

Notes:

"t" missing from "event"

Report New Errata



Search RFCs
Advanced Search
×