IETF 52 CalSched Working Group Meeting Thursday 21-Mar-02 Minneapolis, MN Introductions (Pat / Bob): Quick poll of those in the room: 5 are "new" to the WG: several already on the list and 2 were "Curious Users" Agenda: Agenda Bashing Guide to Internet Calendaring status CalConnect status CAP status Bruce Kahn graciously steps up to be scribe. Guide to Internet Calendaring (Pat): The Guide has been approved for release as an RFC; in the queue for the actual number. The guide is intended to be used by implementers of the C&S standards. CalConnect III (Pat): The one scheduled for next week was cancelled due to several factors (proximity to IETF, travel concerns, etc). Novell still wants to host the next non-virtual CalConnect in Provo, UT. The next CalConnect will be a 'virtual' one and is slated for the June timeframe, probably before the next IETF in Japan. The goals/benefits of having it virtual are: Decreased participation costs (supplemented by scheduled conference calls to keep things moving) We should be able to do this in a "virtual environment" given our design criteria. We will rely on secure instant messaging and regularly scheduled conference calls between participants. Virtual event will have the following: - Virtual environment will have the following: - POP/IMAP/SMTP/FTP/HTTP servers - A Secure collaborative environment for instant messaging, electronic conferencing, and discussion = All dialogs will be encrypted - Timed periodic conference calls with all attendees - Expectation is you are available for the duration of the two days - A set of scenarios to test and a table/matrix with items to test and "check off" as complete/broke/needs more testing Currently there are 7+ vendors interested in participating; no word on any Open Source interest yet. Tentatively targeting August/September 2002 as the timeframe for the next "in person" event. Calendar Access Protocol (CAP): Steve Mansour went over the CAP items Steve went over major items since the last meeting review. They were: - Information inconsistency between transport layer and application layer - there is no clear separation between application and transport layers. - A review VCARS and Queries is in order - We need to add iCalendar extensions to draft - Scheduling restriction tables need more work - Obtaining the UPN after authentication in BEEP - Getting UPNs from BEEP; Need UPN information to properly resolve other identity/security aspects in CAP but unclear how/if BEEP can provide this. Next Steve went over the status of version 7 of the draft. Slide items: - Mixing of Transport and Application Data - Fixed issues from last time - A few things remain (ex: get-capability) - Obtaining the UPN after authentication in BEEP - Proposed Security Model Change: - Current: deny unless explicitly granted - Proposed: grant unless explicitly denied We still have some mixing of the Transport and Application layers. This is due to lack of a clear definition of what each layer really is (it varies by reader so we must nail down the distinction and resolve the layering). Getting UPNs from BEEP. Paul Hill, our security guy, went over this topic. Paul is working with the BEEP and SASL folks to see what can be bubbled up for CAP to get/use. Currently, only WebMail is known to support it. We want to build BEEP and SASL on Windows (not only on Unix as is currently the case); Currently Paul is working on the port (as we have the WG meeting even). The model as it exists should work; He will look at it again to be sure once we have some more information. The next topic was the proposal to change the security model: We want to go from an implicitly Deny w/explicit Grants to an implicit Grant model w/explicit Denys. This scales better and is easier to evaluate. Essentially the evaluation of access is done from the CS -> Calendar -> Entity levels where any Deny at any point prevents access "below" that point. Steve, Paul and others will put together and propose some actual text pending tentative agreement on the conceptual change. Slide items: - SCHEDULE is gone, CREATE to cover it - METHOD value verb or status (STATE)? - BOOKED versus CREATED - DELETED (remember tombstoning?) - What properties MUST be maintained? - iTIP method - Abort versus bounded latency - Do we need abort capability other than latency - Reorder the draft so that it's easy to follow - iCal extensions are currently at the end draft The SCHEDULE command is gone. Reusing the CREATE command instead. This leads to some confusion about the use of METHOD in 'booking'; is METHOD a verb or a state? DELETED is a new METHOD value added to codify the "Tombstone" concept we previously had [explicitly or implicitly at some points -BK]. We need to clearly define what the CS behavior is with respect to deleted entries (ie: exactly what MUST be preserved for sync and other reasons, etc and what MAY be preserved, etc). ABORT vs Bounded Latency - Do we need to have an ABORT command? WE need to reorder the draft to make it easier to follow. The layout is more than a bit hard to read [especially the ABNF that appears in the back after its used elsewhere Slide items: - UIDs for components: - VCARs (Default, Predefined, Decreed) - VALARMs - Querys - Stored Queries | do we need them? - Scoping - component.prop - USING_PROPERTIES - USING_COMPONENTS - Querying for floating time events It is unclear how UIDs for some components should be added and how to deal with uniqueness. Also, it was questioned how some of the VCARs function (ie: predefined ones: Are they 'templates' for creating instances in each VAGENDA or are they copied. If they are templates, thats a new concept. If they are copied then the UIDS are no longer unique.) Regarding queries, how useful are stored queries given that the majority of queries used in C&S are 'time sensitive' and we have no ability to macro substitute values into saved queries. For example: Give me all my events that have an alarm that triggers in the next hour requires that the CUA send an explicit UTC time for the bounds. As such, tomorrow the query would be basically useless. There are questions/issues regarding the scoping of queries: The design currently restricts them to COMPONENT.PROPERTY [without any clear reason apart from some apparently implicit assumption about the underlying actual search engine like SQL. There is no clear definition for the use/need of USING_PROPERTIES and USING_COMPONENTS. They appear to be used as a form of shorthand at best without any functional need/description for them. There is no way to query for "floating time" entries. The query code expressly declares that all queried time must be in UTC but thats not possible for the "Every morning I go jogging from 6AM - 7AM no matter where I am" case. "Floating time" (aka Local only) entries have no associated time zone and as such cannot be converted and stored in UTC. Going forward: Slide items: - Post all issues to the list = Analyses for all = Recommendations for many - Targeting getting issues posted by end of the month - Work through the issues one at a time All issues will be taken to the list. There should be an analysis of each one and preferably a recommendation for resolving them as well (in the interest of time). Target posting all of the issues is by the end of March 2002 to the WG list. We will work thru the issues 1 at a time instead of "flailing" on several at once and seemingly resolving none. Pat will be the Keeper of Order. TBD will be the Keeper of Issues. Pat noted that there exist WG chair tools to aid in this process and she will investigate them and get the relevant parties up to speed on them. The cochairs/editors want more WG feedback on postings (ie: more than just 2 people going back and forth on a topic). Pat suggests that the "techies" take care to put the painful technical details/explainations into Plain English (TM) for the rest of the WG so that "less techie folks" are more inclined to participate. A quick poll shows that we may not have sufficient people to have a WG meeting in Japan. As such we want to get more progress done on the list before then. We will deal with the layer issue first. Much of this is due to the BEEP changeover. We want to finish off the concerns of "XML creep" and the layer bleeding before we get back to the actual protocol details. Pat put out a call for "anyone" with BEEPCOREC and SASL implementations to get engaged in dealing with this. Larry noted that SASL is lightweight in design. MD5 is "heavy duty" as the minimum base for CAP authentication. There are lots of SASL implementations and they mostly interoperate. Larry asked why not just adopt XML now with the new work the WG is doing. He finds it confusing to have both XML and iCalendar in the draft. This gets back to the prior issue about XML creep that we need to finally resolve. Steve responded that we could do the change but we need to make changed to xcal (which is expired now). Also, its odd to mix XML and iCalendar data but the mix is an artifact of the BEEP changeover. One example is the SEARCh command that is in XML but it has no data. Larry pointed out the mix of data dn commands/actions (ie: search) in 1 blob is still confusing. Steve: we need to better explain the mix in the design text and descriptions. Wrapup (Pat): The WG site calsch.org (or www.calsch.org) is up and has the drafts, texts and relevant links. Meeting adjourned. Respectively submitted by Pat Egen.