Internet Calendaring and Scheduling Core Object Specification (iCalendar)
draft-ietf-calsify-rfc2445bis-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2009-07-30
|
10 | Lisa Dusseault | Appointing Cyrus Daboo and Bernard DesRuisseaux as expert reviewers |
2009-04-30
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-04-30
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-04-30
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-04-30
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-04-28
|
10 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-04-28
|
10 | (System) | IANA Action state changed to In Progress |
2009-04-28
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2009-04-28
|
10 | Cindy Morgan | IESG has approved the document |
2009-04-28
|
10 | Cindy Morgan | Closed "Approve" ballot |
2009-04-27
|
10 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss by Alexey Melnikov |
2009-04-27
|
10 | Alexey Melnikov | [Ballot discuss] |
2009-04-20
|
10 | Alexey Melnikov | [Ballot discuss] DISCUSS from Chris Newman, updated as per -10: Section 3.2.19 > ... An > individual "VTIMEZONE" calendar component MUST be … [Ballot discuss] DISCUSS from Chris Newman, updated as per -10: Section 3.2.19 > ... An > individual "VTIMEZONE" calendar component MUST be specified for > each unique "TZID" parameter value specified in the iCalendar > object. What happens if the TZID is one recognized by the system (perhaps because it begins with a "/"), and the system has a newer version of the rules for that VTIMEZONE element. What takes precedence? I would presume whichever ruleset is newer as that's most likely to achieve the intent of the human user. But the specification should make this clear. |
2009-04-20
|
10 | Alexey Melnikov | [Ballot discuss] Carrying over DISCUSS from Chris Newman (Note that some of the issues below are COMMENT level): General: "local time" This term is used … [Ballot discuss] Carrying over DISCUSS from Chris Newman (Note that some of the issues below are COMMENT level): General: "local time" This term is used without being well defined. From my reading, "local time" is defined as any time which is not UTC or a fixed offset from UTC. It includes both specified local time (with a TZID) and floating local time (with no TZID). I believe the document would be much clearer if it distinguished these two cases consistently, perhaps by using separate terms (e.g., "specified local time" and "floating local time") consistently. I'm also concerned that the document is a bit lax about use of "floating local time". The cases where it usefully interoperates (2008-01-01T00:00:00 repeating annually is the only one that comes to mind) for multiple users are so few. Section 3.1.3 What is image/basic? This MIME type is not registered with IANA. Section 3.2 (in general) This section presents a lot of property parameters. But this gives me no idea of what a compliant implementation of iCalendar MUST or SHOULD do with the parameters to be compliant with this specification. Some of them are clearly fine to ignore (e.g., DIR=) while some of them will cause interoperability problems if not rendered to the end-user (e.g., DELEGATED-*). If the goal is to improve interoperability, I'd like to know what is expected of a complaint implementation for an iCalendar object for each of these parameters. Perhaps if we had statements like: Original Event Generation: OPTIONAL Event Reply Generation: OPTIONAL Event Reply Processing: MANDATORY to copy to original event UI Rendering: MANDATORY Where, for example, if it says "UI Rendering" then an implementation which renders events to a user is compliant with this specification if it does what's said there. This would make it clearer what a minimal implementation must do to interoperate. 3.2.7. Inline Encoding The example does not seem to be a valid JPG image preamble. 3.2.8. Format Type I don't understand how media type parameters can be distinguished from additional iCalendar property parameters. The ABNF seems ambiguous in context. Please explain. Section 3.2.19 > ... An > individual "VTIMEZONE" calendar component MUST be specified for > each unique "TZID" parameter value specified in the iCalendar > object. What happens if the TZID is one recognized by the system (perhaps because it begins with a "/"), and the system has a newer version of the rules for that VTIMEZONE element. What takes precedence? I would presume whichever ruleset is newer as that's most likely to achieve the intent of the human user. But the specification should make this clear. > The use of local time in a DATE-TIME or TIME value without the > "TZID" property parameter is to be interpreted as a local time > value, regardless of the existence of "VTIMEZONE" calendar > components in the iCalendar object. I do not understand what "local time value" means. Which local time? The local time of the system that generated the event? The local time of the system processing the event? How is this useful? How could this possibly interoperate? Section 3.3.10 In section 2 you say: > Note: All indented editorial notes, such as this one, are intended > to provide the reader with additional information. The > information is not essential to the building of an implementation and in this section you use "MUST" in a note. That's inconsistent. Either it's not a note or it makes no normative statements. |
2009-04-20
|
10 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-04-20
|
10 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
2009-04-20
|
10 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-04-19
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-04-19
|
10 | (System) | New version available: draft-ietf-calsify-rfc2445bis-10.txt |
2009-03-13
|
10 | Lisa Dusseault | Removed from agenda for telechat - 2009-04-16 by Lisa Dusseault |
2009-03-13
|
10 | Lisa Dusseault | Placed on agenda for telechat - 2009-04-16 by Lisa Dusseault |
2009-03-13
|
10 | Lisa Dusseault | Removed from agenda for telechat - 2009-04-02 by Lisa Dusseault |
2009-03-13
|
10 | Lisa Dusseault | Placed on agenda for telechat - 2009-04-02 by Lisa Dusseault |
2008-12-18
|
10 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2008-12-18
|
10 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-12-18
|
10 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-12-18
|
10 | Chris Newman | [Ballot comment] General: "local time" This term is used without being well defined. From my reading, "local time" is defined as any time which is … [Ballot comment] General: "local time" This term is used without being well defined. From my reading, "local time" is defined as any time which is not UTC or a fixed offset from UTC. It includes both specified local time (with a TZID) and floating local time (with no TZID). I believe the document would be much clearer if it distinguished these two cases consistently, perhaps by using separate terms (e.g., "specified local time" and "floating local time") consistently. I'm also concerned that the document is a bit lax about use of "floating local time". The cases where it usefully interoperates (2008-01-01T00:00:00 repeating annually is the only one that comes to mind) for multiple users are so few. Section 3.1.3 What is image/basic? Section 3.2 (in general) This section presents a lot of property parameters. But this gives me no idea of what a compliant implementation of iCalendar MUST or SHOULD do with the parameters to be compliant with this specification. Some of them are clearly fine to ignore (e.g., DIR=) while some of them will cause interoperability problems if not rendered to the end-user (e.g., DELEGATED-*). If the goal is to improve interoperability, I'd like to know what is expected of a complaint implementation for an iCalendar object for each of these parameters. Perhaps if we had statements like: Original Event Generation: OPTIONAL Event Reply Generation: OPTIONAL Event Reply Processing: MANDATORY to copy to original event UI Rendering: MANDATORY Where, for example, if it says "UI Rendering" then an implementation which renders events to a user is compliant with this specification if it does what's said there. This would make it clearer what a minimal implementation must do to interoperate. 3.2.7. Inline Encoding The example does not seem to be a valid JPG image preamble. 3.2.8. Format Type I don't understand how media type parameters can be distinguished from additional iCalendar property parameters. The ABNF seems ambiguous in context. Please explain. Section 3.2.19 > ... An > individual "VTIMEZONE" calendar component MUST be specified for > each unique "TZID" parameter value specified in the iCalendar > object. What happens if the TZID is one recognized by the system (perhaps because it begins with a "/"), and the system has a newer version of the rules for that VTIMEZONE element. What takes precedence? I would presume whichever ruleset is newer as that's most likely to achieve the intent of the human user. But the specification should make this clear. > The use of local time in a DATE-TIME or TIME value without the > "TZID" property parameter is to be interpreted as a local time > value, regardless of the existence of "VTIMEZONE" calendar > components in the iCalendar object. I do not understand what "local time value" means. Which local time? The local time of the system that generated the event? The local time of the system processing the event? How is this useful? How could this possibly interoperate? Section 3.3.10 In section 2 you say: > Note: All indented editorial notes, such as this one, are intended > to provide the reader with additional information. The > information is not essential to the building of an implementation and in this section you use "MUST" in a note. That's inconsistent. Either it's not a note or it makes no normative statements. I haven't finished my review yet, but I'm going to send this much out now to get discussions started. |
2008-12-18
|
10 | Chris Newman | [Ballot comment] This term is used without being well defined. From my reading, "local time" is defined as any time which is not UTC or … [Ballot comment] This term is used without being well defined. From my reading, "local time" is defined as any time which is not UTC or a fixed offset from UTC. It includes both specified local time (with a TZID) and floating local time (with no TZID). I believe the document would be much clearer if it distinguished these two cases consistently, perhaps by using separate terms (e.g., "specified local time" and "floating local time") consistently. I'm also concerned that the document is a bit lax about use of "floating local time". The cases where it usefully interoperates (2008-01-01T00:00:00 repeating annually is the only one that comes to mind) for multiple users are so few. Section 3.1.3 What is image/basic? Section 3.2 (in general) This section presents a lot of property parameters. But this gives me no idea of what a compliant implementation of iCalendar MUST or SHOULD do with the parameters to be compliant with this specification. Some of them are clearly fine to ignore (e.g., DIR=) while some of them will cause interoperability problems if not rendered to the end-user (e.g., DELEGATED-*). If the goal is to improve interoperability, I'd like to know what is expected of a complaint implementation for an iCalendar object for each of these parameters. Perhaps if we had statements like: Original Event Generation: OPTIONAL Event Reply Generation: OPTIONAL Event Reply Processing: MANDATORY to copy to original event UI Rendering: MANDATORY Where, for example, if it says "UI Rendering" then an implementation which renders events to a user is compliant with this specification if it does what's said there. This would make it clearer what a minimal implementation must do to interoperate. 3.2.7. Inline Encoding The example does not seem to be a valid JPG image preamble. 3.2.8. Format Type I don't understand how media type parameters can be distinguished from additional iCalendar property parameters. The ABNF seems ambiguous in context. Please explain. Section 3.2.19 > ... An > individual "VTIMEZONE" calendar component MUST be specified for > each unique "TZID" parameter value specified in the iCalendar > object. What happens if the TZID is one recognized by the system (perhaps because it begins with a "/"), and the system has a newer version of the rules for that VTIMEZONE element. What takes precedence? I would presume whichever ruleset is newer as that's most likely to achieve the intent of the human user. But the specification should make this clear. > The use of local time in a DATE-TIME or TIME value without the > "TZID" property parameter is to be interpreted as a local time > value, regardless of the existence of "VTIMEZONE" calendar > components in the iCalendar object. I do not understand what "local time value" means. Which local time? The local time of the system that generated the event? The local time of the system processing the event? How is this useful? How could this possibly interoperate? Section 3.3.10 In section 2 you say: > Note: All indented editorial notes, such as this one, are intended > to provide the reader with additional information. The > information is not essential to the building of an implementation and in this section you use "MUST" in a note. That's inconsistent. Either it's not a note or it makes no normative statements. I haven't finished my review yet, but I'm going to send this much out now to get discussions started. |
2008-12-18
|
10 | Chris Newman | [Ballot discuss] While this is a significant improvement over the original specification, I believe it still has many areas where it is unclear how to … [Ballot discuss] While this is a significant improvement over the original specification, I believe it still has many areas where it is unclear how to implement certain things, areas where the specification is inconsistent, areas where I'm there are interoperability issues and areas where it is unclear what features are mandatory-to-implement in order to have a compliant implementation of this specification. I believe this needs a revision focused on improvements in these areas. I'll include my review in the "IESG comments" field as it contains many non-discuss level issues that I feel may still be worth improvement. |
2008-12-18
|
10 | Chris Newman | [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman |
2008-12-18
|
10 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-12-18
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-18
|
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-12-18
|
10 | Pasi Eronen | [Ballot discuss] A question based on Richard Barnes's SecDir review: when using BINARY data type with in-line encoding, should the text say FMTTYPE MUST be … [Ballot discuss] A question based on Richard Barnes's SecDir review: when using BINARY data type with in-line encoding, should the text say FMTTYPE MUST be included (or SHOULD be included)? Or is the recipient supposed to guess semantics from e.g. file name extension or data contents? |
2008-12-18
|
10 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-12-17
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-12-17
|
10 | Amanda Baber | IANA's questions have been answered. |
2008-12-17
|
10 | Dan Romascanu | [Ballot comment] I support Magnus's DISCUSS based on Lars's comment about the reference to RFC1738. |
2008-12-17
|
10 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-12-17
|
10 | Magnus Westerlund | [Ballot comment] The ABNF is not formally correct: There are some multi-line rules containing empty lines, like calprops and many of the other props rules. … [Ballot comment] The ABNF is not formally correct: There are some multi-line rules containing empty lines, like calprops and many of the other props rules. I understand that this is for readability however, it is against the ABNF rules. I guess most text editors and the XML to RFC tool are against you in that they will strip the white spaces on the empty lines. Maybe try to get the RFC-editor to ensure that there are white spaces on the empty lines within rules. |
2008-12-17
|
10 | Magnus Westerlund | [Ballot discuss] I will take on Lars comment and keep that as a discuss. There is a normative reference to RFC 1738 that is an … [Ballot discuss] I will take on Lars comment and keep that as a discuss. There is a normative reference to RFC 1738 that is an obsoleted RFC. To my knowledge normative references is not allowed on a standards track document. Is it necessary to include these scheme identifiers? Can it be done in some other way that doesn't make it into a normative ref? |
2008-12-17
|
10 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-12-16
|
10 | Lars Eggert | [Ballot comment] Section 3.2.6., paragraph 5: > Description: This parameter can be specified on properties with a > CAL-ADDRESS value type. The … [Ballot comment] Section 3.2.6., paragraph 5: > Description: This parameter can be specified on properties with a > CAL-ADDRESS value type. The parameter specifies a reference to > the directory entry associated with the calendar user specified by > the property. The parameter value SHOULD be a CID [RFC2392], DATA > [RFC2397], FILE [RFC1738], FTP [RFC1738], HTTP [RFC2616], HTTPS > [RFC2818], LDAP [RFC4516], or MID [RFC2392] URI. The URI > parameter value MUST be specified in a quoted-string. What's the status of "file://" and "ftp://|? RFC1738 was obsoleted, and while "telnet://" and "gopher://" have been resurrected (RFC 4248, RFC 4266), I couldn't locate an RFC that did the same for these two. (Making this a comment, since I won't be on the call and I don't want to block.) |
2008-12-16
|
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2008-12-12
|
10 | Russ Housley | [Ballot comment] This minor error was caught in the Gen-ART Review by Gonzalo Camarillo: OLD: This property SHOULD not be used … [Ballot comment] This minor error was caught in the Gen-ART Review by Gonzalo Camarillo: OLD: This property SHOULD not be used to alter the interpretation of NEW: This property SHOULD NOT be used to alter the interpretation of |
2008-12-12
|
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-12-11
|
10 | Lisa Dusseault | Placed on agenda for telechat - 2008-12-18 by Lisa Dusseault |
2008-12-11
|
10 | Lisa Dusseault | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::Revised ID Needed by Lisa Dusseault |
2008-12-11
|
10 | Lisa Dusseault | [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault |
2008-12-11
|
10 | Lisa Dusseault | Ballot has been issued by Lisa Dusseault |
2008-12-11
|
10 | Lisa Dusseault | Created "Approve" ballot |
2008-12-02
|
10 | Lisa Dusseault | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Lisa Dusseault |
2008-11-25
|
10 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Richard Barnes. |
2008-11-24
|
10 | Amanda Baber | IANA comments: IANA has questions: - In section 3.3.10 you define recurrence rules; do you want a registry of rules? - In 3.3.10 you define … IANA comments: IANA has questions: - In section 3.3.10 you define recurrence rules; do you want a registry of rules? - In 3.3.10 you define the FREQ and INTERVAL tags, but never register them anywhere. - In Section 8.2.6 you define a "Values" registry, but you never populate it. What should be included in that registry? - In sections 8.3.5, 8.3.6, 8.3.7, 8.3.8, 8.3.9, 8.3.10, 8.3.11, and 8.3.12, you define the "Calendar User Types", "Free/Busy Time Types", "Participation Statuses", "Relationship Types", "Participation Roles", "Actions", "Classifications", and "Methods" registries, but you do not supply the allocation policies. Please verify that these registries have the same allocation policies as defined in section 8.2.1? - From Section 3.8.1.11, CONFIRMED, CANCELLED, DRAFT, and FINAL status values are not registered anywhere. - From Section 3.8.2.7, OPAQUE and TRANSPARENT properties are not registered anywhere. - From Section 3.2.13 and 3.8.4.4, THISANDFUTURE, COUNT, and UNTIL are not registered anywhere. - From Section 3.8.8.3, the Request Status codes are not registered anywhere. Action 1 (Section 8.1): Upon approval of this document, the IANA will make the following changes in "Text Media Types" registry located at http://www.iana.org/assignments/media-types/text/ OLD: text calendar [RFC2445] NEW: text calendar [RFC-calsify-rfc2445bis-09] Action 2 (Sections 8.2.2, 8.3.1): Upon approval of this document, the IANA will create the registry "Components" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +-----------+---------+------------------------+ | Component | Status | Reference | +-----------+---------+------------------------+ | VCALENDAR | Current | [RFC-calsify-rfc2445bis-09], Section 3.4 | | | | | | VEVENT | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.1 | | | | | | VTODO | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.2 | | | | | | VJOURNAL | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.3 | | | | | | VFREEBUSY | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.4 | | | | | | VTIMEZONE | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.5 | | | | | | VALARM | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.6 | | | | | | STANDARD | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.5 | | | | | | DAYLIGHT | Current | [RFC-calsify-rfc2445bis-09], Section 3.6.5 | +-----------+---------+------------------------+ Action 3 (Sections 8.2.3, 8.3.2): Upon approval of this document, the IANA will create the registry "Properties" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +------------------+------------+---------------------------+ | Property | Status | Reference | +------------------+------------+---------------------------+ | CALSCALE | Current | [RFC-calsify-rfc2445bis-09], Section 3.7.1 | | | | | | METHOD | Current | [RFC-calsify-rfc2445bis-09], Section 3.7.2 | | | | | | PRODID | Current | [RFC-calsify-rfc2445bis-09], Section 3.7.3 | | | | | | VERSION | Current | [RFC-calsify-rfc2445bis-09], Section 3.7.4 | | | | | | ATTACH | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.1 | | | | | | CATEGORIES | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.2 | | | | | | CLASS | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.3 | | | | | | COMMENT | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.4 | | | | | | DESCRIPTION | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.5 | | | | | | GEO | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.6 | | | | | | LOCATION | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.7 | | | | | | PERCENT-COMPLETE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.8 | | | | | | PRIORITY | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.9 | | | | | | RESOURCES | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.10 | | | | | | STATUS | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.11 | | | | | | SUMMARY | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.12 | | | | | | COMPLETED | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.1 | | | | | | DTEND | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.2 | | | | | | DUE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.3 | | | | | | DTSTART | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.4 | | | | | | DURATION | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.5 | | | | | | FREEBUSY | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.6 | | | | | | TRANSP | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.2.7 | | | | | | TZID | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.3.1 | | | | | | TZNAME | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.3.2 | | | | | | TZOFFSETFROM | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.3.3 | | | | | | TZOFFSETTO | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.3.4 | | | | | | TZURL | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.3.5 | | | | | | ATTENDEE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.1 | | | | | | CONTACT | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.2 | | | | | | ORGANIZER | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.3 | | | | | | RECURRENCE-ID | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.4 | | | | | | RELATED-TO | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.5 | | | | | | URL | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.6 | | | | | | UID | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.4.7 | | | | | | EXDATE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.5.1 | | | | | | EXRULE | Deprecated | RFC2445, Section 4.8.5.2 | | | | | | RDATE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.5.2 | | | | | | RRULE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.5.3 | | | | | | ACTION | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.6.1 | | | | | | REPEAT | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.6.2 | | | | | | TRIGGER | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.6.3 | | | | | | CREATED | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.7.1 | | | | | | DTSTAMP | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.7.2 | | | | | | LAST-MODIFIED | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.7.3 | | | | | | SEQUENCE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.7.4 | | | | | | REQUEST-STATUS | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.8.3 | +------------------+------------+---------------------------+ Action 4 (Sections 8.2.4, 8.3.3): Upon approval of this document, the IANA will create the registry "Parameters" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +----------------+---------+-------------------------+ | Parameter | Status | Reference | +----------------+---------+-------------------------+ | ALTREP | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.1 | | | | | | CN | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.2 | | | | | | CUTYPE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.3 | | | | | | DELEGATED-FROM | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.4 | | | | | | DELEGATED-TO | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.5 | | | | | | DIR | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.6 | | | | | | ENCODING | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.7 | | | | | | FMTTYPE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.8 | | | | | | FBTYPE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.9 | | | | | | LANGUAGE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.10 | | | | | | MEMBER | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.11 | | | | | | PARTSTAT | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | RANGE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.13 | | | | | | RELATED | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.14 | | | | | | RELTYPE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.15 | | | | | | ROLE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.16 | | | | | | RSVP | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.17 | | | | | | SENT-BY | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.18 | | | | | | TZID | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.19 | | | | | | VALUE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.20 | +----------------+---------+-------------------------+ Action 5 (Sections 8.2.5, 8.3.4): Upon approval of this document, the IANA will create the registry "Value Data Types" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +-----------------+---------+-------------------------+ | Value Data Type | Status | Reference | +-----------------+---------+-------------------------+ | BINARY | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.1 | | | | | | BOOLEAN | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.2 | | | | | | CAL-ADDRESS | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.3 | | | | | | DATE | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.4 | | | | | | DATE-TIME | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.5 | | | | | | DURATION | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.6 | | | | | | FLOAT | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.7 | | | | | | INTEGER | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.8 | | | | | | PERIOD | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.9 | | | | | | RECUR | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.10 | | | | | | TEXT | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.11 | | | | | | TIME | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.12 | | | | | | URI | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.13 | | | | | | UTC-OFFSET | Current | [RFC-calsify-rfc2445bis-09], Section 3.3.14 | +-----------------+---------+-------------------------+ Action 5 (Section 8.2.6): Upon approval of this document, the IANA will create the registry "Values" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: Values Status Reference ------ -------- ---------- Action 6 (Section 8.3.5): Upon approval of this document, the IANA will create the registry "Calendar User Types" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +--------------------+---------+------------------------+ | Calendar User Type | Status | Reference | +--------------------+---------+------------------------+ | INDIVIDUAL | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.3 | | | | | | GROUP | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.3 | | | | | | RESOURCE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.3 | | | | | | ROOM | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.3 | | | | | | UNKNOWN | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.3 | +--------------------+---------+------------------------+ Action 7 (Section 8.3.6): Upon approval of this document, the IANA will create the registry "Free/Busy Time Types" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +---------------------+---------+------------------------+ | Free/Busy Time Type | Status | Reference | +---------------------+---------+------------------------+ | FREE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.9 | | | | | | BUSY | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.9 | | | | | | BUSY-UNAVAILABLE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.9 | | | | | | BUSY-TENTATIVE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.9 | +---------------------+---------+------------------------+ Action 8 (Section 8.3.7): Upon approval of this document, the IANA will create the registry "Participation Statuses" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +--------------------+---------+-------------------------+ | Participant Status | Status | Reference | +--------------------+---------+-------------------------+ | NEEDS-ACTION | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | ACCEPTED | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | DECLINED | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | TENTATIVE | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | DELEGATED | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | COMPLETED | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | | | | | | IN-PROCESS | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.12 | +--------------------+---------+-------------------------+ Action 9 (Section 8.3.8): Upon approval of this document, the IANA will create the registry "Relationship Types" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +-------------------+---------+-------------------------+ | Relationship Type | Status | Reference | +-------------------+---------+-------------------------+ | CHILD | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.15 | | | | | | PARENT | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.15 | | | | | | SIBLING | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.15 | +-------------------+---------+-------------------------+ Action 10 (Section 8.3.9): Upon approval of this document, the IANA will create the registry "Participation Roles" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the regisration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +-----------------+---------+-------------------------+ | Role Type | Status | Reference | +-----------------+---------+-------------------------+ | CHAIR | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.16 | | | | | | REQ-PARTICIPANT | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.16 | | | | | | OPT-PARTICIPANT | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.16 | | | | | | NON-PARTICIPANT | Current | [RFC-calsify-rfc2445bis-09], Section 3.2.16 | +-----------------+---------+-------------------------+ Action 11 (Section 8.3.10): Upon approval of this document, the IANA will create the registry "Actions" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +-----------+------------+--------------------------+ | Action | Status | Reference | +-----------+------------+--------------------------+ | AUDIO | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.6.1 | | | | | | DISPLAY | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.6.1 | | | | | | EMAIL | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.6.1 | | | | | | PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 | +-----------+------------+--------------------------+ Action 12 (Section 8.3.11): Upon approval of this document, the IANA will create the registry "Classifications" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the regisration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: +----------------+---------+--------------------------+ | Classification | Status | Reference | +----------------+---------+--------------------------+ | PUBLIC | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.3 | | | | | | PRIVATE | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.3 | | | | | | CONFIDENTIAL | Current | [RFC-calsify-rfc2445bis-09], Section 3.8.1.3 | +----------------+---------+--------------------------+ Action 13 (Section 8.3.12): Upon approval of this document, the IANA will create the registry "Methods" at http://www.iana.org/assignments/TBD Registration of new iCalendar elements MUST be reviewed by the designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation statuses values to be used in "VEVENT" calendar components. A Standards Track RFC is also REQUIRED for registration of iCalendar elements that modify iCalendar elements previously documented in a Standards Track RFC. Initial contents of this registry will be: Method Status Reference ------- -------- ------------- We understand the above to be the only IANA Actions for this document. |
2008-11-18
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-11-11
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2008-11-11
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2008-11-04
|
10 | Cindy Morgan | Last call sent |
2008-11-04
|
10 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2008-11-04
|
10 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2008-11-04
|
10 | (System) | Ballot writeup text was added |
2008-11-04
|
10 | (System) | Last call text was added |
2008-11-04
|
10 | (System) | Ballot approval text was added |
2008-11-04
|
10 | Lisa Dusseault | State Changes to Last Call Requested from AD Evaluation::AD Followup by Lisa Dusseault |
2008-10-31
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-10-31
|
09 | (System) | New version available: draft-ietf-calsify-rfc2445bis-09.txt |
2008-07-02
|
10 | Lisa Dusseault | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Lisa Dusseault |
2008-05-29
|
10 | Lisa Dusseault | State Changes to AD Evaluation from Publication Requested by Lisa Dusseault |
2008-05-29
|
10 | Lisa Dusseault | Intended Status has been changed to Proposed Standard from Draft Standard |
2008-05-19
|
10 | Lisa Dusseault | PROTO questionnaire for: draft-ietf-calsify-rfc2445bis-08 prepared by: Aki Niemi , current co-chair of the Calsify WG. He has reviewed this version of the document (as well … PROTO questionnaire for: draft-ietf-calsify-rfc2445bis-08 prepared by: Aki Niemi , current co-chair of the Calsify WG. He has reviewed this version of the document (as well as a number of previous versions) and believes it to be ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The working group has performed extensive review of the document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No such concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No; those issues have been resolved since the review. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus behind this document. During progressing the draft, the working group employed an issue tracking system to which over 70 issues were collected, tracked, and ultimately closed as consensus on them was reached. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are appropriately split, and none of the normative references are pending approval, or that are downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Yes. No designated expert has been named yet. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF defined in the document was ran through the ABNF checker at http://rtg.ietf.org/~fenner/abnf.cgi that produced no errors. (Certain differences between the tool's canonical output and the original ABNF were found, most of which result from elements being defined that are only referenced from text and not used anywhere else within the ANBF.) (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries and free/busy information, independent of any particular calendar service or protocol. Working Group Summary The working group proceeded with the work in an orderly fashion, opening tickets for all the found issues in the original RFC2445, and then systematically closing them until no known issues remained. Document Quality There are a number of existing implementations of the original RFC2445 specification that are likely to upgrade their implementation to the new specification. During the process of developing this document, the CalConnect.org industry consortium provided various types of vendor feedback and errata over the original specification. The working group took special care to take into account this feedback as well as the feedback received from a number of other contributors, some of which are also mentioned in the document's Acknowledgements section. Personnel Document Shepherd: Aki Niemi Responsible AD: Lisa Dusseault The IANA Expert(s) for the registries in this document are . |
2008-05-19
|
10 | Lisa Dusseault | Draft Added by Lisa Dusseault in state Publication Requested |
2008-02-07
|
08 | (System) | New version available: draft-ietf-calsify-rfc2445bis-08.txt |
2007-07-09
|
07 | (System) | New version available: draft-ietf-calsify-rfc2445bis-07.txt |
2007-03-05
|
06 | (System) | New version available: draft-ietf-calsify-rfc2445bis-06.txt |
2007-01-30
|
05 | (System) | New version available: draft-ietf-calsify-rfc2445bis-05.txt |
2007-01-17
|
04 | (System) | New version available: draft-ietf-calsify-rfc2445bis-04.txt |
2006-10-25
|
03 | (System) | New version available: draft-ietf-calsify-rfc2445bis-03.txt |
2006-10-11
|
02 | (System) | New version available: draft-ietf-calsify-rfc2445bis-02.txt |
2006-06-23
|
01 | (System) | New version available: draft-ietf-calsify-rfc2445bis-01.txt |
2005-10-26
|
00 | (System) | New version available: draft-ietf-calsify-rfc2445bis-00.txt |