Re: request + add

Michael Fair wrote:
> 
> "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:


That was the question that was asked repeatedly (B)
which was a request + add, which is also the subject
line you keep replying to. I am now convinced you have no
intention of participating in a technical debate about
this issue.

If there is anyone that thinks that you can get 'B'
and still thinks that you have to have prior history
of an object in order to extract the recurrece-id
on expand?

If there are 20 changes to a uid, it is insane to expect
that the next person added will have to say yes/no to
19 old dates, reply to them, only to finaly get vevent
request 20 and then possibly counter. How would they
know that they can not counter the first 19 until they
get a no, accept and then get another sequence. I do not
read that into any rfc or draft.  I have over the last
two months read the entire list archive and see discussions
about using 'add' to describe a single instance that is part
of a set that has a different location. That seems to have
been one purpose to 'add'.