Subject: Re: iTIP REPLY question

From: "Jay Parker" <[email-masked]>
Date: Tue, 06 May 2003 00:38:29 -0600

I'm still having difficulty understanding the VCAR rights as they
pertain to iTIP over CAP verses  iTIP via iMIP.  Could I get additional
clarification on my comments below?

Thanks!

Jay

>>> [email-masked] 4/25/2003 10:59:53 AM >>>
>
>
>Jay Parker wrote:
>> 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?
>
>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.
>

I'm asking from the perspective of a store provider (Novell GroupWise).
 If the calendar item was sent by a non-CAP (GroupWise) client, but
accessed by a CAP client, then the store (GroupWise agent) must decide
whether to use a CAP uri or an email address for the organizer.  As a
store provider we have access to both the CAP uri and the email address.
 Does anyone know of a reason that we should choose to use the CAP uri
instead of the email address or vice-versa.

>> 2. It's not clear to me which pre-defined rights are checked when
>> 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.
>

Again, I am asking from the perspective of an administration utility
that creates the VCAR rights, and from the perspective of a store that
verifies the user rights before allowing access to calendar items.  We
need to map our built-in rights to VCARs.  Several of our built-in
rights are not covered by the pre-defined rights.  For instance, what
pre-defined VCAR deals with rights to return VFREEBUSY components as a
result of a busy search?  Is a CS required to return all granted rights
via VCAR or can it choose to enforce certain built-in rights even though
VCARs associated with those rights are never returned to the client as a
result of a query for VCARs?.

> >  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.

OK.  We can use the word apply.
>
>> Does this right cover both VEVENT and VFREEBUSY components? 
>
>The text in CAP says "... in any components ..." if this question
>applies to UPDATEPARTSTATUS.
>

So the pre-defined CARID:UPDATEPARTSTATUS VCAR does not 'apply' to
VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY
request did not create a 'booked' VFREEBUSY item in the originators
calendar?

>
>> 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?
>
>vVCARs 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.
>

If the iTIP object arrived via email (iMIP) then the UPN associated
with the CAP session will belong to the user processing the received
iMIP message - not the one who sent it and signed it.  But the
permissions should be checked against the sender's email address.  How
would the user's MUA/CUA that is processing the iMIP message get the
VCARs to 'apply' to the sender's email address?  And how would the CS
prevent the MUA/CUA from spoofing someone's email address.

>> 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?
>
>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.

The CUA UPN identity is established through the CAP session
authentication.  How is the UPN identity established when a CUA is
processing iTIP objects sent via iMIP?  Or is the calendar store the
component that must validate the signature on the MIME?  It seems like
the entire signed MIME rather than just the iTIP object should be passed
to the CS when an iTIP request was delivered via email.  Or from another
perspective... how does the CS know that the CUA/MUA has validated the
signature before passing the iTIP object to the calendar store?

>
>-- 
>
>  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: Tue, 06 May 2003 09:40:53 -0600

> instead of the email address or vice-versa.

As in iTIP you can not have both for the same property (ORGANIZER
or ATTENDEE), your question will not have a definitive answer
as it will not apply to iCalendar objects. So the answer is
out of scope for RFC 244[567] or CAP.

> result of a busy search?

Defined in 4.2.2 of draft-...-10.txt: READBUSYTIMEINFO

 > Is a CS required to return all granted rights

The CUA never needs to ask for VCARs. So yes.

> request did not create a 'booked' VFREEBUSY item in the originators

No, because that is not how it is defined in section 4.2.2.
And because VFREEBUSY does not have an ATTENDEE property as
described in 4.2.2 / UPDATEPARTSTATUS.

> permissions should be checked against the sender's email address.

No VCARs are checked against the UPN of the currently connected
CUA that successfully logged in. Othe VCAR rules may restrict
the data however the CS will never see the senders email address.
The CS will only see the ATTENDEE or ORGANIZER property values.

 >   How
> VCARs to 'apply' to the sender's email address?

I do not understand you question. The CUA attempts an operation
and the CS allows or disallows it because of the VCARs stored
in the CS.

> And how would the CS

No such claim has been made. The CS compares the VCARs to the
currently connected and authenticated session. The CS never
sees the 'From:' address of the object.

> processing iTIP objects sent via iMIP?

A CS does not accept iMIP objects directly, they always come
from a CUA (automated or not). So it is up to the CUA
to map e-mail addresses to/from UPNs for authentication.

 >  Or is the calendar store the
> component that must validate the signature on the MIME?

The CS is not an MUA, so no. All iCalendar objects are MIME
objects, iCalendar objects are not 822 messages.

> It seems like

It does not.

--