Re: Chair review of draft-ietf-calsify-rfc2445bis

Hi Aki,

Aki Niemi wrote:
> All,
> 
> I've now reviewed RFC2445-bis, and am currently working on the PROTO
> writeup, which is a document that accompanies the draft as we request
> publication.
> 
> I'll also send some typos and such to Bernard privately.
> 
> Cheers,
> Aki
> 
> 
> Technical:
> ==========
> 
> * Sec 3.2.3: an implementation should treat an unrecognized CUTYPE value
> as UNKNOWN as opposed to INDIVIDUAL:
> 
>         OLD:
>         
>         Applications MUST treat x-name and iana-token value they don't
>         recognized the same way as the INDIVIDUAL value. 
>         
>         NEW:
>         
>         Applications MUST treat x-name and iana-token value they don't
>         recognized the same way as the UNKNOWN value. 

Re: dtstamp twice

Fixed.

Thanks,
Bernard

Mike Douglass wrote:
> Maybe corrected but draft 7 has dtstamp and uid both required and 
> optional for freebusy
> 
>                   ; the following are REQUIRED,
>                   ; but MUST NOT occur more than once
> 
>                   dtstamp / uid /
> 
>                   ; the following are OPTIONAL,
>                   ; but MUST NOT occur more than once
> 
>                   contact / dtstart / dtend / duration / dtstamp /
>                   organizer / uid / url /
> 
> 

Re: As long as we're talking about PARTSTAT...

Hi John,

John W Noerenberg II wrote:
>> At 2:08 PM -0800 1/21/08, John  W Noerenberg II wrote:
>>> IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent 
>>> UPDATE, then the REPLY should probably not be accepted. Do others 
>>> agree and should we clarify this?
> 
> Forgive me if I'm dragging out a dead horse...
> 
> Why do we have both PARTSTAT and RSVP parameters?  Is there ever a 
> condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and 
> not set RSVP=TRUE?

Here's one:

The "Organizer" of a VTODO is requesting an updated status from an 
"Attendee" that currently has PARTSTAT=IN-PROCESS. The "Attendee" will 
either reply with PARTSTAT=COMPLETED, or with PARTSTAT=IN-PROCESS with 
perhaps a greater PERCENT-COMPLETE value.

Cheers,
Bernard

> Is there ever a condition  where a CUA would omit 
> PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?
> 
> If it were up to me, I'd get rid of RSVP.  I know the RSVP parameter is 
> used.  In 2445bis and 2446bis, I'd say the RSVP parameter and it's value 
> have no semantic meaning.  It's presence in an ATTENDEE property is not 

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... 

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

RE: VFREEBUSY REPLY's UID

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: ietf-calsify-bounces <at> osafoundation.org
[mailto:ietf-calsify-bounces <at> osafoundation.org] 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.

I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt

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 
i-d-announce-request <at> ietf.org 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

[Fwd: CALSIFY - Requested session has been scheduled for IETF 71]

Our agenda will focus on RFC2446bis.

Eliot

From: IETF Secretariat <agenda <at> ietf.org>
Subject: CALSIFY - Requested session has been scheduled for IETF 71
Date: 2008-02-09 09:01:01 GMT

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

I-D Action:draft-ietf-calsify-2446bis-05.txt

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
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

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