Subject: CAP Issues / ToDo List

From: George Babics <[email-masked]>
Date: Thu, 15 Mar 2001 12:45:39 -0500

Hi All,

  Here is a list of issues and todos for CAP.
The main goal is to have a central list, much like
Doug's old list.

  I compiled the list from Doug's old list, and various
posts and other emails.

  If there are things that should be added or
removed, please let me know and I will do it.

  BTW, the more people who review the CAP documents the better.
We especially need people to check the restriction tables.

George

Issues:
=======

- A number of issues with the various restriction tables.
  See CAP.

- CS do not preserve data integrity.

  Explanation/example:  someone can store a multipart/signed vEvent on their
  own calendar via CAP but when the owner goes to read it back the sig is
  gone (or its been 'resigned' by the CS).  For multipart/encrypted, CS's may
  decrypt and later reencrypt data back but it data security/preservation is
  not available.  A by-product of this is that when an invite arrives in your
  calendar scheduling queue all you will be able to tell is that your server
  says the data got there in some safe manner; no info as to the original
  signature, etc.  As such anyone with a valid  signature can send the
  calendar owner  entries and the CAP server will say this was signed and CAP
  verified it was".  In eMail you can see the senders signature (somewhere in
  the UI); with CAP you have no visual way to see _WHO_ signed it.

  Another way to look at this is: you sign and save an entry.  Your AA or
  someone else w/access to it comes in and modifies it. You later go back and
  reopen the entry but you will  have no visual clue as to its been changed
  by someone else since _I_ signed and saved it since my CAP server only says
  "This was really signed when it was saved".  Is this OK? (from Bruce)

- Security issue - mutual trust model. Is it in the draft?

  CAP implicitly requires some form of mutual trust model.  Is this
  explicitly called out in the draft even though it is implict in the design?
  Once something is outside of a firewall it is out of your realm of control
  just like email. (from Bruce)

- JIT signing/encryption:

  For some cases we may wind up having signing/encryption done by
  'downstream' CS's as the request routes thru.  ie: Paul @ MIT sent a
  REQUEST to his CS w/your CalID as 1 TARGET.  He sends the data
  unsigned/encrypted to his CS.  It sees your TARGET and by some TBD CS
  policy it decides that the data must be signed/encrypted so that it can go
  over, say, iMIP.  His CS does not have his key so it simply uses its own.
  (Additionally, if his server fanned it out to outside the firewall before
  this happens, the signer/encryptor is not even his CS).  So the first CS
  that can sign it does and then that is trackable all the way to you [after
  resigning by each subsequent CS in the flow path is done] (from Bruce)

