RFC Errata
Found 6 records.
Status: Verified (5)
RFC 5464, "The IMAP METADATA Extension", February 2009
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 1691
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-22
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11
Section 3.1,2nd para says:
For example, a general comment being added to a mailbox may have an
| entry name of "/comment" and a value of "Really useful mailbox".
^^^^^^^^
It should say:
For example, a general comment being added to a mailbox may have an | entry name of "/shared/comment" and a value of "Really useful mailbox".
Notes:
Rationale:
The example given in the Original Text violates the rules for
the formation of entry names specifcied later in the RFC
(cf. section 3.2 ff.), and is therefore considered confusing.
Errata ID: 1692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-22
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11
Section 4.3, pg.11 says:
Arguments: mailbox-name
| entry
| value
| list of entry, values
It should say:
Arguments: mailbox-name
| list of {entry, value} pairs
Notes:
Location is top of page 11.
Rationale:
The prose version of the syntax specification is confusing.
The ABNF in Section 5 is much more specific, and the prose
should correspond to the ABNF. The relevant ABFN rules
in Section 5 (pg.14/15) are (stripped of comments):
setmetadata = "SETMETADATA" SP mailbox SP entry-values
entry-values = "(" entry-value *(SP entry-value) ")"
entry-value = entry SP value
Errata ID: 2785
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2011-04-20
Verifier Name: Barry Leiba
Date Verified: 2012-05-08
Section 4.2.1 says:
| C: a GETMETADATA "INBOX" (MAXSIZE 1024)
(/shared/comment /private/comment)
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete
It should say:
| C: a GETMETADATA (MAXSIZE 1024) "INBOX"
(/shared/comment /private/comment)
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete
Notes:
GETMETADATA examples with options are wrong. ABNF says the options should be before mailbox name, not after. (Having them after mailbox name would also make the parsing more difficult since it could be confused with entries-list).
Errata ID: 2786
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timo Sirainen
Date Reported: 2011-04-20
Verifier Name: Barry Leiba
Date Verified: 2012-05-08
Section 4.2.2 says:
| C: a GETMETADATA "INBOX" (DEPTH 1)
(/private/filters/values)
S: * METADATA "INBOX" (/private/filters/values/small
"SMALLER 5000" /private/filters/values/boss
"FROM \"boss@example.com\"")
S: a OK GETMETADATA complete
It should say:
| C: a GETMETADATA (DEPTH 1) "INBOX"
(/private/filters/values)
S: * METADATA "INBOX" (/private/filters/values/small
"SMALLER 5000" /private/filters/values/boss
"FROM \"boss@example.com\"")
S: a OK GETMETADATA complete
Notes:
Same reason as for the section 4.2.1 errata.
Errata ID: 3868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Gokcen
Date Reported: 2014-01-16
Verifier Name: Barry Leiba
Date Verified: 2014-01-17
Section 4.4.1 says:
Example:
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment"
/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
In the above example, two entries and their values are returned by
the server.
Example:
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment")
S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
It should say:
Example:
C: a GETMETADATA "INBOX" (/private/comment /shared/comment)
S: * METADATA "INBOX" (/private/comment "My comment"
/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
In the above example, two entries and their values are returned by
the server.
Example:
C: a GETMETADATA "INBOX" (/private/comment /shared/comment)
S: * METADATA "INBOX" (/private/comment "My comment")
S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
Notes:
ABNF in section 5 for "getmetadata" says that when requesting multiple metadata entries, they must be part of a parenthesized list, and not simply space-separated:
getmetadata = "GETMETADATA" [SP getmetadata-options] SP mailbox SP entries
entries = entry / "(" entry *(SP entry) ")"
entry = astring
Status: Rejected (1)
RFC 5464, "The IMAP METADATA Extension", February 2009
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3160
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2012-03-22
Rejected by: Pete Resnick
Date Rejected: 2012-04-28
Section 4.4.2 says:
The response consists of a list of entries, each of which have
changed on the server or mailbox.
Example:
C: a NOOP
S: * METADATA "" /shared/comment
S: a OK NOOP complete
In the above example, the server indicates that the "/shared/
comment" server entry has been changed.
Example:
C: a NOOP
S: * METADATA "INBOX" /shared/comment /private/comment
S: a OK NOOP complete
In the above example, the server indicates a change to two mailbox
entries.
It should say:
needs design input
Notes:
unsolicited METADATA responses not clear as to scope / state
need some prose about what to do depending on client state.
if a client has a mailbox selected should it receive unsolicited metadata responses relating ONLY to that mailbox, or any mailbox? The response has a mailbox field, so it's feasible a client not in a selected state could want responses for any metadata change on any mailbox.
--VERIFIER NOTES--
A desire for more explanatory prose is not appropriate for an erratum.