CalSch meeting at 42nd IETF - Chicago We began with the usual agenda bashing: - IESG status on drafts - Locating Draft status - IRIP status - CAP requirements - Next Steps IESG status on drafts ICalendar, iTIP, and iMIP have gone through IETF last call and have been offered by our Area Directors (AD) to the IESG for approval as Proposed Standards. The ADs noted a few comments about the drafts, but they have been passed, and will be in the hands of the RFC Editor soon. It may be possible the Editor will request minor changes before they are assigned RFC numbers. However, these three are nearly ready to be published! Locating Draft Working Group Last Call completed with no major objections. It was noted the draft contained incorrect references to documents. The editor said he'll remove these. After that, the draft will be ready for review by the ADs. To expedite the review, they will post the document for IETF Last Call while they review it, instead of completing their review first. Patrik Falstrom reviewed the steps from Working Group draft to Proposed Standard, and listed the times the document may need to be edited during this process. iRIP status The iRIP team reviewed their work and their plans. They've released a couple of drafts which have garnered numerous comments. They divided the work to be accomplished in two parts, clarifications, and open issues. Clarifications are changes which are not controversial and will be accomplished in the next draft. Open issues are problems for which the WG has not found consensus. Clarifications to be incorporated are: - Changes to the state diagram - Adding a command table - Discussion of server behavior if timeout occurs during ICALDATA command - Better error definitions and examples - Adding referral syntax and examples - Specify UTF8 as default charset. Other charsets are allowed as given by MIME We then began a discussion of the open iRIP issues. There is a choice to be made regarding the server's behavior on a referral. The server can simply return the referral address, or it could both return the address, and attempt to perform the operation on the client's behalf. We were unable to resolve this during the meeting, further discussion on the list will be necessary. However, there was noticeable sentiment in the room to choose the first alternative as being simpler. Attempting to perform the operation may induce the server to attempt an iMIP connection which would likely not give acceptable real-time performance. Supporting iRIP will require sysadmins to deploy new server daemons across their nets, and will require firewall modification to allow the protocol to pass between nets. Some expressed the fear these changes would inhibit deployment of the protocol because it would potentially weaken a net's integrity. It was proposed the iRIP command set be submitted as an extension to SMTP. This avoids punching a new hole in a firewall for the new protocol. In support of this proposal, it was noted that the fax WG is considering extensions to SMTP to support fax transmission across the net. The response to this was the fax WG's requests to extend SMTP are far from accepted. Those familiar with email protocols thought it unlikely that such extensive changes to smtp to support iRIP capability would not be accepted by the email community. AD Patrik Falstrom suggested that this idea may find a warmer reception in the metad group. It is unclear when an ICALDATA is complete what should become of the recipient list in the object. Should it be saved, or does the list reset? No resolution was apparent in the meeting. This will require further discussion on the list. Finally (as far as open iRIP issues are concerned), whether iRIP must return all error codes defined in iTIP is unclear. The editors will seek the WG's advice on the list. Schedule for iRIP Work The editors anticipate releasing the next draft within 2 weeks. Over the next 6 to 8 weeks the editors expect to make further revisions with the guidance of the WG. They anticipate we'll be ready for WG Last Call in approximately 8 weeks. By the 43rd IETF, an iRIP protocol should be ready for AD review prior to an IESG ballot. CAP Requirements Draft Having disposed of iRIP, the WG next focused its gaze on CAP requirements. The editors outlined their hopes and goals for the document. They want to capture as many requirements as possible so the WG can review and agree on the requirements before proceeding to design the protocol. They anticipate, as do many others within the WG, that a usable protocol will be subtle, complicated, and big. Agreeing on the requirements should erect a sufficiently tall barrier to casual changes to the design in the future. The WG spent some time debating the future of the document once it is written. This was returned to several times during the course of discussion of the requirements so far gathered. The authors anticipate requirements will break down into five categories: Basic, Administrative, Component Management, Access Control and Notifications. It was noted that Access Control refers to calendar object access, not access to calendar daemons themselves. The authors polled the WG if the explanations were sufficiently detailed. The WG seemed generally satisfied, although it was noted that the requirements while clear are not necessarily consistent. Requirements are not yet sufficiently abstracted. As a result, some are stated as scenarios or examples rather than a explicit condition that must be met by the protocol. Some worried the authors intended the scenarios to be normative. Eventually it was understood they are to be explanatory, but that the scenarios currently are the vehicle to express requirements not yet fully conceived. The authors then began to outline what constitutes the different catagories of requirements. Basic requirements include calendar object manipulation such as add/modify/delete actions. Requirements for the connection between the CUA and CS are considered basic. The WG noted requirements for Searching Calendars will be necessary. Operations such as discovery, lookup and search should be included. Notifications should support 2-way communication between client and servers. Protocol Security requirements must cover 3 areas. The protocol must provide for authentication between clients and servers. It must be possible for clients and servers to identify each other. Finally, the protocol must provide a means to determine if particular actions are authorized. The CAP requirements authors offered to keep our ADs apprised of the WG's discussion of the requirements. AD Patrik Falstrom noted that our WG's approach to setting requirements before embarking on design has not been widely used within the IETF to date. Others will watch our progress with interest. To sum up the requirements discussion, the authors expect to have a new requirements draft prepared in time for the 43rd IETF meeting. They expect to be able to enumerate major sections of the requirements by Oct 9th. They will continue considering comments until Nov 25th. Comments after that date will need to be included in the revision to follow the next meeting. While it is not necessarily true the requirements document must become an RFC of the IETF, it certainly should have a strong role in shaping CAP's design. Deviating from the requirements must not be entered into lightly. A number expressed the hope this would become an informational RFC for the benefit of future implementors. Finally, the model document author agreed to resurrect the model document draft, as it has expired. However, he made no promises on when this feat would be accomplished. Chairman's Summary iCalendar, iTIP and iMIP are in the hands of the RFC Editor. Their issuance as RFCs is imminent. Locate will be presented to the ADs for their review. Within the WG, iRIP requires further revision. The WG must provide additional review, commentary, and revision for CAP Requirements. It was proposed that SCAP be removed from our Charter. With our agenda completed, the chairman adjourned the meeting.