Re: request + add

"Mark Smith" <[email protected]> wrote in message
news:[email protected]...
>
> Michael Fair wrote:
>
> > >
> > > The example given was ADD which is NOT the object above.
> > > See the original post and section "3.2.4 ADD" in iTIP.
> >
> > I think you are misunderstanding what object it is that's being
> > described here.
>
> So the question (restated) is:
>
>   Once attendee-2 gets 'B' which is an 'add' (not some other things).
>   As that is a valid way to invite an attendee.

Where in rfc2446 did you get that?

As far as valid invites go, I only see one "valid" way to do an invite:

3.2.2 REQUEST

   The "REQUEST" method in a "VEVENT" component provides the following
   scheduling functions:

     -  Invite "Attendees" to an event;


Further, section 3.2.4 ADD does not specify what a CUA _must_ do if
it receives an ADD for a UID that isn't in the store.

3.2.4 ADD:
   ...

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT".  If an "Attendee"
   implementation does not support the "ADD" method it should respond
   with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".



That very clearly states that ADD is not a valid method of inviting a
user to a set of recurring events.  Just because a CUA could safely get
by utilizing the information that is in the message (which the RFC
encourages) does make it a valid method.

Further, let me stress _could_.
Another legal thing for the CUA to do is to throw the message out and
just send a REFRESH request only.

The only section that is explcitly blessed as a valid invite is REQUEST.


>   Do you agree that once 'B' is complete then attendee-2 can
>   only get the recurrence-id's from what it has those objects
>   described in 'B'. As attendee-2 attendee-2 will never have
>   the sequence:0 object.

Yes and then no.
Once B is complete a generous CUA will only be able to put onto the
calendar that which the ADD message describes.
However, it sent the REFRESH request and therefore has a REQUEST message
coming its way.  This REQUEST message has all the data for every currently
valid instance in it.  So I disagree that A2 will never see the prior info.

I want to stress that A2 will never see and has no need to see the SEQ:0
object to construct the most recent version of UID:XXX.  So the sentence
that A2 will never see the SEQ:0 info is true, but the statement that it
will never see earlier information is false.  A2 will see the SEQ:1 info.

A2 needs only to receive information from SEQ:1 forward because SEQ:1 is
the most recent redefinition of the entire set.

In our example, once SEQ:1 has been created by the ORGANIZER, the SEQ:0
object
becomes completely obsolete and totally useless and irrevocably consigned to
be forgotten by all parties interested in UID:XXX.  At that moment, the only
necessary information comes from the SEQ:1 version of UID:XXX.  The same is
not true of the SEQ:2 ADD though.

It is the combination of the SEQ:1 REQUEST and the SEQ:2 ADD that make
up the current state of UID:XXX.

That combined state can be encapsulated in a single REQUEST message, and
that SEQ:2 ADD message will never be sent to any interested party ever
again.  It will be sent once and only once to the ATTENDEES and if they
have a problem with it that's tough.  The ORGANIZER will never generate
it for them again as they have no way to ask for that.


> A 'refresh' would only return 'A', 'B' or 'C' and not
> the sequence:0 iTIP message.

I'm not sure I'm following you...
Above I thought you were referring to message B, here I'm not sure
what A,B, and C are...
Here's what I can say though.

A REFRESH, once methods A,B or C have completed, will send the exact same
response.  The single REQUEST message from my prior email.  Method D
(the proper method) however would give the 2nd instance a different
RECURRENCE-ID but otherwise would be the same.

In methods A, B and C, the SEQ:0 version of the object is utterly and
completely useless.  There is no need to see it... ever... by anyone...
The SEQ:1 version is the version that has all the valid data to be
combined with SEQ:2.

A REFRESH would send the combined status of SEQ:1 and SEQ:2 as its response.



> So it can not be true that you have to have the history
> of an object to get the recurrence-id's. It also can
> not be true that the recurrence-id's are tied to the
> original (0) object. As it would be impossible to
> change an object that was later added with the
> add method. The attendee must be able to expand
> the 'A', 'B', or 'C' objects from themselves.

The "original" is not the same as SEQ:0.
The "original" is the most recent REQUEST that does not contain
a RECURRENCE-ID for UID:XXX.

SEQ:0 is a REQUEST that does not contain a RECURRENCE-ID property.
Therefore, it is the "original" at that time.

SEQ:1 is also a REQUEST that does not contain a RECURRENCE-ID
property.  Further, it is more recent than SEQ:0, and therefore
it is the new "original" definition of the RECURRENCE-IDs for
UID:XXX.

SEQ:2 is then an ADD, therefore it gets combined with the most
recent version of the original UID:XXX, which in this case is
the SEQ:1 version.

As a thought experiment, if SEQ:1 had been an instance reschedule
instead of a REQUEST without a RECURRENCE-ID, then the most recent
"original" definition would have been SEQ:0 and then the information
contained in SEQ:0 would be retained.  As the example was written
however, at the moment of SEQ:1's incarnation, SEQ:0 become completely
obsolete and complete unnecessary.  The pivotal piece of prior info
for the definition of RECURENCE-IDs was no contained in SEQ:1.


How we doing?  Making progress?

-- Michael --