Subject: [ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-09.txt

From: [email-masked]
Date: Sun, 19 Apr 2009 19:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title           : iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)       : C. Daboo
	Filename        : draft-ietf-calsify-2446bis-09.txt
	Pages           : 131
	Date            : 2009-04-19

This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between
different calendaring systems.  This is done without reference to a
specific transport protocol so as to allow multiple methods of
communication between systems.  Subsequent documents will define
profiles of this protocol using specific interoperable methods of
communications between systems.

iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current
calendaring systems.  These scheduling methods permit two or more
calendaring systems to perform transactions such as publish,
schedule, reschedule, respond to scheduling requests, negotiation of
changes or cancel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Apr 2009 14:45:31 -0400

Hi folks,
As you will have seen, draft-ietf-calsify-2446bis-09 has been submitted. 
This includes fixes for all of Reinhold's issues (except #105/106/107 which 
all relate to the same section).

-- 
Cyrus Daboo

Date: Thu, 30 Apr 2009 14:45:31 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-09.txt

Hi folks,
As you will have seen, draft-ietf-calsify-2446bis-09 has been submitted. 
This includes fixes for all of Reinhold's issues (except #105/106/107 which 
all relate to the same section).

-- 
Cyrus Daboo

Date: Wed, 29 Apr 2009 11:15:53 +0200
From: Eliot Lear <[email-masked]>
To: The IESG <[email-masked]>
Cc: calsify mailing list <[email-masked]>, Internet Architecture Board <[email-masked]>, IETF-Announce <[email-masked]>, Bernard Desruisseaux <[email-masked]>, calsify chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Re: [ietf-calsify] Protocol Action: 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)' to Proposed Standard

Dear all,

I'd like to congratulate the working group and Bernard Desruisseaux in 
particular on this event.

Warmest regards,

Eliot

On 4/28/09 6:20 PM, The IESG wrote:
> The IESG has approved the following document:
>
> - 'Internet Calendaring and Scheduling Core Object Specification
>     (iCalendar) '
>     <draft-ietf-calsify-rfc2445bis-10.txt>  as a Proposed Standard
>
> This document is the product of the Calendaring and Scheduling Standards
> Simplification Working Group.
>
> The IESG contact persons are Lisa Dusseault and Alexey Melnikov.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-10.txt
>
> 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<[email-masked]>
>
> Responsible AD: Lisa Dusseault<[email-masked]>
>
> The IANA Expert(s) for the registries in this document are Cyrus Daboo
> and Bernard Desruisseaux.
>
>
> Note to RFC Editor
>
> Please ensure that the ABNF is valid, including semi-colons or explicit
> spaces in empty lines within rules.
>
> OLD in section 3.2.19:
>
>        The parameter MUST be specified on properties with a DATE-TIME
>        value if the DATE-TIME is not either a UTC or a "floating" time.
>
> NEW:
>
>        The parameter MUST be specified on properties with a DATE-TIME
>        value if the DATE-TIME is not either a UTC or a "floating" time.
>    Failure to include and follow VTIMEZONE definitions in iCalendar
>    objects may lead to inconsistent understanding of the local time at any
>    given location.
>

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Tue, 28 Apr 2009 09:20:54 -0700 (PDT)
Cc: calsify mailing list <[email-masked]>, Internet Architecture Board <[email-masked]>, calsify chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: [ietf-calsify] Protocol Action: 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)' to Proposed Standard

The IESG has approved the following document:

- 'Internet Calendaring and Scheduling Core Object Specification 
   (iCalendar) '
   <draft-ietf-calsify-rfc2445bis-10.txt> as a Proposed Standard

This document is the product of the Calendaring and Scheduling Standards 
Simplification Working Group. 

The IESG contact persons are Lisa Dusseault and Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-10.txt

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 <[email-masked]>

Responsible AD: Lisa Dusseault <[email-masked]>

The IANA Expert(s) for the registries in this document are Cyrus Daboo
and Bernard Desruisseaux.

Note to RFC Editor

Please ensure that the ABNF is valid, including semi-colons or explicit
spaces in empty lines within rules.

OLD in section 3.2.19:

      The parameter MUST be specified on properties with a DATE-TIME
      value if the DATE-TIME is not either a UTC or a "floating" time.

NEW:

      The parameter MUST be specified on properties with a DATE-TIME
      value if the DATE-TIME is not either a UTC or a "floating" time.
  Failure to include and follow VTIMEZONE definitions in iCalendar
  objects may lead to inconsistent understanding of the local time at any
  given location.

From: [email-masked]
To: [email-masked]
Date: Sun, 19 Apr 2009 22:45:01 -0700 (PDT)
Cc: [email-masked]
Subject: [ietf-calsify] I-D Action:draft-ietf-calsify-rfc2445bis-10.txt

