CALSCH Working Group minutes: 15-Mar-99, 3:30PM - 5:30PM Pat Egen and Robert Moskowitz - chairs Agenda: Assign Volunteer Scribe: Alex Taler of CS&T and Bruce Kahn of Iris CAP Requirements: WG last call status XML/ICAL syntax resolution iRIP Update iTIP Identified issues/defects CAP Design Group status update As of now, rough consensus on XML vs iCal is to stick w/iCal for syntax. In the future we may consider moving to XML. After delta changes to CAP Requirements are in, it will not go to RFC but kept for historical reasons IRIP discussion: Steve Manseur & Andre Courtemanche. Issues from IETF 43: - Resolved queuing issues in new draft - Editorial fixes - Revised draft to list Remaining issues: - Overlap between iRIP and CAP: - Keep similar syntaxes so can sub/super set features. Uses are still semi- disparate. Need to get feedback from Steve on how to best differentiate them - Request & responses are now tagged so can do > 1 request/response at a time - Fan out response in multiple MIME blocks so data won't have to be merged into 1 block. Now each CalID will return separate MIME block(s) Authentication/security Issues: - Trusted relationship between iRIP servers not sufficient. Will want to borrow CAP authentication info/schema to re-use it. - May need to authenticate users as opposed to calendars; a new concept for us. - Others to be posted to the list New Editorial issues based on new draft - Will try to keep CAP and iRIP similar features in sync as they progress Next steps: - New draft by next IETF and one by 15-Apr-99. - Track CAP progress iTIP & iMIP Defects: Steve M. & Frank Dawson - These solutions will be submitted to revise iTIP drafts. Overloading iTIP REQUEST: - Current method used for invite, reschedule, update, confirm, reply to refresh. A reschedule and/or update are semantically different than confirm or Reply to REFRESH - Propose: New CONFIRM method to be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST method. Identify sender of iTIP COUNTER: - Can't identify who COUNTER came from because all of the ATTENDEEs will appear in the method. - Propose: Only specify ORGANIZER and countering ATTENDEE in method. - Caveat: Can still forward or delegate a REQUEST to change participants. However, only the ORGANIZER can remove a participant.; This removes functionality and can be done w/an iMIP header but won't work for all iTIP. Will revisit how to best do this on the list. Intolerant iMIP receiver: - MIP specifies numerous MIME encapsulations for iCal/iTIP msgs. It doesn't require that an implementation MUST be able to receive each of them. This is leading to interop problems w/different CUAs. - Propose: A conforming iMIP implementation MUST be able to receive each of the MIME encapsulations shown in the iMIP examples.; It does not have to GENERATE them, just RECEIVE them! Why not just use multipart alternative instead of multipart mixed. A minimal MIME compliant mailer must grok multipart mime so this may be moot. Adding/deleting ATTENDEE: - If ORGANIZER adds or deletes an ATTENDEE, do they really have to send the reschedule to all of the other ATTENDEEs? - Propose: No, they can send the REQUEST w/the new ATTENDEE info to just the new ATTENDEE. It is up to the CUA. It is an implementation dependent issue if the SEQUENCE number needs to be incremented when you add/delete an ATTENDEE. iCal does not require SEQUENCE rev if a new ATTENDEE is added so this won't break iCal or cause a revision there. CAP Design Group discussion: Frank Dawson Tomorrow's session will be tutorial on what the design group and the list have been working on. Topics: Status of interim work Proposed schedule for work in 99 CAP design summary (Continued tomorrow) Design Goals: Leverage iCal and iTIP work Design to CAP Reqs doc Validate reqs wherever possible; Some deferred stuff was pulled in (ie VCARs) based on WG list feedback. Keep list active in providing feedback and consensus (vs "telling" them what the WG have done) Submit draft for July IETF mtg Activities: - 2 interim meetings: NYC 2/99 @ Morgan Stanley & Menlo Park 3/99 @ Sun - Identified design approach for CAP data model, addressing, system model, state diagram, query, calendar access rights and command set - Changes to reqs doc (moving in access rights, server fan out, the concept of a 'user') - Need to gain closure on transport - Poll of audience shows about 25% to 33% of the folks are new to CalSched so we went over the data and system model. Data Model: CS (calendar Store): vTZs (timezones) Properties (CS owners authids, CS's local time or time info, etc) vCARs (access rights) Calendar(s): Calendar(s) Calendar Properties () vCARs vEvents vAlarms vTodos vAlarms vJournals Questions from the floor and answers: Calendars can have Calendars within them and the "parent" of the 'top' one has the CS as its parent. CS is what the CUA connects to. What is meaning of "sub calendars"? Use inheritance of vCARs from parents, etc to see what access a user has. Does naming imply hierarchy (ie: subcalendars vs parents): Calendar addresses have opaque names and hierarchy is NOT based on any schema of the CALID format so no, no implications! Names are just pretty human readable indicators for reference. What is use of "sub calendars": To emulate how people organize their time, or other info. For example, my "soccer" calendar and my "work" calendar can be subcalendars of my main calendar. Other examples are parent calendar of a building and then subcalendars of resources in it. This model is a relationship model, not a storage model for data. vCARs are inherited down but info is NOT inherited up! There are lots of client side and undiscovered issues to consider still. Needs to be thought out more and covered on the list! Should multi-value PARENT properties be allowed? There are inheritance issues to consider WRT vCARs before just saying yes. There are also issues of having 'split' or disparate stores that contain the sub calendars (ie: Kids store on the ISP and my store at work!) Would aliases for calendars be useful? What about mulitple personas? This can have/require multiple authIDs and names, etc to pull together. Can CAP be used by 1 CUA to access > 1 CS at a time? Yep. Is Group calendar support something to pull into initial release too? Is it necessary in the protocol or can it be done by CUA? Group Calendar = aggregate > 1 calendar into 1. VCARs could be used to emulate this but its ugly! An aggregate calendar could be an actual calendar instead of just an aggregate one. This needs to be taken to the list too. CAP Addressing Model discussion: A CalUID conforming to RFC 1738: caluid = [://[csid][: = "cap" = < any 7bit UIS-ASCII identifier> Examples: cap://calendar.example.com/user1 user1 (relative to the CS; equivalent to the one above) cap://calendar.example.com/conferenceRoomA cap://calendar.example.com/923345346-foo RFC 1738 obsoleted by ~RFC 2368 CAP System Model: Internet SMTP/MIME + iTIP is really CUA <-> CUA but it could be CS->CUA as well. iMIP could be used between CS1 and CS2 but then its addressing CS2, not CUA 2 Need to clarify what is mandatory and what is not in the model. Fan out IS a requirement of CAP now. CAP between CS1 and CS2: If CS acts as CUA then is it Fan out or not? Isn't this just a requirement for a fatter CS? If iMIP is a requirement then why is CAP between CS's of any use (if there is no authentication between all CS's)? There was lots of discussion on this that will be brought up on the list. The State Diagram was drawn. Questions from the floor and answers: What good is CAPABILITY in RTS state? Why not... Its nonsensical in this mode as a CUA should have up front checks not 'spur of the moment'. What is the use of CONTINUEs? To handled bounded latency issues. Latency is not that bad on low latency intranets but can be larger on internet due to routers, etc. Clients on high latency connections will want to avoid the RTS state. Missing assorted links in diagram from last revision. Frank to revise based on notes from last 2 interim meetings. Need comment on how to handle tagging and multithreading, etc. Could be problems w/queued requests and reauthentcation, etc. Next, there was a description of a Query: Based on SQL clause/statements Specified in a VQUERY component Example: BEGIN:VQUERY QUERYID:Read today's event QUERY: Select=UID,DTSTAT,DTEND,SUMMARY;FROM=VEVENT;Where=DTEND >= 19990315T143000Z and DTSTART <= 19990315233000Z; orderby=dtstart asc, dtend, summary, uid END:vQUERY Question/Answers: Why is it not just SQL? We already have concept of name=value so use it. Still, why just not use SQL?? Don't want to get raw SQL data that doesn't map 100% to iCal. Stuff in SQL may not be desirable now (ie: weighting of results) but may want later. If we use SQL syntax then we gain an already understood behavior; We just didn't want to get the mods that we'd have to make to avoid non-doable stuff (ie: "today"); There could be problems w/vendor extensions of SQL that dont interop so a strict separate syntax prevents that. Revisit on the list (did in Dec 98 but no responses). Pat asked for feedback on the list. Calendar Access Rights: Need to decide on the granularity of the CARs; property level, entry level, etc. Specified calendar access for: Given authenticated calendar user (PRINCIPAL) and either: Particular calendar access policy (POLICY) or; Particular set of calendar operations (ACTION), Relation to a set of calendar components, calendar properties, component properties, property parameters (OBJECT), Particular property or parameter values (VALUE). Specified in vCAR calendar component No rights assumed; must be given them! There is no way to revoke rights (yet?) Need feedback on how to manage this. Can I set VCARs that say "Frank can only edit my calendar between 3/15 and 3/19"? You can filter based on property values but not for this case in particular. Suggestion was it could be attempted using ROLEs. Example: BEGIN:VCAR CARID:Read public events GRANT: PRINCIPAL=foo;ACTION=READ;OBJECT=VEVENT DENY:PRINCIPAL=foo;ACTION=READ;OBJECT=CLASS;VALUE=Private, Confidential END:VCAR This example grants public R access to all docs and revokes access to Private or Confidential CLASS valued items How can I create a VCAR that prevents FOO from reading the CLASS: property? How about: DENY:PRINCIPAL=foo;ACTION=*;OBJECT=CLASS Can a properties value be used to govern a vCAR? Yes. Unclear how this is different from above except the missing VALUE=; What about adding a new SCOPE parameter to target the scale to filter out: property, doc, etc How about a SCOPE property for the right (all components, etc)?? Do we want to add expressions to build "Give Frank Access from 3/15/to 3/19" to the VCARs? What about adding ranges of values, etc.??.. Take to list as we need more input on this. This will be done by Tony Small. Policy support is mandatory, Grammar is optional. Assorted proposals will be posted to list with indicator as to status within the WG (ie: draft, proposed for CAP v1, etc). CAP Command Format: CUA command request format: