Minutes taken by Richard Shusterman and Pat Egen WG co-Chair Pat Egen acted as session chair for the meeting. There were 31 people in attendance. Update on draft activities: The chair showed the current Draft/RFC numbers for Calendaring and Scheduling. These included the following: iCalendar - RFC2445 iMIP - RFC2447 iTIP - RFC2446 iRIP - draft-ietf-calsch-irip-02 CAP Requirements Doc - draft-ietf-calsch-capreq-02 Implementer Guide - draft-ietf-calsch-imp-guide-01 CAP - draft-ietf-calsch-cap-03 ** ** located at ftp://royer.com/pub/CALSCH - this was published to the list prior to Pittsburg but not in time to make the IETF-Drafts file area. It will be reposted with additional editing changes two weeks after Pittsburg. For unknown reasons, "guide to implementors" was not posted to the IETF Announce list, even though it was submitted and accepted prior to the deadline. An email did go out with the correct URL link (from IETF-Drafts). We pointed attendees to that link and asked that they give the document one more "look see" and put comments on the list. iCalendar/iMIp/iTIP Update: The Chair went over the results of the first CalConnect Interoperability testing. The key items are noted on the Powerpoint slides that will be sent with these minutes. The biggest issue was MIME and multipart handling. Every vendor appears to do it differently. There will be another CalConnect in the Fall/Winter timeframe and the chair will post the details by the week of 8/15. One issue is funding for the Open Source developers. We would like to see them at the testing, but need to overcome the funding issue. No solutions were suggested. The slides show that no scheduling was tested. Steve Mansour from Netscape stated that there was some scheduling tested. We will update our results to reflect that comment. We solicited vendors to provide examples that we can use during testing. If vendors then test to those examples, we have a better chance of ironing out incompatibilities. Bob Mahoney will post a note to the list asking for examples. We will be working with the IMC.ORG people (Paul Hoffman) to put up a matrix showing what has been implemented by which vendor. This will be a living document that will continually be updated as vendors add interoperability and standard support. Implementors Guide: Bob Mahoney (co/chair) went over the Implementers Guide. He stated that we are going to change the name to Guide to Internet Calandaring Standards so that it can be of use to end users as well as developers and implementors. We added George Babics from CS&T as an editor. We still need more feedback from real implementors. iRIP update: The Chair gave an update on the status of resubmission/non resubmission of iRIP. Some dialog from the list says resubmit, some says do not because the functionality of iRIP is in CAP. John Stracke submitted a new draft (during Pittsburg) using what he calls CRISP - which is a smaller version of IRIP that pulls out "verbage" not in CAP and resubmit as a standard draft. John said that CAP can handle iTIP so it can be used as a iRIP-only server. The Capability command would indicate that new iCalendar components like VCAR are not supported. Since this was posted this week, people will need to have time to read and comment on this draft. One attendee objected to the RFC track - said he found it confusing and that it should be incorporated into CAP. Another attendee said it's still CAP but limited. The chair stated the discussion should be on the list. CAP Update: The Chair then went over CAP. There has been activity but the draft did not make it in time to the draft submission. There will be ongoing telephone conference calls with the editors and the chair will act as Scribe and then post the minutes and key items to the list (in succinct format). We will at some point need to register the CAP URI and port with IANA. The charter for the WG is being updated. One item added is to Evaluate readiness for interop in Dec 2001. The charter will also be updated to make the dates accurate. Steve Mansour, CAP editor, went over an example Restriction Table. He said there is a lot more work that will need to be done on each component table. The next effort is to take it to the list and get more feedback. These tables are the key thing missing from CAP and is part of the final process to complete the draft. The editors intend to follow iTIP examples for tables. He went over the fact there will be lots of transactions per command, many responses, one per transaction, and no rollback. He explained the layout of the table and then went over the CREATE COMMAND table. The example will be included with the Powerpoint slides. Other key items noted were: - An explanation of "2.0" for VERSION - An explanation of 0, 0+, 0 or 1, 1, or 1+ - As needed, comments - Why not ABNF - Why not create (store) VFREEBUSY. - If no CMDID, cannot pipeline The restriction table discussed follows: This is an example for the CREATE command. - - - - - - This is the proposed format for CAP restriction tables. Their purpose is to define the composition of commands sent to a CAP server and the composition of the command replies. While the tables list every property, it is not meant to define the meaning of the property. It is meant to define presence or absence of a property. There will be a RESPONSE-STATUS for each VCALENDAR and/or component created, modified, deleted, or requested. The number of response status valuesreturned MUST be equal to the number of TARGETS times the number of objects in the command. The responses MUST be ordered first by TARGET then by the order of the objects as supplied in the command. Client Restriction Table for the Create command Component/Property Presence Comment ------------------- ---------------------------------------------- VCALENDAR 1+ CMDID 0 or 1 If CMDID is not supplied, then there must not be pending replies to previous command. VERSION 1 MUST be 2.0 VCOMMAND METHOD 1 MUST be CREATE. TARGET 1+ VCALENDAR 0+ CALMASTER 1 NAME 0 or 1 The user friendly name, localizable. OWNER 1+ RELCALID 1 This is only present when creating a new calendar. This is the name of the calid to create. TZID 0 or 1 VCAR 0+ CARID 0 or 1 A reference name DENY 0+ permissions denied. Note, there must be at least one GRANT or DENY within the VCAR. GRANT 0+ permissions granted. Note, there must be at least one GRANT or DENY within the VCAR. VQUERY 0+ EXPAND 0 or 1 Expand recurrences or not MAXRESULTS 0 or 1 Limit the solution set to no more than this many enries. MAXSIZE 0 or 1 Maximum number of octets to transfer QUERYNAME 1 Name by which this query is referenced QUERY 1 The query VEVENT 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTEND 0 or 1 if present DURATION MUST NOT be present DTSTAMP 1 DTSTART 1 DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ORGANIZER 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUSSSSS 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VTODO 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null. UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTSTAMP 1 DTSTART 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ORGANIZER 1 PRIORITY 1 PERCENT-COMPLEEEEETE 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUSSSSS 0 RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS/CANCELLED URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VJOURNAL 0+ METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ATTENDEE 0 DESCRIPTION 1 Can be null. DTSTAMP 1 DTSTART 1 ORGANIZER 1 UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 EXDATE 0+ EXRULE 0+ LAST-MODIFIED 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ RRULE 0+ SEQUENCE 0 or 1 MUST echo the original SEQUENCEnumber. MUST be present if non-zero. MAY be present if zero. STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED SUMMARY 0 or 1 Can be null URL 0 or 1 X-PROPERTY 0+ VALARM 0+ ACTION 1 ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ VFREEBUSY 0 VTIMEZONE 0+ MUST be present if any date/time refers to timezone DAYLIGHT 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSET 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ LAST-MODIFIED 0 or 1 STANDARD 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ TZID 1 TZURL 0 or 1 X-PROPERTY 0+ Server Restriction Table for the CREATE command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ TARGET 1 VERSION 1 MUST be 2.0 CMDID 0 or 1 MUST be returned if the request contained a CMDID VALARM 0 RESPONSE-STATUS 0 if not creating a calendar 1+ if creating a calendar VCAR 0+ RESPONSE-STATUS 1+ * 0 No other VCAR properties are present VCOMMAND 0 VEVENT 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present VFREEBUSY 0+ RESPONSE-STATUS 1+ * 0 No other VFREEBUSY properties are present VJOURNAL 0+ RESPONSE-STATUS 1+ * 0 No other VJOURNAL properties are present VQUERY 0+ RESPONSE-STATUS 1+ * 0 No other VQUERY properties are present VTODO 0+ RESPONSE-STATUS 1+ * 0 No other VTODO properties are present Issues: freebusy - a cap server should dynamically calculate freebusy information we recommend that you cannot create, modify, or delete freebusy composers - - - - - Attendee Questions: John Stracke said if CMDID is 0, flag to indicate no pipelining? Steve showed the server response table to create. IS * if no other properties are present. He then showed the order of response codes, target first, then components as they were supplied. At the completion of this table review, the Chair asked for a show of hands of how many people have read CAP - a few hands. How many people have read implementors - a few hands. How many people are just waiting for a calendar standard - the majority of the audience. The chair stated she is trying to make list less intimidating (i.e. less combative) in order to provide a good vehicle for people to ask questions or provide answers. She then asked did anyone need/want to know why we need CAP and where it fits - a few hands. Some time was spent explaining how CAP fits into the calendaring area. CAP is the piece that manages how you write calendar entries to your datafile or "calendar Store". It kind of equates to POP in the email world. General Questions/Answer session: The chair then reiterated that we are actively trying to get interoperabilty and completing the missing piece. Then asked what is everyone here expecting? One person, a user representing 230K (Dept of Energy) users, uses Outlook + calendaring products. Question: Is there a place to figure out each vendor's compliance. Bob - No, but working to post something soon. That's the IMC.org work. Question: We also need to identify contacts for each vendor. Patrik - pointed you at Paul/imc.org to force vendors to test for interop. Dave - Can you publish list of vendors who don't support a standard? Patrik - It's still up to the vendor to expose/promote their support for standards. The session officially ended at 2:00pm. One person came up to the chair at the end to ask if there was an informal web site about calendaring products etc. We may look into setting something like this up. Watch for details soon. Thanks to Richard Shusterman for taking notes during the session. Respectively submitted by Pat Egen, co-Chair.