Re: problem reconciling CAP Methods

[Doug Royer <Doug.Royer@xxxxxxxxxxxx>]

Nitin Shingne wrote:
> 
> Greetings !!!
> 
> What would be the sequence of commands to create a new entry for an Event in
> a Calendar. The event has some attendees.
> 
> The draft gives an example to create an entry as ...
>    C: SENDDATA
>    C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII
>    C: Content-Transfer-Encoding:7bit
>    C:
>    C: BEGIN:VCALENDAR
>    C: VERSION:2.1
>    C: CMDID:abcde
>    C: METHOD:CREATE
>    C: TARGET:cap://cal.foo.com/relcal1
>    C: TARGET:relcal2
>    C: BEGIN:VEVENT
> ...........
> ........... so on....
> 
> Now with the method specified as "CREATE", where would the scheduling method
> "REQUEST" go?

A CS does two things for you:

	(1) Calendaring - Get this months appointments.
			- Place this appointment into my calendar.
			  (The example you gave above).

	(2) Scheduling	- METHOD: REQUEST, REPLY, COUNTER, DECLINE-...

So there needs to be a way for a CUA to say "just drop this into
my calendar as I (the CU) have already determined I want this
on my calendar".

A CS would CREATE a new VEVENT in the store with
the characteristics that followed in the same command.
If the CREATEed VEVENT had METHOD:REQUEST, then the CS would
deposit the REQUEST VEVENT into the calendar along with the
other properties in the VEVENT.

This is where we still need more text in CAP. The CS
would look at the ORGANIZER:

Is the ORGANIZER the CU that deposited the VEVNET (with METHOD:REQUEST
in the VEVENT)?

	Yes -	Process it as an iTIP scheduling request.
	 	Send out email or CAP connect to the ATTENDEEs
		sending them a METHOD:REQUEST.
		
		This is a CU requesting a scheduling with the
		ATTENDEEs via METHOD:REQUEST and CAP.

	No  -	This is a CU depositing a REQUEST (possibly
		from iMIP) into the CU's (not ORGANIZER's) store.

		Just drop the VEVENT into the store as the
		CU/CUA wants to keep the VEVENT data.

		Later a CUA/CU would look for all non-booked
		appointments (text already in CAP or soon to be),
		find this one and ask the CU if they wanted to attend
		the event:

		Yes -	Change the METHOD:REQUST to METHOD:CREATE
			in the store. It is now 'booked' in the
			CU's store.

			Possibly RSVP with a YES.

			Possibly sending a METHOD:REPLY to the
			ORGANIZER.

			Probably deleting the entry from the store.

		No  -	Possibly RSVP with a NO.

			Possibly sending a METHOD:REPLY to the
			ORGANIZER.

			Probably deleting the entry from the store.

We need more discussion on this, it looks to be the same as iTIP
and I suspect it is exactly the same. I also suspect that anything
that we find that is not like iTIP, will be a bug in iTIP that
will also need to be fixed.

It is just that CAP also needs to just be able to deposit and fetch
appointments for a CUA.

ALSO - we need a CAP restriction table, much like the iTIP restriction
table. I suspect that the above CAP example will not be valid as
I suspect a METHOD will be a MUST (As I think you are pointing out).

-Doug

			
		
			

			
> Also BTW, What is CMDID? I could not find the definition in the draft or
> RFC's 2446 & 2445.

iCalendar is extendable.

CMDID missing from CAP. Thanks!

It is simply a TAG to match a command to a response for overlapped
commands.

> thanks & regards,
> nitin