errata logo graphic

Found 19 records.

Status: Verified (14)

RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Source of RFC: calsify (app)

Errata ID: 1911

Status: Verified
Type: Technical

Reported By: Bernard Desruisseaux
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-13

Section 2.1 says:

| DQUOTE                 | 22                |

It should say:

| DQUOTE                 | 34                |

Notes:

The codepoint for the DQUOTE character was erroneously specified in hexadecimal instead of decimal. Issue was found by Raimund Nisius.


Errata ID: 1913

Status: Verified
Type: Technical

Reported By: Anshul Agrawal
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-07

Section 3.3.10 says:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYWEEKNO or BYMONTH rule parts are present.  If an integer

It should say:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYWEEKNO or BYMONTH rule parts are not present.  If an integer
                                   ^^^

Notes:

The original statement appears contradictory in itself.


Errata ID: 1916

Status: Verified
Type: Technical

Reported By: Alexey Melnikov
Date Reported: 2009-10-15
Verifier Name: Lisa Dusseault
Date Verified: 2010-03-10

Section 3.6.4 says:

  BEGIN:VFREEBUSY
  UID:19970901T115957Z-76A912@example.com
  DTSTAMP:19970901T120000Z
  ORGANIZER:jsmith@example.com
           ^

It should say:

  BEGIN:VFREEBUSY
  UID:19970901T115957Z-76A912@example.com
  DTSTAMP:19970901T120000Z
  ORGANIZER:mailto:jsmith@example.com
            ^^^^^^^

Notes:

The last example in section 3.6.4 is missing "mailto:" after the "ORGANIZER:"


Errata ID: 2039

Status: Verified
Type: Technical

Reported By: Arnout Engelen
Date Reported: 2010-02-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-15

Section 4 says:

       BEGIN:VALARM
       ACTION:AUDIO
       TRIGGER:19980403T120000Z
       ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
        files/ssbanner.aud
       REPEAT:4
       DURATION:PT1H
       END:VALARM

It should say:

       BEGIN:VALARM
       ACTION:AUDIO
       TRIGGER;VALUE=DATE-TIME:19980403T120000Z
       ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
        files/ssbanner.aud
       REPEAT:4
       DURATION:PT1H
       END:VALARM

Notes:

The trigger is presented as a DATE-TIME, but the default type of this field is DURATION (3.8.6.3). Either the type must be specified (as per the corrected text), or specified in DURATION format.


Errata ID: 2677

Status: Verified
Type: Technical

Reported By: Bernard Desruisseaux
Date Reported: 2010-12-21
Verifier Name: Alexey Melnikov
Date Verified: 2011-01-20

Section 3.8.1.10 says:

Conformance:
This property can be specified once in "VEVENT" or "VTODO" calendar component.
                               ^^^^

It should say:

Conformance:
This property can be specified in "VEVENT" or "VTODO" calendar component.

Notes:

The word "once" was mistakenly introduced in RFC 5545.
RFC 2445 didn't have this issue.

Issues was previously reported by Dennis Gearon <gearond@sbcglobal.net>
(See Errata 2676) but proposed the wrong correction.


Errata ID: 3740

Status: Verified
Type: Technical

Reported By: Daniel Barkalow
Date Reported: 2013-09-29
Verifier Name: Barry Leiba
Date Verified: 2013-10-08

Section 4 says:

       BEGIN:VTIMEZONE
       TZID:America/New_York
       BEGIN:STANDARD
       DTSTART:19981025T020000
       TZOFFSETFROM:-0400
       TZOFFSETTO:-0500
       TZNAME:EST
       END:STANDARD
       BEGIN:DAYLIGHT
       DTSTART:19990404T020000
       TZOFFSETFROM:-0500
       TZOFFSETTO:-0400
       TZNAME:EDT
       END:DAYLIGHT
       END:VTIMEZONE

