Re: request + add

"Mark Smith" <[email protected]> wrote in message
news:[email protected]...
>
> Michael Fair wrote:
>
> > >
> > > Okay, now what if it gets the sequence:1 request and the sequence:2
'add'
> > > as shown in 'B'.  As all three instances can not be represented in
> > > one 'method request' object because the duration of all three
instances
> > > are not the same. Now the master object is at sequence:2, as is
> > > attendee-2.
> >
> > This can actually be described in one method:request object as I'll
> > demonstrate below in response to a REFRESH request.  You are right
> > if what you meant was that it can't be described in 1 VEVENT component.
>
> However you did not do a request+add below which was the question.
> You did a request + single instance reschedule.

I'm not quite sure how to respond to this.
I assure you that I responded accurately and completely to a request+add.

You have neither corrected me by putting forth your expectation nor have
you done anything other than just assert the belief that I didn't respond
to the example when I have.

If you have a different answer I ask that you present it and refrain from
just stating that you believe someone's answer isn't correct.

If you do not know what the correct answer should be then you should state
that in your email.  I believe what I believe and I can back up what I've
presented (it's a very long email which I'm really inclined to create unless
it really needs to be done).  You saying that I didn't answer the question
is not going to help me understand the question you think is being asked or
how my answer is somehow invalid.

> > > The recurrence-id's can be calculated from what attendee-2 has.
Correct?
> > > And it will be the same recurrence-id's as organizer. Correct?
> >
> > This sounds correct, but since we haven't rescheduled any of the
instances
> > yet it's not all that meaningful...
>
> As this topic is part of EXPAND:TRUE debate - yes it is valid.
>
> Your example below is not the one asked.

The question asked was a REQUEST followed by an ADD.
The first response in my email covered that.

Because of my uncertainty about what you were asking I decided to
cover my bases and also show what would happen if A2 received an
ADD as the first message in the sequence.

You said that A2 didn't see the event until SEQ:2.
SEQ:2 was an ADD message.  Therefore it would generate REFRESH request
when the CUA received it.

The ORGRANIZER would then respond with a single REQUEST message that
encapsulated the entire current state of UID:XXX.

This "current state" would include the merged sets of events from the
SEQ:1 state and the "ADD message" resulting in the RDATEs described.
As you pointed out, the second instance is 1.5 hours long and not 1 hour
long.
This cannot be represented in a single VEVENT component.
The method outlined in the standard for relaying per instance specific data
is to use multiple VEVENT components.  You may use multiple VEVENT
components
in the same message if and only if all VEVENT components reference the same
UID.

What was sent below is not a REQUEST followed by a RESCHEDULE.  That would
be
two separate and distinct messages.  What was sent is a single REQUEST
message.
Describing the SEQ:2 state of UID:XXX.  Generated in response to a REFRESH
request from the CUA when it received the "ADD" message.

> >
> > The ORGANIZER will send the following message in response to the
REFRESH:
> > BEGIN:VCALENDAR
> >   METHOD:REQUEST
> >
> >   BEGIN:VEVENT
> >    UID:XXX
> >    SEQUENCE:2
> >    ...
> >    DTSTART: 1-dec-2003 at noon
> >    DTEND: 1-dec-2003 at 1pm
> >    ...
> >    RDATE:3-dec-2003 at noon
> >    RDATE:2-dec-2003 at 3:30
> >   END:VEVENT
> >
> >   BEGIN:VEVENT
> >    UID:XXX
> >    RECURRENCE-ID:2-dec-2003 at 3:30
> >    SEQUENCE:2
> >    ...
> >    DTSTART: 2-dec-2003 at 3:30
> >    DTEND: 2-dec-2003 at 5pm
> >    ...
> >   END:VEVENT
> >
> > END:VCALENDAR
> >




How is this not the example given?
How is this not the question asked?

-- Michael --