Subject: Re: iTIP REPLY question

From: "Jay Parker" <[email-masked]>
Date: Thu, 24 Apr 2003 23:31:23 -0600

Could someone please provide clarification in the following areas:

1. Can both an email address and a CAP uri be specified for the
organizer so that if rights haven't been granted for opening a
connection then the CUA can fall back to the email address?  If so how
is it done?  If not, and both a CAP uri and an email address are
available - which should be preferred when creating an iTIP request?

2. It's not clear to me which pre-defined rights are checked when
depositing an iTIP reply object.  I.E. Is CARID:UPDATEPARTSTATUS VCAR
checked?  Does this right cover both VEVENT and VFREEBUSY components? 
Or does each store need to implement additional VCARs such as a
hypothetical CARID:UPDATEBUSYTIMEINFO.  Do I need to create a VCAR to
handle the email address AND a VCAR to handle the CAP uri?

3. A CUA that is ready to process an iTIP reply that was delivered via
iMIP is expected to check the VCARs in the same manner as if it was
transported via CAP, correct?

>>> [email-masked] 4/24/2003 1:32:32 PM >>>

Preston Stephenson wrote:
> I need a clarification on where the iTIP REPLY object is created in
a
> reply to an iTIP REQUEST in CAP.
> 
> Given CUA1 with CS1 and CUA2 with CS2.
> 
> CUA1 creates a METHOD:REQUEST object for CUA2 in CS2.
> CUA2 reads the METHOD:REQUEST object in CS2.
> CUA2 creates the METHOD:REPLY object for CUA1.
> 
> In which CS is the METHOD:REPLY object created, CS1 or CS2?

Nether, it is created in CUA2.

> The iMIP logic says it gets sent back to CS1. There is no way for
iMIP
> to get the reply back from CUA2 in any other way than for CUA2 to
send
> the REPLY back in an email message.

If the ORGANIZER property in the REQUEST is a CAP uri, then CUA2
deposits
the REPLY into CS1. If the ORGANIZER property is a mailto uri,
then CUA2 e-mail's the REPLY to that e-mail address.

> In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST
> objects in another CUA's CS.
> There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT
> information.
> 
> How do I get the rights to place METHOD:REPLY objects in another
CUA's
> CS?

They must give it to you in advance. If they have not given you the
rights to deposit a REPLY into their CS, then they broke iTIP - ignore
them
and throw away the REQUEST.

It is possible that they want you to connect anonymously.

> How do I access the other CS?

If the ORGANIZER property is a CAP uri, then open a connection
to that uri.

> If I have to create METHOD:REPLY objects in my own CS and have other
> people query for METHOD:REPLY objects then that breaks the
functionality
> with iMIP. iTIP is suppose to be transport independent, so I would
> expect the METHOD:REPLY to back in CS1.

No query needed from CUA1 into CS2. It is a push model.

-- 

  Doug Royer                     |   http://INET-Consulting.com 
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Fri, 25 Apr 2003 10:59:53 -0600

> available - which should be preferred when creating an iTIP request?

RFC 2445 limits one URI value to ORGANIZER
RFC 2446 limits one ORGANIZER to a VEVENT.

So currently no, you can not have both for the same ORGANIZER.

As to which is preferred:

	If you can let then REPLY via CAP, you cap if you wish.
	If not, e-mail them and give them an e-mail reply.

> depositing an iTIP reply object.

Nothing is specified. So, (1) try it or (2) query for the VCARs
and figure it out. I would think that (1) would be faster and
require less round trips.

 >  I.E. Is CARID:UPDATEPARTSTATUS VCAR checked?

I an not sure what you mean by 'checked'. It applies (per CAP)
to booked components, not unscheduled entries.

> Does this right cover both VEVENT and VFREEBUSY components? 

The text in CAP says "... in any components ..." if this question
applies to UPDATEPARTSTATUS.

> handle the email address AND a VCAR to handle the CAP uri?

VCARs apply to UPNs, not CAP or e-mail URI's.

In cap-10:

    Calendar Access Rights (VCAR) -  The mechanism for specifying the CAP
       operations ("PERMISSION") that a particular calendar user ("UPN")
       is granted or denied permission to perform on a given calendar
       object ("SCOPE").  The calendar access rights are specified with a
       "VCAR" component.  (Section 9.3.

> transported via CAP, correct?

A 'CS' would check the VCARs if the 'CUA' attempts any operation.
However the CUA is free to query for the VCARs and decide before
the operation.

--