It should say:

       BEGIN:VTIMEZONE
       TZID:America/New_York
       BEGIN:STANDARD
       DTSTART:19671029T020000
       RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z
       TZOFFSETFROM:-0400
       TZOFFSETTO:-0500
       TZNAME:EST
       END:STANDARD
       BEGIN:DAYLIGHT
       DTSTART:19870405T020000
       RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z
       TZOFFSETFROM:-0500
       TZOFFSETTO:-0400
       TZNAME:EDT
       END:DAYLIGHT
       END:VTIMEZONE

Notes:

The time zone specification in the original example does not cover the event in the example (which occurs on 19980312, before both of the listed onsets).

---- Verifier notes -----
The corrected text uses part of the VTIMEZONE definition in the example on page 68.


Errata ID: 3779

Status: Verified
Type: Technical

Reported By: Daniele Mancini
Date Reported: 2013-10-31
Verifier Name: Barry Leiba
Date Verified: 2013-10-31

Section 3.3.10 says:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYWEEKNO or BYMONTH rule parts are present.  If an integer
modifier is not present, it means all days of this type within the
specified frequency.  For example, within a MONTHLY rule, MO
represents all Mondays within the month.  The BYDAY rule part MUST
NOT be specified with a numeric value when the FREQ rule part is
not set to MONTHLY or YEARLY.  Furthermore, the BYDAY rule part
MUST NOT be specified with a numeric value with the FREQ rule part
set to YEARLY when the BYWEEKNO rule part is specified.

It should say:

represents the last Monday of the month.  The numeric value in a
BYDAY rule part with the FREQ rule part set to YEARLY corresponds
to an offset within the month when the BYMONTH rule part is
present, and corresponds to an offset within the year when the
BYMONTH rule part is not present.  If an integer
modifier is not present, it means all days of this type within the
specified frequency.  For example, within a MONTHLY rule, MO
represents all Mondays within the month.  The BYDAY rule part MUST
NOT be specified with a numeric value when the FREQ rule part is
not set to MONTHLY or YEARLY.  Furthermore, the BYDAY rule part
MUST NOT be specified with a numeric value with the FREQ rule part
set to YEARLY when the BYWEEKNO rule part is specified.

Notes:

Other than the missing 'not', pointed out in the errata 1913, the original text contradicts itself regarding BYWEEKNO.
At the beggining of the paragraph, it says that when using a YEARLY frequency with BYWEEKNO rule part, the integer part identifies an offset within the year (i.e. either in [-53, 0) or (0, 53], as it can be a week day in a valid week of the year, even if it is not clearly specified), but at the end of the paragraph, it states that offsets should not be specified in conjunction with a BYWEEKNO rule part.


Errata ID: 3883

Status: Verified
Type: Technical

Reported By: Bruce Florman
Date Reported: 2014-02-05
Verifier Name: Barry Leiba
Date Verified: 2014-02-14

Section 3.8.5.3 says:

      Every 3 hours from 9:00 AM to 5:00 PM on a specific day:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z

       ==> (September 2, 1997 EDT) 09:00,12:00,15:00

It should say:

      Every 3 hours from 9:00 AM to 5:00 PM on a specific day:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T210000Z

       ==> (September 2, 1997 EDT) 09:00,12:00,15:00

Notes:

The UNTIL rule part is specified with UTC time, which was four hours ahead of America/New_York on 19970902. So 170000Z would only be 1:00 PM on that day.

The corrected UNTIL rule matches the description (from 9 to 5). Note that "UNTIL=19970902T190000Z" would have the same effect (the last event is at 3 PM in New York, which is 19:00 Z), but 21:00 Z is what matches the description.


Errata ID: 4149

Status: Verified
Type: Technical

Reported By: Hiroaki KAWAI
Date Reported: 2014-10-29
Verifier Name: Barry Leiba
Date Verified: 2014-10-30

Section 4 says:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:mailto:jsmith@example.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z

It should say:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
UID:19970901T115957Z-76A912@example.com
DTSTAMP:19970901T120000Z
ORGANIZER:mailto:jsmith@example.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z

Notes:

