Found 3 records.

Status: Held for Document Update (2)

RFC 3862, "Common Presence and Instant Messaging (CPIM): Message Format", August 2004

Errata ID: 3625
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergio Garcia
Date Reported: 2013-05-17
Held for Document Update by: Barry Leiba
Date Held: 2013-06-10

Section ABNF defs says:

From-header = "From" ": " [ Formal-name ] "<" URI ">"
                        ; "From" is case-sensitive

It should say:

From-header = %d46 %d72 %d6f %d6g ": " [ Formal-name ] "<" URI ">"
                        ; "From" is case-sensitive

Notes:

All the ABNF from headers are not correct, from ABNF RFC:

Literal text is specified through the use of a string enclosed in quotation marks ("). These strings are case-insensitive and the character set used is (US-)ASCII. Therefore the string “abc” will match “abc”, “Abc”, “aBc”, “abC”, “ABc”, “AbC”, “aBC”, and “ABC”. For a case-sensitive match the explicit characters must be defined: to match “aBc” the definition will be %d97 %d66 %d99.

----------------------- Verifier notes -----------------------
This issue isn't limited to the From header, but applies throughout. However...

Customs for specifying ABNF have become more strict since RFC 3862 was written.
At the time of its writing, it was considered acceptable to use the mechanism here:
specify the string (which would normally be case-insensitive, according to RFC 2234)
and add a comment to note the case-sensitivity. In fact, it was specifically considered
more clear to do that than to specify sequences of hex characters. In addition to the
comments in the ABNF, this variance is noted in Sections 3 and 3.6:

<<
NOTE: Specified text values MUST be used as given, using exactly the
indicated upper- and lower-case letters. In this respect, the ABNF
usage here differs from RFC 2234 [6].
>>

Given that, this is clearly not an *error* in RFC 3862, though a different decision
might be made today, or whenever this document might be revised.

I am therefore marking this report as "held for document update".

Errata ID: 3011
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaushik N V S
Date Reported: 2011-11-03
Held for Document Update by: Peter Saint-Andre

Section 5.2 says:

An Example Esing MIME multipart/signed

It should say:

An Example Using MIME multipart/signed

Status: Rejected (1)

RFC 3862, "Common Presence and Instant Messaging (CPIM): Message Format", August 2004

Errata ID: 4065
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sergio Garcia
Date Reported: 2014-07-28
Rejected by: Barry Leiba
Date Rejected: 2014-07-28

Section 4.1 says:

   Examples:

      From: Winnie the Pooh <im:pooh@100akerwood.com>

      From: <im:tigger@100akerwood.com>

It should say:

   Examples:

      From: "Winnie the Pooh" <im:pooh@100akerwood.com>

      From: <im:tigger@100akerwood.com>



Also there are other From and To headers examples in
 which name should be double quoted:

      h: From: "MR SANDERS" <im:piglet@100akerwood.com>
      h: To: "Depressed Donkey" <im:eeyore@100akerwood.com>

Notes:

From-header = "From" ": " [ Formal-name ] "<" URI ">"

Examples:

From: Winnie the Pooh <im:pooh@100akerwood.com>

But

Formal-name = 1*( Token SP ) / String
Token = 1*TOKENCHAR
String = DQUOTE *( Str-char / Escape ) DQUOTE
NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d
/ %x5e-60 / %x7c / %x7e
/ ALPHA / DIGIT

; Any UCS char except CTLs or SEPARATORS:
TOKENCHAR = NAMECHAR / "." / UCS-highç

So Winnie the Pooh is not a TOKEN but a STRING and should be quoted:

From: "Winnie the Pooh" <im:pooh@100akerwood.com>
--VERIFIER NOTES--
The reporter missed seeing the "1*" in the ABNF for Formal-name; the construct can actually contain multiple space-delimited Tokens, and those names are all valid.

Report New Errata