Calendaring and Scheduling

Bernard Desruisseaux | 13 Jul 2007 21:57

[Fwd: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt]

The Calsify WG Chairs have issued a Working Group Last Call on
draft-ietf-calsify-rfc2445bis-07.txt (i.e., the revision of
iCalendar).  See:

http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001762.html

People interested to know exactly what was changed in RFC 2445
can look at the following annotated version of the draft:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html

Please send your comments to the ietf-calsify <at> osafoundation.org
mailing list before August 10th, 2007.

Cheers,
Bernard

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt
Date: Mon, 09 Jul 2007 17:15:01 -0400
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org
CC: ietf-calsify <at> osafoundation.org

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.

(Continue reading)

headers

pregen | 4 Sep 2003 22:40

Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]


Doug, from what I read on Frank and Derik's replies and on other peoples
comments on the list, I see a pattern evolving.  People are coding their
applications using more of a fixed model.  Why do we have to have a
complicated draft when all we need to do is remove the one sentence in
3.7.1, change examples to reflect that change and resubmit the draft.

So, my question to everyone on the list that has been active on the
Recurrence-ID issue - does this sound like too simplistic an approach?  Am
I missing something.  The arguments seem to lean towards Bruce's comments
and attempt at a model.  His borad summary
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

                                                                                                                          
                      Doug Royer                                                                                          
                      <Doug <at> royer.com>             To:       "ietf-calendar <at> imc.org" <ietf-calendar <at> imc.org>,             
                      Sent by:                      "ietf-calendar <at> imc.org" <ietf-calendar <at> imc.org>                       
                      owner-ietf-calendar <at> m        cc:                                                                    
                      ail.imc.org                  Subject:  [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]                

                                                                                                                          
                      09/04/2003 03:17 PM                                                                                 

This is an attempt to start documenting all of the RECURRENCE-ID issues.
In -00 I did not represent the 'FIXED' camp very well as I do
not fully understand it and so it is missing examples.

(Continue reading)

headers

Doug Royer | 4 Sep 2003 22:48

Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]

pregen <at> egenconsulting.com wrote:
> 
> 
> 
> 
> Doug, from what I read on Frank and Derik's replies and on other peoples
> comments on the list, I see a pattern evolving.  People are coding their
> applications using more of a fixed model.  Why do we have to have a
> complicated draft when all we need to do is remove the one sentence in
> 3.7.1, change examples to reflect that change and resubmit the draft.
 >
> So, my question to everyone on the list that has been active on the
> Recurrence-ID issue - does this sound like too simplistic an approach?  Am
> I missing something.  The arguments seem to lean towards Bruce's comments
> and attempt at a model.  His borad summary

When you read what I put in the draft, not all of the 'fixed' camp agree
on all of the details.  And they are NOT compatible with each other.

I have a list that I am not confident to send out yet as I re-read
the examples sent. It looks as if there are 4 distinct models and
not 2. This list will be included in the next rev of that draft.

Its not as simple as 'fixed' vs. 'non-fixed' which is one of the
points of the draft.

--

-- 

  Doug Royer                     |   http://INET-Consulting.com

(Continue reading)

headers

Michael Fair | 5 Sep 2003 00:28

Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]


> > Doug, from what I read on Frank and Derik's replies and on other peoples
> > comments on the list, I see a pattern evolving.  People are coding their
> > applications using more of a fixed model.  Why do we have to have a
> > complicated draft when all we need to do is remove the one sentence in
> > 3.7.1, change examples to reflect that change and resubmit the draft.
>  >
> > So, my question to everyone on the list that has been active on the
> > Recurrence-ID issue - does this sound like too simplistic an approach?
> > Am I missing something.  The arguments seem to lean towards Bruce's
> > comments and attempt at a model.

That is certainly a step in the right direction and would clear
up the blatant conflicts.

However there are other areas too.
Off the top of my head:

"Bad Recurrence-ID" needs to be expanded to include a fourth
possibility; that it has never seen neither the base UID nor
the RECURRENCE-ID before.

The "may be" in "so that each instance may be both sequence
and versioned" needs to be changed to "is" I don't recall the
section offhand.  This needs to make it explcit that the
SEQUENCE value for each instance is tracked independently
and that they do not share a common SEQUENCE counter.

Somehow it needs to be made clear that every relevant reference
to "UID" throughout the document really means something more

(Continue reading)

headers

Bruce_Kahn | 5 Sep 2003 20:55

Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]

Michael replied on 09/04/2003 06:28:40 PM:
> "Bad Recurrence-ID" needs to be expanded to include a fourth
> possibility; that it has never seen neither the base UID nor
> the RECURRENCE-ID before.

