Subject: Re: iTIP REPLY question

From: "Jay Parker" <[email-masked]>
Date: Thu, 15 May 2003 00:27:56 -0600

>
>>>> [email-masked] 05/06 9:40 AM >>>
>
>
>Jay Parker wrote:
>
>>>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.
>
>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.
>
>> 
>>>>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?
>
>Defined in 4.2.2 of draft-...-10.txt: READBUSYTIMEINFO
>
From 4.2.2... 
 
  " CARID:READBUSYTIMEINFO -  Specifies the "GRANT" and "DENY" rules
that
      allow UPNs to search "VFREEBUSY" components."
 
If I understand it correctly, the iTIP steps for UserA performing a
busy search of UserB's calendar are as follows:
1. UserA creates an iTIP REQUEST for VFREEBUSY and stores it in UserB's
calendar
2. UserB's CUA (or a bot) processes the request and creates an iTIP
REPLY with VFREEBUSY information and stores it in UserA's calendar
3. UserA queries his calendar for VFREEBUSY replies to his request and
processes them.
 
Does READBUSYTIMEINFO apply to all 3 steps in the process?  It seems to
only apply to step 3 when UserA SEARCHES his calendar for the replies. 
What am I missing?  I would have expected a CARID:UPDATEBUSYTIMEINFO or
something similar.

>> 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?.
>
>The CUA never needs to ask for VCARs. So yes.
>
>> 
>>>> 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.
 
True, the returned VFREEBUSY REPLY is not booked, but neither is the
VEVENT REPLY that is created.  Isn't it the CUA processing the REPLY
that would need the UPDATEPARTSTATUS rights?  
 
The CAP draft does not specify which rights would apply for each iTIP
step of a busy search or of an appointment request/Accept secquence.  If
someone would like to take a stab at it, I'd greatly appreciate the
detailed response.

>> 
>> 
>> 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?
>
>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.
 
CARID:READBUSYTIMEINFO in 4.2.2 specifies the right to "search"
VFREEBUSY components.  Does that also imply the right to request them or
create them in response to a request?  If not what does?

>
>> 
>>>>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.
>
>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
>> would the user's MUA/CUA that is processing the iMIP message get
the
>> 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
>> prevent the MUA/CUA from spoofing someone's email address.
>
>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.
>
>>>>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?
>
>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.
>
 
Hmmm...  Yet another requirement on the CAP client that could be
implemented at the store....
 
Are there any efforts underway for a thin client version of CAP that
pushes the calendaring logic to the store?  Most collaboration products
such as Notes, GroupWise and Exchange already implement calendaring
logic that would facilitate a 'CAP Thin Client ' protocol with real-time
transport.  A thin cient busy search could request information and
receive immediate results.  A meeting could be scheduled in a single
command that created the organizer's entry, created each local target's
entry and converted external targets into an SMTP/iMIP message for
external users.  A single command could also be used to tell the
store/agent to book a request and create the associated reply...  Is
there interest for a CAP thin client protocol or is everyone content
with the thick client approach?

>>  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
>> 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?
>
>It does not.
>
That's unfortunate for administrators; instead of choosing a secure
calendar store, they must now concern themselves with every possible CAP
client that might run against 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: Thu, 15 May 2003 13:57:59 -0600

Jay Parker wrote:

>  From 4.2.2...
>  
>   " CARID:READBUSYTIMEINFO -  Specifies the "GRANT" and "DENY" rules that
> If I understand it correctly, the iTIP steps for UserA performing a busy 
> search of UserB's calendar are as follows:

> Does READBUSYTIMEINFO apply to all 3 steps in the process?

It applies to search. So if they VQUERY for VFREEBUSY
the VCAR applies.

 > It seems to only apply to step 3 when UserA SEARCHES his calendar for
 > the replies. What am I missing?

Nothing, you are correct.

> I would have expected a CARID:UPDATEBUSYTIMEINFO or 
> something similar.

There is a VCAR called REQUESTONLY which is would apply to your
step (1) above.

> that would need the UPDATEPARTSTATUS rights? 

Yes, the UPDATEPARTSTATUS rights would allow or block a CUA from
just updating the currently authenticated UPN's entries PARTSTAT
parameter value in the TARGET.

> someone would like to take a stab at it, I'd greatly appreciate the 

So far no such proposal has been made.

>  >> VFREEBUSY components in an iTIP free busy reply because the VFREEBUSY
> VFREEBUSY components.  Does that also imply the right to request them 
> or create them in response to a request?  If not what does?

It allows for search rights only.

> pushes the calendaring logic to the store?

No, it would have to push is to a CUA that did the work for the thin
client. The same as if you wanted a WEB calendar. You would need
to implement a CUA that took HTTP requests and send them to the CS.

The terms 'CUA' and 'CS' are conceptual things, there is nothing
to keep them from being built into one binary program.

 >  Most collaboration products

The same with an MUA. There is no reason that you could not combine
a MUA + CUA, CUA + CS, MUA + CUA + CS into one binary program.
However they are separate layers as far as the protocol and
interoperability is concerned.

--