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?
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?
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.
toOr does each store need to implement additional VCARs such as a hypothetical CARID:UPDATEBUSYTIMEINFO. Do I need to create a VCAR
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.
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.
via3. A CUA that is ready to process an iTIP reply that was delivered
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.
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?
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature