Skip to main content

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