RFC Errata
Found 4 records.
Status: Verified (3)
RFC 5546, "iCalendar Transport-Independent Interoperability Protocol (iTIP)", December 2009
Note: This RFC has been updated by RFC 6638
Source of RFC: calsify (app)
Errata ID: 2097
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bernard Desruisseaux
Date Reported: 2010-03-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21
Section 3.4.6 says:
+--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | | | | | ... | | | | | | | | ORGANIZER | 0 | |
It should say:
+--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | | | | | ... | | | | | | | | ORGANIZER | 1 | |
Notes:
The "ORGANIZER" property should be REQUIRED in "VTODO" calendar components with the "REFRESH" method.
Errata ID: 2331
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Filip Navara
Date Reported: 2010-07-15
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26
Section 3.4. says:
| REPLY | Reply to a VTODO request. Attendees MAY set | | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | | | DELEGATED, PARTIAL, and COMPLETED. |
It should say:
| REPLY | Reply to a VTODO request. Attendees MAY set | | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | | | DELEGATED, IN-PROCESS, and COMPLETED. |
Notes:
The PARTSTAT value for VTODO component that is in progress is IN-PROCESS, not PARTIAL, per RFC 5545.
Errata ID: 3932
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfie John
Date Reported: 2014-03-25
Verifier Name: Barry Leiba
Date Verified: 2014-03-28
Section 3.1.2 says:
| DAYLIGHT | 0+ | MUST be one or more of either | | | | STANDARD or DAYLIGHT. | | COMMENT | 0+ | | | DTSTART | 1 | MUST be local time format. | | RDATE | 0+ | | | RRULE | 0 or 1 | | | TZNAME | 0+ | |
It should say:
| DAYLIGHT | 0+ | MUST be one or more of either | | | | STANDARD or DAYLIGHT. | | COMMENT | 0+ | | | DTSTART | 1 | MUST be local time format. | | RDATE | 0+ | If present, RRULE MUST NOT be | | | | present | | RRULE | 0 or 1 | If present, RDATE MUST NOT be | | | | present | | TZNAME | 0+ | |
Notes:
The corrected text appeared in RFC 2446, however I couldn't find the reasoning as to why it was omitted in RFC 5546.
The correct comments also appear a few lines below, under "STANDARD".
Status: Rejected (1)
RFC 5546, "iCalendar Transport-Independent Interoperability Protocol (iTIP)", December 2009
Note: This RFC has been updated by RFC 6638
Source of RFC: calsify (app)
Errata ID: 3037
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Praveen Bhamidipati
Date Reported: 2011-11-30
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-30
Section 3.1.3 says:
| DURATION | 0 or 1 | If present, REPEAT MUST be | | | | present. | | REPEAT | 0 or 1 | If present, DURATION MUST be | | | | present. |
It should say:
| DURATION | 0 or 1 | If present, DURATION MUST be | | | | present. | | REPEAT | 0 or 1 | If present, REPEAT MUST be | | | | present. |
Notes:
Currently, the Component/Property doesn't match the term used in Comment. That needs to be corrected.
--VERIFIER NOTES--
Per discussion on the ietf-calsify list, this report simply misunderstands the intent of the document and is clearly false.