Subject: [Ietf-calsify] Agenda, IETF71

From: Aki Niemi <[email-masked]>
Date: Fri, 29 Feb 2008 08:46:40 +0200

Hi,

Here's the WG session agenda for IETF71:
http://www.ietf.org/proceedings/08mar/agenda/calsify.txt

If you have any comments on the agenda, please bug the chairs.

Cheers,
Aki

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Aki Niemi <[email-masked]>
To: "[email-masked]" <[email-masked]>
Organization: Nokia Devices R&D
Date: Fri, 29 Feb 2008 08:46:40 +0200
Subject: [Ietf-calsify] Agenda, IETF71

Hi,

Here's the WG session agenda for IETF71:
http://www.ietf.org/proceedings/08mar/agenda/calsify.txt

If you have any comments on the agenda, please bug the chairs.

Cheers,
Aki

Date: Wed, 27 Feb 2008 16:13:44 -0800
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: deadline for open issues for rfc2446bis approaches

Dear all,

March 1 is the deadline for new issues to draft-ietf-calsify-2446bis.  
Please send any such issues to the list.

Thanks,

Eliot

To: [email-masked]
From: [email-masked]
Date: Sun, 24 Feb 2008 19:00:02 -0800 (PST)
Cc: [email-masked]
Subject: [Ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-05.txt 

--NextPart

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-05.txt
	Pages           : 123
	Date            : 2008-02-24

This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between
different calendar 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
calendar systems.  These scheduling methods permit two or more
calendar 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-05.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-calsify-2446bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-2446bis-05.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-2446bis-05.txt

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

Content-Type: text/plain
Content-ID: <2008-02-24185725.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Date: Mon, 11 Feb 2008 08:37:04 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] [Fwd: CALSIFY - Requested session has been scheduled for IETF 71]

This is a multi-part message in MIME format.
--------------070308050905000202050706
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Our agenda will focus on RFC2446bis.

Eliot

--------------070308050905000202050706
Content-Type: message/rfc822;
	name="CALSIFY - Requested session has been scheduled for IETF 71.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename*0="CALSIFY - Requested session has been scheduled for IETF
	71.e"; filename*1="ml"

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]
From: IETF Secretariat <[email-masked]>
Subject: CALSIFY - Requested session has been scheduled for IETF 71 
Date: Sat,  9 Feb 2008 01:01:01 -0800 (PST)

Dear Eliot Lear,

The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by 
the information of sessions that you have requested.

CALSIFY Session 1 (2 hours)
Tuesday, Afternoon Session II 1520-1720
Room Name: Breakout Room
----------------------------------------------

Requested Information:

---------------------------------------------------------
Working Group Name: calsify
Area Name: Applications Area
Session Requester: Eliot Lear

Number of Sessions: 1
Length of Session(s):  2 hours

Number of Attendees: 50
Conflicts to Avoid:
  First Priority:  apparea  lemonade sasl httpbis
  Second Priority: intarea saag v6ops
  BOF or IRTF Session: rrg

Special Requests:
  
---------------------------------------------------------

--------------070308050905000202050706--

To: [email-masked]
From: [email-masked]
Date: Thu,  7 Feb 2008 15:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt 

--NextPart

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		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-08.txt
	Pages		: 177
	Date		: 2008-2-6
	
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.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-rfc2445bis-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-08.txt

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

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

--OtherAccess--

--NextPart--

From: "Tim Hare" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, "'ietf-calsify'" <[email-masked]>
Subject: RE: [Ietf-calsify] VFREEBUSY REPLY's UID
Date: Tue, 5 Feb 2008 14:29:52 -0500

Are there implementations which do _not_ create VFREEBUSY in response to a
request, but rather maintain it separately? Those might just mail back a
copy of the (supposedly current) VFREEBUSY data for that entity, which would
already have a UID when the VFREEBUSY was created. 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Tuesday, February 05, 2008 1:13 PM
To: ietf-calsify
Subject: [Ietf-calsify] VFREEBUSY REPLY's UID

Hi folks,
In 2446 right now, when a VFREEBUSY REQUEST is responded to, the value for
the UID in the REPLY is not required to match the UID of REQUEST. Whereas
for VEVENTs, VTODOs, VJOURNALs the UID in the REPLY must match the UID in
the REQUEST.

So, should the UID in the VFREEBUSY REPLY match that in the REQUEST? i.e. 
is there a need to correlate the reply with the request?

Given that with iMIP there is no guarantee of processing order for
scheduling messages isn't it important to be able to match up VFREEBUSY
requests and replies?

Proposal: change 2446 to require that the UID in a VFREEBUSY REPLY matches
the UID in the REQUEST that caused the reply.

--
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Tue, 05 Feb 2008 10:13:09 -0800
From: Cyrus Daboo <[email-masked]>
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] VFREEBUSY REPLY's UID

Hi folks,
In 2446 right now, when a VFREEBUSY REQUEST is responded to, the value for 
the UID in the REPLY is not required to match the UID of REQUEST. Whereas 
for VEVENTs, VTODOs, VJOURNALs the UID in the REPLY must match the UID in 
the REQUEST.

So, should the UID in the VFREEBUSY REPLY match that in the REQUEST? i.e. 
is there a need to correlate the reply with the request?

Given that with iMIP there is no guarantee of processing order for 
scheduling messages isn't it important to be able to match up VFREEBUSY 
requests and replies?

Proposal: change 2446 to require that the UID in a VFREEBUSY REPLY matches 
the UID in the REQUEST that caused the reply.

-- 
Cyrus Daboo

From: Aki Niemi <[email-masked]>
To: ext Bernard Desruisseaux <[email-masked]>
Organization: Nokia
Date: Fri, 01 Feb 2008 10:32:01 +0200
Cc: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] Re: Chair review of draft-ietf-calsify-rfc2445bis

On to, 2008-01-31 at 23:29 -0500, ext Bernard Desruisseaux wrote:
> This issue was discussed during IETF-65.
> 
> Slide 7:
> http://www.ietf.org/proceedings/06mar/slides/calsify-1/sld7.htm
> 
> Minutes [From 03:08:46 to 03:15:38]:
> http://tools.ietf.org/wg/calsify/minutes?item=minutes65.html
> 
> Back then the idea was to remove these restrictions on mailto URI
> and to specify a set of URI types that should be allowed. Given
> that we never got around to define this set, I will simply remove
> the MUST specified for DELEGATED-TO and DELEGATED-FROM and rely
> only on cal-address definition.

That sounds good to me.

> > * Section 2, first sentence: RFC2119 doesn't have a "NOT RECOMMENDED"
> > key word. (Caught by I-D nits tool)
> 
> Check Errata ID 499.
> http://www.rfc-editor.org/errata.php
> 
> The idnits tool should be fixed to allow this.

True, I actually double-checked RFC2119 and still didn't find this key
word. But I suspect I did a search with NOT_RECOMMENDED... Too many
#defines that day, I guess... ;-)

Cheers,
Aki