Subject: Re: Question for list

From: [email-masked]
Date: Thu, 13 Apr 2000 17:01:37 -0400

Doug also wrote:
>-OR- *IF* you were to add ORGANIZER to your group-of-one appointment.
>Why do you care? I do not see that anything in the protocol is busted.

I care because there is a semantic difference.  One involves no workflow, the other does.  Are you suggesting 
we revise the RFCs to mandate ORGANZIER always be there for group and 
non-group entries??

As for busted, see my previous replys example about 10 missing entries.

>So far - I just hear "I don't want to". But I am sure there is a reason.
>I just do not see it yet.

Ive been saying "Ya cant get there from here."  So far you agree w/my 
example but the solution ("Use CAP") is not reasonable to the scenario. 
This is not an issue of real time access, etc; its an issue of not being able to 
publish my entire calendar (just those that Ive scheduled with other folks).  "Use CAP" 
still wont allow me to publish my entire calendar to a file!!!  FMI: Just 
what METHOD value would be used for those non-group entries?!?!?  YOU DONT 
HAVE ONE WITH OR WITHOUT CAP SINCE CAP DOESNT ADDRESS THIS CASE EITHER!

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Apr 2000 13:43:59 -0700

[email-masked] wrote:
> I care because there is a semantic difference.  One involves no workflow, the other does.

What workflow? I see nothing in iCalendar or iTIP using the word  'workflow'.
Do you mean scheduling? If so, if the METHOD is CREATE as stored
in the CS per CAP - then there is no scheduling to perform.

If METHOD is REQUEST - then you have a REQUEST to act on.
If METHOD is REPLY then you have reply that needs sent
 .
 .
 .

>  Are you suggesting

No I am saying ether the current object needs action or it does not.
And that iTIP is for scheduling - and not anything else.

> example but the solution ("Use CAP") is not reasonable to the scenario.

Why is it not reasonable?

Out of scope for iTIP as iTIP is not direct booking - it is scheduling.
iTIP is not busted - it's just that you wish to extend iTIP
to do direct booking of non-scheduling objects - correct?

> This is not an issue of real time access, etc; its an issue of not being
> able to publish my entire calendar (just those that Ive scheduled with>
> other folks).

PUBLISH is in iTIP scheduling concept - that uses ORGANIZER.

It is not a direct booking concept.

> "Use CAP" still wont allow me to publish my entire calendar to a file!!! 

Not true.

CAP will allow you to retrieve the entire contents via METHOD:READ

PUBLISH? If you mean copy the contents to a file - not directly,
but it can allow you to do that. Backup/Restore is out of scope for
iTIP. The WG has already agreed backup/restore is out of scope
for iTIP and CAP.

> FMI: Just
> what METHOD value would be used for those non-group entries?!?!? 

iTIP - None at all - as it is not a scheduling request.

CAP - METHOD:CREATE to create it in your store.
      METHOD:READ with a VQUERY to pull it out.

> YOU DONT HAVE ONE WITH OR WITHOUT CAP SINCE CAP DOESNT ADDRESS
> THIS CASE EITHER!

So far there is NO CAP restriction table - so why have you
reached this conclusion?

And you are incorrect as you CAN place a non-scheduling object into
your CS using CAP. And you can pull them out.

CAP can transfer scheduling METHODs into/from your calendar.
It can also put/get (METHOD:CREATE/METHOD:READ) into/from
your CS with CAP directly booking objects. 

This is precisely one of the primary reasons that CAP exists.

What you do with it is up to you (file, ...).

-Doug