Isn't that already covered by:

If the "UID" property value in
the "REQUEST" is not found on the recipient's calendar, then the
"REQUEST" is for a new "VEVENT" calendar component.

(factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in place of UID when dealing with recurring instances per Section 2.1.5)?

> Somehow it needs to be made clear that every relevant reference
> to "UID" throughout the document really means something more
> along the lines of "primary key" which could include UID,
> RECURRENCE-ID, and RANGE to accurately identify which events
> are being referred to. Much of the confusion here has been
> as a result of interpretting "UID" to not mean all of those.

Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's meaning) would be useful?

> Making it clear that when canceling an event for a particular
> user the SEQUENCE value should not be incremented (or at least
> more discussion on what it should do).

While this is a good change, exactly how to do it is another matter. The problem is that this change is that it will effect all implementations already out there that follow that text from Section 2.1.4. Just making the change could mean interoperability issues w/existing implementations and no way to detect it.

Bruce
===========================================================================
Bruce Kahn INet: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration Phone: 978.399.6496
IBM Software Group FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

headers

Michael Fair | 5 Sep 2003 22:21

Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]


> > "Bad Recurrence-ID" needs to be expanded to include a fourth
> > possibility; that it has never seen neither the base UID nor
> > the RECURRENCE-ID before.
>
> Isn't that already covered by:
>
>                                  If the "UID" property value in
>    the "REQUEST" is not found on the recipient's calendar, then the
>    "REQUEST" is for a new "VEVENT" calendar component.
>
> (factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in
> place of UID when dealing with recurring instances per Section 2.1.5)?

What to do is handled, but it's the actual text of 4.7.2 that
bothers me.

Section 4.7.2 Bad RECURRENCE-ID says:
 ... there are three cases in which an instance cannot be found. ...

It then talks about finding the "UID" but then either not
finding the RID or having problems with the SEQUENCE value.

This isn't true.  There are four cases.  The fourth case being
that neither the UID nor the RID have ever been seen before.
A simple reference to "Do what 2.1.5 says" would suffice, but
the declaration that there are only three cases can be confusing.

> > Somehow it needs to be made clear that every relevant reference
> > to "UID" throughout the document really means something more
> > along the lines of "primary key" which could include UID,
> > RECURRENCE-ID, and RANGE to accurately identify which events
> > are being referred to.  Much of the confusion here has been
> > as a result of interpretting "UID" to not mean all of those.
>
> Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's
> meaning) would be useful?

Yes, that would be best, I fear putting it in a different section
like Convenentions used in this document would be to easily missed.

> > Making it clear that when canceling an event for a particular
> > user the SEQUENCE value should not be incremented (or at least
> > more discussion on what it should do).
>
> While this is a good change, exactly how to do it is another matter.  The
> problem is that this change is that it will effect all implementations
> already out there that follow that text from Section 2.1.4.  Just making
> the change could mean interoperability issues w/existing implementations
> and no way to detect it.

Well is there any _real_ problem that develops if we do this?

There's 4 scenarios I can think of, of which only 2 might be
an issue:

1) Old sends a cancel to Old
No problem they do what they always did

2) New sends a cancel to New
No problem they both expect the new behavior

3) Old sends a cancel to New
No problem, SEQUENCE value has been incremented New just prcesses it.
If Old wants to reinvite New it will do whatever it has always done
in the past when it did such things.

4) New sends a cancel to Old
Not sure what happens here since it seems to be implementation specific.
I suspect that it will actually still work since DTSTAMP will be
greater than what it has, but some CUAs might try to enforce the
RFC MUST and ignore a CANCEL if the SEQUENCE isn't greater.
I guess the question is are there any CUAs we know of that will
fail to CANCEL an event if the SEQUENCE is the same?

Assuming that the CUAs will indeed cancel the event, will they
reschedule it if they receive a request at the same SEQUENCE
but greater DTSTAMP.

--------------------------------------
There might be another approach.
Rather than try and prevent SEQUENCE from being incremented,
define rules for exceptions to invalidating the ATTENDENCE status.

For instance, if an update is sent with a greater SEQUENCE and
ALL fields except Comments are identical, then no REPLY is required
and ORGANIZERS should simply transfer the attendence status.

This way, cancelling an ATTENDEE with cause a SEQUENCE bump,
and reinviting an ATTENDEE will also cause a SEQUENCE bump,
however, those bumps will have no impact on the existing attendees.

Old CUAs will simply go through the extra effort of processing
the replies and New CUAs might be sent an RSVP=true for the
higher SEQUENCE value because it failed to respond.
However, in any case, the right things end up on the calendar.

-- Michael --