Re: The intent/meaning of EXPAND and its usefullness
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Message-ID | <OF7DAD6787.097F5718-ON85256DFA.005789EA-85256DFA.005B3F3E@notesdev.ibm.com> |
Doug replied on 12/11/2003 03:45:49 PM:
> We had discussions and no big vendor would budge at all, so we just set
> flags.
Given that all vendors (large, medium or small) have to deal with existing
customer bases I dont find this astonishing. In any case, the
flags/settings we create need to be comprehensive and clear for all
parties so that correct behaviour can be determined.
> As iTIP has fallback and errors to those same problems that pre-date
> CAP, we did
> not feel that CAP should address those iTIP issues, just allow the
> endpoints to determine
> that the problem existed prior to transferring data.
The iTIP fallbacks you refer to are protocol level behaviours like:
Method Fallback
-------------- -----------------------------------------------------
PUBLISH Required
REQUEST PUBLISH
REPLY Required
ADD Required
CANCEL Required
REFRESH Required
COUNTER Reply with Not Supported
DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise
reply with Not Supported
The issues with EXPAND are not germane to iTIP messaging so its not an
iTIP issue/problem as you contend. The questions related to EXPAND are
related to CAP features/abilities and nothing directly related to iTIP.
> I do not think CAP created this problem, I think it is an iTIP issue
> that CAP
> allows you to find.
iTIP defines the semantics for doing workflow between 2 parties and
nothing more. The issues with EXPAND are non-workflow related and thus
CAP specific; iTIP does not cover accessing and manipulating calendar
contents like CAP does.
Now can we try to address the questions so CAP is clear and as
unambiguious as we can make it?
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...