RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (2)

RFC 6154, "IMAP LIST Extension for Special-Use Mailboxes", March 2011

Source of RFC: morg (app)

Errata ID: 5265
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Roy A. Gilmore
Date Reported: 2018-02-25

Throughout the document, when it says:


Notes:

In RFC6154, the special-use attributes are consistently shown with initial capitals, but there doesn't appear to be any guidance whether the special-use attributes are case-sensitive, case-insensitive, or implementation defined. This could lead to interoperability issues.

Errata ID: 5581
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Not clear whether SPECIAL-USE implies LIST-EXTENDED
Date Reported: 2018-12-21

Section 5.2 says:


     C: t1 CAPABILITY
     S: * CAPABILITY IMAP4rev1 SPECIAL-USE
     S: t1 OK done

It should say:


     C: t1 CAPABILITY
     S: * CAPABILITY IMAP4rev1 SPECIAL-USE LIST-EXTENDED
     S: t1 OK done

Notes:

Is it okay for a server to support SPECIAL-USE without supporting LIST-EXTENDED? The example seems to imply this, but it's not clear from the RFC text. Section 2 starts with: "For the extended list command [RFC5258]", but doesn't say the server MUST support LIST-EXTENDED.

Status: Held for Document Update (1)

RFC 6154, "IMAP LIST Extension for Special-Use Mailboxes", March 2011

Source of RFC: morg (app)

Errata ID: 4422
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Chris Newman
Date Reported: 2015-07-20
Held for Document Update by: Barry Leiba
Date Held: 2015-07-20

Throughout the document, when it says:

N/A

It should say:

N/A

Notes:

There is missing information in this RFC that resulted in interoperability problems when we performed an informal interop test of multiple implementations on 2015-07-19. This is assumed to be a "hold for document update" errata.

There is no guidance in the document related to how special-use attributes are bootstrapped. Servers may pre-create them but there's no requirement to do so and clients may use the CREATE-SPECIAL-USE or METADATA extensions to bootstrap but there is no requirement to use those mechanisms if the server offers them. This resulted in a server implementation assuming the client would bootstrap these attributes and a client assuming the server would do so, thus interoperability failed.

Given this experience, the fastest way to resolve this interop problem over time is for both client and server to take responsibility for bootstrapping special use mailboxes. This means if clients create a mailbox intended for special use (e.g., drafts, sent, junk, trash, etc), and the CREATE-SPECIAL-USE extension is offered, then clients need to provide the USE extension to improve interoperability. Servers that are provisioned with an end-user's locale or language need to pre-create appropriate special-use mailboxes to improve interoperability of this extension. For existing accounts where the server is upgraded to support this feature, the server can look for mailboxes with names that imply special use and add the attribute to those mailboxes (especially if the server has locale/language awareness provisioned for users). Clients that implement a name-based search if special use attributes are not present and decide to use a mailbox for a special use based on its name can use the METADATA extension, if offered, to label that mailbox appropriately.

Status: Rejected (1)

RFC 6154, "IMAP LIST Extension for Special-Use Mailboxes", March 2011

Source of RFC: morg (app)

Errata ID: 5431
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bron Gondwana
Date Reported: 2018-07-19
Rejected by: Alexey Melnikov
Date Rejected: 2018-07-26

Section 2 says:

An IMAP server that supports this extension MAY include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

It should say:

An IMAP server that supports this extension SHOULD include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

Notes:

There exist clients which send a non-extended LIST command and will correctly display and interact with mailboxes usefully if their special-uses are given in the response.

Because of this, many servers are already replying with the special-use attributes, and there are no known reports of clients being broken by that behaviour. Because of this, the MAY should be raised to a SHOULD, and server implementations should default to turning this on.
--VERIFIER NOTES--
The right way to make this change is to revise the document. MAY was intended at the time of publication.

Report New Errata



Advanced Search