RFC Errata
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.