Re: CAP-12-e: TRANSP and -NOCONFLICT changes

[email protected] Wed, 2 Jun 2004 18:21:59 -0400
Newsgroups gmane.ietf.calendar
Message-ID <OFF67645A2.B814F1F0-ON85256EA7.0078AEBA-85256EA7.007ABB9A@notesdev.ibm.com>
Doug wrote on 05/28/2004 05:34:58 PM:
> It is true that CAP adds to the OPAQUE object types in 2445. It however 
> cap does not introduce OPAQUE
> objects as a new concept and even if CAP did not add new OPAQUE object 
> types, the problem still exists
> in existing 2445/2446 objects.
> 
> Again, not a CAP issue.

Im sorry but I have to disagree.  CAP is changing TRANSP from simply 
indicating if an entry "is transparent or not to busy time searches" to 
also convey conflict controls.  That makes this a CAP issue.  Unless CAP 
defines the changes clearly and unambiguously, it will be a problem later 
on. 

Also lets be perfectly clear on something.  RFC 2445 defined TRANSP simply 
as how an entry appears in busytime.  It has NO concept of conflict 
control for calendars or for booking one entry on top of another; that was 
CAPs addition.  So the claim that if there were an issue, its belongs to 
RFC 2445 is simply incorrect.  The new role for TRANSP was introduced by 
CAP and thus CAP needs to deal the ambiguities it introduced.

Perhaps if you could explain in greater detail how you see "a button 
performing this new user friendly feature" and how CAP specifys a 
consistant behaviour for my 2 scenarios (or even my simple 1 day scenario) 
I could better understand why you think there is no issue.  So far I have 
not see any technical info or analysis as to where in CAP this is clearly 
described.  If it is there and I'm simply missing it, please point me to 
it.  If its not there, we need to add a bit more to CAP I think.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...