- "Fallback/fanout to iTIP" concerns:

  If CAP request must get turned into iTIP then some extra coding must occur
  (ie: rewriting the proper ATTENDEE and ORGANIZER values from cap://... to
  mailto:.. ).  Since this may happen anywhere down stream from the
  originating CS, it is not guaranteed that the mapping/rewrites are accurate
  or correct; they are 'assumed' to be usable ("or the request is bounced
  back.").  Unfortunately correctness is only positively done at the starting
  point and not @ Yahoo on the way to Lotus. There are also cases like signed
  or encrypted data that would prevent this from being either doable or run
  the risk of voiding the signature. (from Bruce)

- The workflow path may not be a true path:

  The iTIP workflow path was a just that; a path (msg flow out followed same
  logical flow back).  In CAP, if 'rerouting' over iTIP occurs then the path
  is now a loop (CUA1->CS1->iTIP to MUA2/CUA2->MUA1/(CUA1?).  The last leg of
  getting iTIP/iMIP replies from the MUA1 to CUA1 so it can stuff them into
  CS1 in the "proper place" is just handwaved (or "left up to the user or
  their tools to do").   There is no clear why/how CUA1 would stuff in
  iTIP/iMIP messages into own queue instead of having CUA1 watch the incoming
  MUA1 queue for iTIP msgs and pulling them in or having CS1 rewrite the
  address so that msgs return to it directly.

  Paul or Doug state that users would only be confused (at best) or not aware
  of (at worse) any kind of signature msgs / warnings that they may see on
  their receiving end.  Bruce feels email is stillok in that if my MUA can
  see the sig then it tells me "This msg was signed by Doug Royer and its
  valid".  He does not think there is any usefulness in seeing "This request
  was signed and I, your trusted CS says its valid!" (esp. if we allow
  downstream servers to sign 'on your behalf' or 'at your behest' via some
  TBD mechanism).  Is data integrity within the CS necessary? Do we trust the
  CS to enforce integrity or not. (from Bruce)

- Look at changes required by CAP to make it compatible with CRISP

- Add changes to iCalendar the are required for CAP

- Do we want/need the CAP server to auto-mangle (aka autoinsert) an
  incoming stream of data with a generated UID?  Especially if > 1
  operation is going to be needed (ie: "Put this on my calendar and
  send invitations to the ATTENDEEs" = 1 CREATE and 1 or more
  other operations).  Wouldn't it be simpler and more efficient to have the
  client request a UID and have the CAP server generate and return it (ala
  NNTP does with Message-IDs)??   

  Besides, the client will _probably_ need to have the UID for other
  operations (like saving in its local store if is does sync work!). 
  (from Bruce)

ToDos:
======

- Review restriction tables.

- Review CAP Requirements doc to make sure that we have met
  all requirements.

- Make sure that CAP supports synch.

- Get CAP related changes into iCalendar

- Resolve issues with the various methods (e.g., how does one
  specify a specific attachment during an update).

- VTIMEZONE and IANA. (Doug's list)

- Remove unused definitions (Doug's list). I assume this means
  that we should remove all definitions that are in the definition
  section, but that are not used in the text.

- Document MAXSIZE and MAXRESULT (Doug's list).

- Document METHOD is stored in CS database (Doug's list).

- Only one 'CREATE' per UID (Doug's list).

- Multiple non-CREATE per UID (Doug's list).

- Fix the RESPONSE's to be consistent and multiple components,
  one for each TARGET (Doug's list).

- Section 2.4.4.2 - editor note: We need an example (Steve/Doug).
  Paul needs to read this note an example. (Doug's list).

- Merge changes Doug made into the doc. Some changes may no longer be
  appropriate (George).

- Section 2.6
  CALID - need to define that relative CALID must be consistent with
  the scheme specific part of URI as defined in RFC xxx. - Steve
  (Doug's list).

- Section 7.1.3
  Need to get IANA registration (Doug's list)

- Section 7.2.1.7
  Add an example of a partial result - we want to get something that
  matches some things, and on the ones you don't have access, you
  don't have rights to some of the components. George will write up
  something. (Doug's list).

- Section 8.0
  Response codes.  Need to make sure response codes in all drafts -
  iCal, iMip and iTip and examples. Error numbers need to be the same.  Put
  text about error codes in comments below the examples (so that
  people don't look at them as being required in their text).  Pat
  will look at the codes. (Doug's list).

- Section 11.0
  DTN, DTSTAMP, etc are implementations that may need to be considered.
  Restrictions tables may resolve these issues. (Doug's list).

- Section 12.0 (was section 13)
  This section is not ready for prime time. Need Paul Hill.
  Need an editors note. (Doug's list).

- Section 15.1.4 (now section ?)
   Submit entity for approval - John submitted to list.  Need to find.
   Get John's text and add back into CAP draft.  John submitted as a
   separate draft document. Use the MIME appeal verbage with John's
   additional text. Point WG at John's draft and say it should be
   included in the draft.  We need to also submit to April Marine as
   well. (Doug's list)

- Editor note: Remove references to VDATA (mistake) (Doug's list)

- Editor note:
  GENERATE UID is not a method.  It's wrong in section 7.1.2.3
  Ditto with NOOP - Section 7.2.1.6 (Doug's list)

- Write ABNF for VQUERY. (George)

- There were a few changes made by Doug in an interim document.
  These changes did not make the doc we submitted since we worked
  from another version of the doc. Most of these changes were new
  examples, or small changes to existing text.

- Should we provide some kind of template to follow for all
  the application protocol commands (CREATE,  MODIFY, etc).
  All we have right now is a brief description followed by an
  example. Is there anywhere where the syntax or form that
  should be followed clearly specified?

Examples:
=========

- search
- security
- fanout using iMIP
- basic operations that a user may do during regular use (George)
- the minimum data required to create an entry
- an entire short session from login to download entries,
  to log out.
- errors
- The UIDs in our examples are different than the suggested format in
  iCAL.