Re: CAP Draft 6 comments

[Doug Royer <Doug@xxxxxxxxx>]

Steve Mansour wrote:
> > >   9. Section 4.1.6 versus 4.1.8 -- the value for METHOD.  In some
> > >      places, we refer to the METHOD value for "booked" events as NULL,
> > >      and in other places we refer to it as CREATED.  I happen to
> > >      prefer being explicit and keeping it at CREATED, but whatever we
> > >      choose we must be consistent.
> >
> > I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd.
> 
> We all came to that conclusion.  One suggestion was that we use "BOOKED"
> instead of "CREATED".

I could go for that, that would bring up another question.
Can I queue 'CREATE' and store it (like iTIP methods)? Or must
CREATE always be acted on and never stored?

> >
> > The only way to do this would be to allow only moves to top
> > level calendars - where they can control all of their own VCARs.
> > And as that would be a kludge, should we drop the ability
> > to move calendars?
> 
> hmm... I think it's pretty severe to drop it.  Do people have an issue with
> calenders possibly becoming more restrictive after a move?

I would towards dropping it until CAP-v-next. As pointed out in
another email, VCARs are complex, this just multiplies the states
changes to consider.

By dropping it, it does not mean you can not do it, it means
the WG has not thought out all of the VCAR issues.
Lets work out VCAR interoperability first, before we try
to make it more complicated. You can always - copy to new, delete old
until we have MOVE worked out.

begin:vcard 
n:Royer;Doug
tel;cell:208-520-4044
tel;fax:208-552-1179
tel;work:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com/People/Doug
org:INET-Consulting LLC
version:2.1
email;internet:Doug@xxxxxxxxx
title:Chief Executive Manager
adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA
x-mozilla-cpt:;-1
fn:Doug Royer
end:vcard