RFC Errata
Found 2 records.
Status: Verified (1)
RFC 6868, "Parameter Value Encoding in iCalendar and vCard", February 2013
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 4383
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Wierbosch
Date Reported: 2015-06-01
Verifier Name: Barry Leiba
Date Verified: 2015-06-01
Section 3.2 says:
GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt sburgh, PA 15212":geo:40.446816,-80.00566
It should say:
GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt sburgh, PA 15212":geo:40.446816\,-80.00566
Notes:
RFC 6350 Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The GEO property value in the example contains a comma. Therefore it must be escaped with a backslash.
(The GEO example in RFC 6350 is incorrect see Errata 3846)
Status: Reported (1)
RFC 6868, "Parameter Value Encoding in iCalendar and vCard", February 2013
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 4374
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-05-21
Section 3 says:
When parsing iCalendar or vCard parameter values, the following apply: o the character sequence ^n (U+005E, U+006E) is decoded into an appropriate formatted line break according to the type of system being used o the character sequence ^^ (U+005E, U+005E) is decoded into the ^ character (U+005E) o the character sequence ^' (U+005E, U+0027) is decoded into the " character (U+0022) o if a ^ (U+005E) character is followed by any character other than the ones above, parsers MUST leave both the ^ and the following character in place
It should say:
When parsing iCalendar or vCard parameter values, the following apply: o first all occurrences of the character sequence ^n (U+005E, U+006E) is decoded into an appropriate formatted line break according to the type of system being used o second all occurrences of the character sequence ^' (U+005E, U+0027) is decoded into the " character (U+0022) o third all occurrences of the character sequence ^^ (U+005E, U+005E) is decoded into the ^ character (U+005E) o if a ^ (U+005E) character is followed by any character other than the ones above, parsers MUST leave both the ^ and the following character in place
Notes:
It is unclear how a string like: FOO=^^n should be decoded.
Possibly FOO=^n or FOO=^\n or FOO=\n
Section 3 implies that ^n is converted first, then ^^, then ^'. But it is not explicit. Also this leads to a contradiction. FOO=^^n will become FOO=\n, not what is expected.
An equally reasonable interpretation is to proceed from the left and convert as encountered.
The first gives FOO=\n the second FOO=^n.
In the absence of an explicit definition of the order of interpretation it is impossible to decide which to use.