3.6.4 says
fbprop = *(
;
; The following are REQUIRED,
; but MUST NOT occur more than once.
;
dtstamp / uid /


Errata ID: 2497

Status: Verified
Type: Editorial

Reported By: Scott Furry
Date Reported: 2010-08-21
Verifier Name: Peter Saint-Andre
Date Verified: 2010-09-14

Section 2.1 (pg 7) says:

              +------------------------+-------------------+
              | Character name         | Decimal codepoint |
              +------------------------+-------------------+
              | HTAB                   | 9                 |
              | LF                     | 10                |
              | CR                     | 13                |
-->           | DQUOTE                 | 22                |
-->           | SPACE                  | 32                |
... table continues

It should say:

              +------------------------+-------------------+
              | Character name         | Decimal codepoint |
              +------------------------+-------------------+
              | HTAB                   | 9                 |
              | LF                     | 10                |
              | CR                     | 13                |
-->           | SPACE                  | 32                |
-->           | DQUOTE                 | 34                |
                                         ^^
                                         corrected value
...table continues

Notes:

Correction to Table on page 7 of RFC updating the order of ASCII-US listing (decimal codepoint descending) and incorporating errata ID 1911(2009-10-13 - DQUOTE char listing shows hexadecimal value).


Errata ID: 2038

Status: Verified
Type: Editorial

Reported By: Arnout Engelen
Date Reported: 2010-02-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-15

Section Appendix A says:

   5.  The "DURATION" property can no longer appear in "VFREEBUSY"
       components.

A.2. Restrictions Removed

It should say:

   5.  The "DURATION" property can no longer appear in "VFREEBUSY"
       components.

   6.  Use of the "charset" Content-Type parameter in MIME transports 
       is now mandatory.

A.2. Restrictions Removed

Notes:

One change is missing from the list of changes.


Errata ID: 2516

Status: Verified
Type: Editorial

Reported By: David Wright
Date Reported: 2010-09-13
Verifier Name: Peter Saint-Andre
Date Verified: 2010-09-14

Section 3.8.4.1 says:

Example:  The following is an example of this property's use when
      another calendar user is acting on behalf of the "Attendee":

       ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith:
        mailto:jsmith@example.com

It should say:

Example:  The following is an example of this property's use when
      another calendar user is acting on behalf of the "Attendee":

       ATTENDEE;SENT-BY="mailto:jan_doe@example.com";CN=John Smith:
                        ^                          ^
        mailto:jsmith@example.com

Notes:

In the specification for SENT-BY (3.2.18), the r-value MUST be explicitly bound by DQUOTEs (ABNF follows)

sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE


Errata ID: 2527

Status: Verified
Type: Editorial

Reported By: David Wright
Date Reported: 2010-09-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-04

Section 3.8.5.2 says:

  Example:  The following are examples of this property:

       RDATE:19970714T123000Z
       RDATE;TZID=America/New_York:19970714T083000

       RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
        19960404T010000Z/PT3H

       RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
        19970526,19970704,19970901,19971014,19971128,19971129,19971225

It should say:

  Example:  The following are examples of this property:

       RDATE:19970714T123000Z
       RDATE;TZID=America/New_York:19970714T083000

       RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
        19960404T010000Z/PT3H

       RDATE;VALUE=DATE:19970101,19970120,19970217,19970421,
                                                           ^
        19970526,19970704,19970901,19971014,19971128,19971129,19971225

Notes:

Comma missing at the fold boundary.


Errata ID: 3747

Status: Verified
Type: Editorial

Reported By: Alfie John
Date Reported: 2013-10-09
Verifier Name: Barry Leiba
Date Verified: 2013-10-26

Section 3.3.10 says:

   +----------+--------+--------+-------+-------+------+-------+------+
   |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note 2|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
   +----------+--------+--------+-------+-------+------+-------+------+

      Note 1:  Limit if BYMONTHDAY is present; otherwise, special expand
               for MONTHLY.

      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present; otherwise,
               special expand for WEEKLY if BYWEEKNO present; otherwise,
               special expand for MONTHLY if BYMONTH present; otherwise,
               special expand for YEARLY.

It should say:

   +----------+--------+--------+-------+-------+------+-------+------+
   |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A    |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note 2|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
   +----------+--------+--------+-------+-------+------+-------+------+
   |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
   +----------+--------+--------+-------+-------+------+-------+------+

      Note 1:  Limit if BYMONTHDAY is present; otherwise, special expand
               for MONTHLY.

      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present; otherwise,
               special expand for YEARLY.

Notes:

The change is to "Note 2":
Removed WEEKLY and MONTHLY clause as Note 2 only applies to FREQ = YEARLY.


Status: Held for Document Update (2)

RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Source of RFC: calsify (app)

Errata ID: 3038

Status: Held for Document Update
Type: Technical

Reported By: Brent Bloxam
Date Reported: 2011-11-30
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-12-06

Section 3.8.7.2 says:

Value Type:  DATE-TIME

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property MUST be included in the "VEVENT",
      "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

   Description:  The value MUST be specified in the UTC time format.

      This property is also useful to protocols such as [2447bis] that
      have inherent latency issues with the delivery of content.  This
      property will assist in the proper sequencing of messages
      containing iCalendar objects.

It should say:

Value Type:  DATE-TIME. The time value MUST be in the DATE WITH UTC
      TIME form defined for the DATE-TIME value type.

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property MUST be included in the "VEVENT",
      "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

   Description:  This property is also useful to protocols such as
      [2447bis] that have inherent latency issues with the delivery of
      content.  This property will assist in the proper sequencing of
      messages containing iCalendar objects.

Notes:

Application of the DATE-TIME value type is inconsistent in the RFC, and can lead to ambiguity since DATE-TIME can take on three different forms. The wording for the corrected Value Type for DTSTAMP is similar to the DTSTART property's Value Type. This is to make it clear that the only acceptable form is DATE WITH UTC TIME. You can also see evidence of defining specificity inline with the Value Type in the GEO property.

The spec author comments: "To improve consistency, we should modify Section 3.8.7.2. Date-Time Stamp and Section 3.8.7.3. Last Modified to use the same phrasing as Section 3.8.7.1. Date-Time Created and Section 3.8.2.1. Date-Time Completed."


Errata ID: 2495

Status: Held for Document Update
Type: Editorial

Reported By: Scott Furry
Date Reported: 2010-08-21
Held for Document Update by: Peter Saint-Andre

Section 3.2.7 says:

Description: This property parameter identifies the inline encoding
    used in a property value.  The default encoding is "8BIT",
    corresponding to a property value consisting of text.  The
    "BASE64" encoding type corresponds to a property value encoded
    using the "BASE64" encoding defined in [RFC2045].


It should say:

Description: This property parameter identifies the inline encoding
    used in a property value.  The default encoding is "8BIT",
    corresponding to a property value consisting of text.  The
    "BASE64" encoding type corresponds to a property value encoded
    using the "BASE64" encoding defined in [RFC4648].
                                            ^^^^^^^

Notes:

Section "Format Definition" above the "Description" paragraph cites [RFC2045] as defining value "8BIT" and [RFC4648] covering value "BASE64".


Status: Rejected (3)

RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", September 2009

Source of RFC: calsify (app)

Errata ID: 2676

Status: Rejected
Type: Technical

Reported By: Dennis Gearon
Date Reported: 2010-12-20
Rejected by: Alexey Melnikov
Date Rejected: 2011-01-20

Section 3.6.1 says:

                  ; The following are OPTIONAL,
                  ; but MUST NOT occur more than once.
                  ;
                  class / created / description / geo /
                  last-mod / location / organizer / priority /
                  seq / status / summary / transp /
                  url / recurid /
                  ;
                  ; The following is OPTIONAL,
                  ; but SHOULD NOT occur more than once.
                  ;
                  rrule /
                  ;
                  ; Either 'dtend' or 'duration' MAY appear in
                  ; a 'eventprop', but 'dtend' and 'duration'
                  ; MUST NOT occur in the same 'eventprop'.
                  ;
                  dtend / duration /
                  ;
                  ; The following are OPTIONAL,
                  ; and MAY occur more than once.
                  ;
                  attach / attendee / categories / comment /
                  contact / exdate / rstatus / related /
                  resources / rdate / x-prop / iana-prop
                  ^^^^^^^^^
                  ;

It should say:

                  ; The following are OPTIONAL,
                  ; but MUST NOT occur more than once.
                  ;
                  class / created / description / geo /
                  last-mod / location / organizer / priority /
                  seq / status / summary / transp /
                  url / recurid / resources 
                                  ^^^^^^^^^
                  ;
                  ; The following is OPTIONAL,
                  ; but SHOULD NOT occur more than once.
                  ;
                  rrule /
                  ;
                  ; Either 'dtend' or 'duration' MAY appear in
                  ; a 'eventprop', but 'dtend' and 'duration'
                  ; MUST NOT occur in the same 'eventprop'.
                  ;
                  dtend / duration /
                  ;
                  ; The following are OPTIONAL,
                  ; and MAY occur more than once.
                  ;
                  attach / attendee / categories / comment /
                  contact / exdate / rstatus / related /
                  rdate / x-prop / iana-prop
                  ;

Notes:

As per the definition of 'RESOURCES' in section 3.8.1.10,:

Conformance: This property can be specified once in "VEVENT" or
"VTODO" calendar component.

The text in the "VEVENT" definition has RESOURCES in the 'Option and MAY occur more than once.' section. The corrected text above corrects both sections;

1/ It is removed from the 'OPTIONAL/MAY occure more than once section.
2/ It is placed at the end of the 'OPTIONAL/MUST NOT occur more than once section.
--VERIFIER NOTES--
The correct fix is listed in Erratum 2677 which was approved.


Errata ID: 3405

Status: Rejected
Type: Technical

Reported By: Peter Hermann
Date Reported: 2012-11-09
Rejected by: Barry Leiba
Date Rejected: 2012-11-09

Section 3.3.10. says:

       weekday     = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
       ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
       ;FRIDAY, and SATURDAY days of the week.

It should say:

       weekday     = "MO" / "TU" / "WE" / "TH" / "FR" / "SA" / "SU"
       ;Corresponding to MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,
       ;SATURDAY, and SUNDAY days of the week.

Notes:

It is worldwide accepted that a working business week begins with
a monday in all business related activities (stock exchange etc. etc).

See also:
package Ada.Calendar.Formatting is
-- Day of the week:
type Day_Name is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
--VERIFIER NOTES--
This isn't an error in the document. Regardless of your opinion of whether the week should begin on Sunday, Monday, or Thursday, ABNF does not create any particular ordering. Implementations are always free to order them as they please.


Errata ID: 3457

Status: Rejected
Type: Editorial

Reported By: Johannes Raggam
Date Reported: 2013-01-16
Rejected by: Barry Leiba
Date Rejected: 2013-01-16

Section 3.2 says:

Property parameter values that contain the COLON, SEMICOLON, or COMMA
character separators MUST be specified as quoted-string text values.

It should say:

Property parameter values that contain the COLON, SEMICOLON, COMMA or
SPACE character separators MUST be specified as quoted-string text
values.

Notes:

Section "3.2.2. Common Name" gives an example with an double-quoted parameter value with a SPACE in it:

ORGANIZER;CN="John Smith":mailto:jsmith@example.com
--VERIFIER NOTES--
That example also shows a double-quoted parameter value with a "J" in it, but that doesn't mean that values that contain "J" MUST be quoted. Examples are just examples, and any value MAY be quoted.

The ABNF is the definitive source. The ABNF at the bottom of page 10 and top of page 11 (Section 3.1) says that non-quoted values may contain any number of characters from the SAFE-CHAR set, and that set includes WSP (SP and HTAB; see RFC 5234). Quoting is not required on account of space characters.


Report New Errata