RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 6868, "Parameter Value Encoding in iCalendar and vCard", February 2013

Source of RFC: IETF - NON WORKING GROUP
Area 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 GROUP
Area 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.

Report New Errata



Advanced Search