Subject: Re:

From: [email-masked]
Date: Tue, 2 Sep 2003 10:42:43 -0400

Doug asked on 08/28/2003 06:40:37 PM:
> >  >                                                    but the last 
sentence
> >  > definitely says that RECURRENCE-ID changes, and the wording and 
order is
> >  > such that it implies that this happens for an instance change.
> > 
> > This last sentence is the only text in iCalendar or iTIP that says 
> > RECURRENCE-ID changes.  Its contrary to the text immediately above it, 

> > to the text in iCalendar and to all the logic in elsewhere in iTIP 
> > describing workflow sequencing and recovery.
> 
> So do you also claim that Derik's and Frank's recient post also
> is in error when it says they change? Where they in error again?

Not at all.  If you actually read what both I and they wrote you will find 
they are agreement.  They wrote:

4) It is worth noting that those discussion in the related WG email 
threads referring to examples in iTIP are problematic, as section 3 of 
RFC2446 was intended to be illustrative text and was not reviewed as 
thoroughly as other sections of the RFC for consistency with iCalendar 
semantics or conformity to iTIP normative sections. This text defines a 
set of examples, or informational material. Further, this text is known to 
have numerous typographic errors.

and I agree.  I was merely pointing out that the ONLY conflicting text 
cited so far is the last line of 3.7.1 that Tim referred to (the rest 
jives just fine w/iCalendar and the rest of iTIP).   You (and Chris) seem 
to be the only ones who think this single line in the _semantics_ RFC has 
some kind of fiat over the _defintion_ RFC in defining the behaviour of 
the property and is allowed to redefine the property instead of provide 
semantics to it.

Even if you ignore the prose in iCalendar, all the other text in iTIP and 
the recent posting by Frank/Derik, the analysis of how both models perform 
still stands and is still accurate despite wishes to the contrary: the 
delta model performs poorly or can totally break down when message 
missequencing  or loss occurs, the fixed model does not. 

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 02 Sep 2003 10:54:00 -0600

[email-masked] wrote:
> Not at all.  If you actually read what both I and they wrote you will 
> find they are agreement.  They wrote:
> ...

Your conclusions seem to be that they made the same typographical errors in
their recent email post. And that as you believe it is a consistent
typographical error you feel is in iTIP. I find that overly odd. Perhaps
you should contact  them and have them correct their email and iTIP on
this list?

Until then I do no think that it is odd they claim that the RECURRENCE-ID
changes when the pattern changes.

And despite your assertions that only iTIP says that the RECURRENCE-ID
changes and only once. And as iTIP *is* the scheduling definition for
calsch, it seems odd to me that you would think that iTIP text does
not apply to scheduling.

iCAL:

  ...the "RECURRENCE-ID" for a given recurrence instance might also change.

iTIP:

  (Your assertion that iTIP does not modify or update iCAL is not supported
   by the text of iTIP).

  ... iTIP complements the iCalendar object specification by adding
    semantics for group scheduling methods commonly available in current
    calendar systems. ...

  (This next paragraph includes a definition of "REQUEST" to include
   "reschedule" and "change" of recurrence intervals.)

  ... The "REQUEST" method may be used to reschedule an event. A
    rescheduled event involves a change to the existing event in terms of
    its time or recurrence intervals and possibly the location or
    description. ...

And iCAL says:
    ...Purpose: This property is used in conjunction with the "UID" and
    "SEQUENCE" property to identify a specific instance of a recurring
    "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
    value is the effective value of the "DTSTART" property of the
    recurrence instance. ...

Looks to me to be supportive and not two more typographical errors.

  (Note that iTIP specifically defines what it calls "update" to NOT change
   instances, later it defines the term "modify" to mean change instances.
   Your quotes of this section to mean invite are out of context. This
   is for VEVENT, a similar paragraph exists for VTODO.).

    ...The "REQUEST" method may be used to update or reconfirm an event. An
    update to an existing event does not involve changes to the time or
    recurrence intervals, and might not involve a change to the location
    or description for the event. If the recipient CUA of a "REQUEST"
    method finds that the "UID" property value already exists on the
    calendar and that the "SEQUENCE" property value in the "REQUEST" is
    the same as the value for the existing event, then the "REQUEST"
    method describes an update of the event details, but no rescheduling
    of the event. ...

And iTIP 4.4.2 shows how to modify instances.

Your assertion that Derik and Frank meant typographical error to mean
that they accidentally added an entire section in iTIP and included
examples is absurd. The WG (and you were on the mailing list at
that time) concluded that that entire section was valid. Yet
now you want to assert that 58 lines (129-ish words, 1754 characters),
are all one big typographical error that everyone including you
agreed to at the time?

And as 'Steve' was the lead on iTIP, lets ask him if (4.4.2) is a
huge typographical error.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards