Subject: Re: W-23 CAP Calendar property .. overlapped booking

From: Doug Royer <[email-masked]>
Date: Wed, 1 Sep 1999 14:38:31 -0700 (PDT)

> From: [email-masked]
> Date: Tue, 31 Aug 1999 21:54:28 GMT
> 
> Doug Royer wrote:
> 
> >I don't see why it can't be an implementation detail.
> >
> How about "interoperability". If this is an implementation detail, then 
> were do we get the guarantee that it will have the same behavior on two 
> different CSs that receive the same CAP command?
> 
> >One implementation can have it as a rule (Only one person
> >can book a single car). All attempts to set it to the other
> >way in a component can be permission denied as if you did
> >not have the VCAR to do that - hard coded into the CS.
> >

> This sounds like we are building in non-interoperable options.

Ether way you can get permission denied for ANY property or parameter.
Why is this one different?

> >Another implementation can have it be the default by allowing
> >the component to have an entry that conflicts with the
> >calendar default. And the component is that last word for
> >conflicts - hard coded into the CS.
> >
> >It is just a property. Users simply have or do not not have
> >permission to change it.
> >

> Then this would be come yet another VCAR policy? Will this be 
> interoperable amongst at least two different implementations? If not, then 
> this is not a feature we want to codify.

VCAR does not specify an exact list of parameters or properties.
It allows ANY valid parameter or property (including x- experimental
extensions.)

> >I can't think of any case where a calendar would mandate that
> >all components MUST allow conflicts. But if someone did, then
> >that implementation could simply allow it.

> Some calendar systems just allow conflicting appointments/meetings. This 
> would present itself as not supporting the CONFLICTS:FALSE. Or would the 
> CS return an error if the CUA tried to set this on this event?

I think we had said that it was a suggestion from the CU, not a
mandate. So for an implementation that did not support CONFLICTS,
it would simply be ignored.

I do not think that interoperability is an issue.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Thu, 02 Sep 1999 15:27:35 GMT

>It allows ANY valid parameter or property (including x- experimental

Hhmm. Not sure your response addresses the intent of my comment. I must 
not have worded my comment clearly. Sorry.
Addressing your response, VCAR calendar component _does_ indeed specify an 
_exact list of parameters and properties_. Otherwise, it wouldn't provide 
for interoperate among implementations. Yes, the ABNF needs to include the 
support for both experimental extensions and future IANA registered 
properties, as well as the currently known set of parameter and 
properties.
As to my initial comments, is it your proposal for "CS enforcement of 
event conflicts" that this be supported via VCAR specification? If so, 
would this be specified only if you support VCAR grammar (a full VCAR 
capability) or also if you support VCAR policies (a minimum VCAR 
capability)? If the latter, then we will need to add this a a VCAR policy 
enumeration. Clearer comment?
-- Frank