Calendaring and Scheduling WG (calsch) Wednesday, December 13 at 0900-1130 ==================================== CHAIR: Pat Egen Bob Mahoney Reported by: Walt Houser AGENDA: Agenda bashing 1. Guide to Interoperability draft update - inclusion of Timezone data - most recent changes - additional examples added 2. iCalendar updates (and iTIP,iRIP,iMIP if necessary) - Eric Busboom added as an Editor - Bruce Kahn added as Method Reviewer - changes (typos fixed, adjustments, etc) 3. CAP update - Command table work - Timezone efforts 4. Plans for Winter CalConnect __________________________________ 1. Agenda bashing - We will add a discussion of the web site, and a talk by Greg FitzPatrick on SkiCal. 2. The name of the Implementor's Guide is being changed to "A Guide to Internet Calendaring", will be resubmitted with that change immediately, and is targeted toward WG last call in the near future. Implementors' Guide to Internet Calendaring (36388 bytes) http://ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-02.txt This version includes Timezone data for which registry has been submitted to IANA. Recent changes include more explanation of the contents of the other WG documents. Additional examples are needed. 3. iCalendar updates (and iTIP,iRIP,iMIP if necessary) Frank Dawson has moved to Nokia, but will continue with iCAL implementation for small devices. We have added Eric Busboom of Software Studios as an Editor and Bruce Kahn Iris/Lotus added as Method Reviewer. We made a number of changes, typos fixed, adjustments, etc. 3.1 Eric found a several recurrence rules issues in RFC 2445. The specification is possible implement but it is remarkably complex. First, there are conflicts between type of frequency and the BY rules. The text says it is not legal to have BYWEEKNO and BYMONTH. Implementors have typically tossed the rule. There is no status code for invalid BYXX. This should be added to the interoperability tests. One attendee suggested putting a table in the text showing the legal and illegal rules. John Stracke observed that it is hard to imagine how a user using a GUI could generate an illegal rule. But the group felt this needed addressing. The BYSETPOS is potentially quite large number set. Outlook uses BYSETPOS to select the last Thursday of each month. But would interoperability require a large array? Internationalization is an issue that requires clarification. Do some countries use to other numbering schemes? There was a request for examples of each of these issues. 3.2 Two open source implementations are progressing, and will participate in upcoming interoperability tests. We should start pooling our test data. We need twisted minds to come up with test cases. Eric has the RFC 2445 and 2446 examples available on line. Bob and Pat will make these available online. 3.3 John Stracke noted that the CAP server must advertise for Access Control and query, CRISP change to add capabilities = none. This issue was posted to the mail list. 3.4 Eric listed additional issues for CAP: - Data integrity - The trust model - Paul suggested that this be further discussed on the list. Some list participants had concerns that iCAL trusted all the data. Per Paul this is a basic assumption of SASL. There is no way to sign each event with a personal certificate. - Signature and encryption - Fanout - turning iTIP and CAP workflow - Define iTIP and CAP workflow 3.5 iTIP and iMIP updates REQUEST is overloaded. Added to the text the proposal to use CONFIRM 1) reply to REFRESH and 2) changes in ATTENDEE and ORGANIZER. CONFIRM has itself become overload and we propose dropping. Who sends a COUNTER proposal? When attendees are added or removed, do you send to affected attendees only, or all attendees. We decided to send just to affected attendees and not bump the sequence numbers. RFC 2447 does not say which MIME encapsulations must be supported. We oppose to add the requirement that conforming iMIP implementations must be able to receive the described encapsulations, although the ability to generate these encapsulations is not required. Generate both a text version and iCALENDAR attachments. Implementations have to support multipart mixed MIME type. Patrik advised to check the MIME standard to be sure of the combination of acceptable. Garbage in the examples ("Error! Bookmark not defined") have been fixed. New problem: No way an attendee can say to remove me from the event. Options: - Comment to ask to be removed by the organizer. - Reply with ATTREMOVE - Reply with a COUNTER proposal to delegate and remove oneself. This risks overloading COUNTER. The document format is back in MS Word. Plan to convert to XML using RFC 2629 which includes the DTD for RFCs. The product "Email Effects" generates ASCII art, and was recommended for our use. Restriction tables Updated the examples to reflect 3.6 To do: 3.6.1 End-to-end review. John Stracke and another list member reviewed it but it is a hard read. More review needed. 3.6.2 Asynchronous error reporting. Background job to propagate iMIP. No way to handle error replies. 3.6.3 Review schema definition. Doug Royer did it in an SQL-like fashion, and it needs to be updated. Many examples are needed. The current ones were done to flesh out the protocol and are not always reasonable. When an organizer creates an event it will appear in his calendar as created. The attendees are invited in a conceptual queue using the REQUEST method. Is this one or two CAP actions? What is the minimum event? What is returned when I ask for all properties of this minimal event? What if I have permission to write events but not permission to write particular properties? Backing out written events is hard across multiple stores. Is the command set enough to support synchronization? Who are synch vendors or experts that can review the commands? We plan to get this done by January 22. We will try to get it ready for the next IETF meeting. 3.7 CAP update is resubmitted as version 3. The WG charter was resubmitted. CAP Requirements (53021 bytes) http://ietf.org/internet-drafts/draft-ietf-calsch-capreq-04.txt Calendar Access Protocol (CAP) (217860 bytes) http://ietf.org/internet-drafts/draft-ietf-calsch-cap-03.txt 4. The Winter CalConnect is planned for the third week in Feb 2001 in San Jose area. Interoperability testing will address scheduling and mime multipart. We need to go through the examples and recurrence rules for testing. (Do we need external access to the Internet?) We are discussing details with a large university in the area. 5. A general website for calendaring issues to be created. Plan is for www.calsch.org to be active in about three weeks. MIT will provide a home for this. 6. Greg FitzPatrick spoke about SkiCal, an extension of iCal. This effort adds properties extending rfc2445. Example: Required: shoes. RECOMMENDED: warm clothes PROHIBITED: suits and ties Recommended lists of terms to permit discovery and interoperability in language. A draft will appear after the IETF reopens the drafts queue. Note: There are a number of implementations currently using the existing draft. 7. General Discussion 7.1 XML interpretation of iCAP. Microsoft is doing iCAP in XML. SkiCal is doing an XML schema; and they found 63 syntax errors when validating the current schema. There is no nesting, so the mapping is one-to-one. Lisa Lippert has left Microsoft (where she was the champion of iCAL) Chairs will be speaking with Microsoft about a new contact. SkiCal will prepare DTD and compare the schemas. 7.2 Question: How should we handle iCAL events when the recipient server wants an XML version? 7.3 Bruce raised the issue that the delegation model does not specify the delegation and retraction of delegation. What happens to the status of the redelegation? Let the organizer decide? The organizer needs to decide to uninvited? Or is every redelegation in the chain dropped? Double delegations? What if one is a delegatee from two or more bosses? 7.4 Walt Houser mentioned the Contextualization of Resolution BOF (c15n), which seeks to address how to incorporate elements of contextual control information in determining the "appropriate copy" of a resource. This is generally applicable to all URI resolution, but it is more specific than "web caching". Software systems being built to solve this are using specialized, non-interoperable, non-scalable approaches. The individual's context could be implemented in the client using vCard. At present there is no working group addressing this. Minutes respectfully submitted by Patricia Egen and Bob Mahoney