--NextPart

	Title           : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)       : B. Desruisseaux
	Filename        : draft-ietf-calsify-rfc2445bis-10.txt
	Pages           : 189
	Date            : 2009-04-19

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.Editorial Note (To be removed by
RFC Editor prior to publication)

This document is a product of the Calendaring and Scheduling
Standards Simplification (Calsify) working group of the Internet
Engineering Task Force.  Comments on this draft are welcomed, and
should be addressed to the [email-masked] [1] mailing
list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-10.txt

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Sun, 19 Apr 2009 19:45:01 -0700 (PDT)
Cc: [email-masked]
Subject: [ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-09.txt

--NextPart

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-calsify-2446bis-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Date: Thu, 02 Apr 2009 11:10:34 -0700
From: Ciny Joy <[email-masked]>
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-calsify] [Tc-caldav-l] FREEBUSY property in VFREEBUSY component

Hi Cyrus,
    Thank you for clarifying that!

Ciny

On 04/02/09 10:58, Cyrus Daboo wrote:
> Hi Ciny,
>
> --On April 2, 2009 10:56:18 AM -0700 Ciny Joy <[email-masked]> wrote:
>
>>    What is the minimum number of FREEBUSY property fields required in a
>> VFREEBUSY component? 0 or 1? iTIP says 1+
>> (http://tools.ietf.org/html/rfc2446#section-3.3.3) but Calsify says 0+
>> (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.3.3). 
>>
>>     If it is 1, what should a FREEBUSY response look like if there are
>> no events that take up time, during the time period? A freebusy property
>> of type FREE for the entire slot?
>>     Today our server gives a response validation error on the following
>> response. Wondering if it is valid.
>
> We (calsify) have decided that the original "1+" value was wrong, 
> hence the change to "0+". I would suggest you change your 
> implementation accordingly.

Date: Thu, 02 Apr 2009 13:58:40 -0400
From: Cyrus Daboo <[email-masked]>
To: Ciny Joy <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-calsify] [Tc-caldav-l] FREEBUSY property in VFREEBUSY component

Hi Ciny,

--On April 2, 2009 10:56:18 AM -0700 Ciny Joy <[email-masked]> wrote:

>    What is the minimum number of FREEBUSY property fields required in a
> VFREEBUSY component? 0 or 1? iTIP says 1+
> (http://tools.ietf.org/html/rfc2446#section-3.3.3) but Calsify says 0+
> (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.3.3).
>     If it is 1, what should a FREEBUSY response look like if there are
> no events that take up time, during the time period? A freebusy property
> of type FREE for the entire slot?
>     Today our server gives a response validation error on the following
> response. Wondering if it is valid.

We (calsify) have decided that the original "1+" value was wrong, hence the 
change to "0+". I would suggest you change your implementation accordingly.

-- 
Cyrus Daboo

Date: Thu, 02 Apr 2009 10:56:18 -0700
From: Ciny Joy <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: [ietf-calsify] FREEBUSY property in VFREEBUSY component

Hi,
   What is the minimum number of FREEBUSY property fields required in a 
VFREEBUSY component? 0 or 1? iTIP says 1+ 
(http://tools.ietf.org/html/rfc2446#section-3.3.3) but Calsify says 0+ 
(http://tools.ietf.org/html/draft-ietf-calsify-2446bis-08#section-3.3.3).
    If it is 1, what should a FREEBUSY response look like if there are 
no events that take up time, during the time period? A freebusy property 
of type FREE for the entire slot?
    Today our server gives a response validation error on the following 
response. Wondering if it is valid.

HTTP/1.0 200
Date: Tue, 31 Mar 2009 00:22:34 GMT
Content-type: application/xml; charset=UTF-8
Content-length: 729
Last-modified: Tue, 31 Mar 2009 00:22:34 GMT
Pragma: no-cache
Expires: 0
Cache-Control: no-cache

<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
       xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
 <C:recipient>
   <D:href>mailto:[email-masked]</D:href>
 </C:recipient>
 <C:request-status>2.0;Success</C:request-status>
 <C:calendar-data>BEGIN:VCALENDAR
PRODID:-//Sun/Calendar Server//EN
VERSION:2.0
METHOD:REPLY
BEGIN:VFREEBUSY
DTSTAMP:20040901T200200Z
ORGANIZER;mailto:[email-masked]
DTSTART:20090902T000000Z
DTEND:20090903T000000Z
UID:[email-masked]
ATTENDEE;CN="Praveen1 CN":mailto:[email-masked]
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</C:response>
</C:schedule-response>

Thanks,
Ciny