IETF68 ====== Calsify Working Group minutes for March 19, 2007 ================================================ Chairs: Eliot Lear Aki Niemi Agenda: #. Topic presents time ------------------------------------------------- 1. Agenda Bash chairs 15:20 - 15:25 2. Administrivia chairs 15:25 - 15:30 3. RFC24x45bis issues Bernard 15:30 - 16:15 4. RFC2446bis issues Cyrus 16:15 - 16:45 5. RFC2447bis issues Alexey 16:40 - 17:10 6. AoB chairs 17:10 - 17:20 Documents: - RFC2445bis: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-05 - RFC2446bis: http://tools.ietf.org/html/draft-ietf-calsify-2446bis-03 - RFC2447bis: http://tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-03 Resources: - Calsify WG Issue Tracker: http://www.ofcourseimright.com/cgi-bin/roundup/calsify/ - Calsify WG Status Pages (Jabber logs, etc.) http://tools.ietf.org/wg/calsify/ Minutes: ======== 1. Agenda Bash -------------- No changes. 2. Administrivia (Eliot Lear) ----------------------------- (Slides: ) Eliot Lear: RFC2445bis is nearing completion. WGLC will be in a few weeks time. Special thanks to Bernard who has been working really hard on the document. New draft version will be issued only after all issues are closed. Chairs working with Eric Burger to get someone from the Applications Area Review Team to make a review of the document. Also working with IANA to get them to do an early review. Current mailstones are out-of-date; will change them to reflect current schedule. Question: Will all of the documents progress together through the process. Eliot: Yes, they will all be issued IETF LCs together. Documents should be reviewed together as there are quite many interdependencies. 3. RFC2445bis issues (Eliot Lear) --------------------------------- (Slides: ) Eliot reviews the current status of open issues in the tracker: No text: 10, 11, 71, 73 Discuss: 23, 67, {8, 68, 69, 70}*, 78, 79 (* DST discontinuities Out of these, issues 23, 73 have since been closed (but not marked as such in tracker yet). Issue 71: leap seconds Next, discussion on the discontinuity issues. First, discussion ensues about leap seconds. ***Consensus on issue 71: Ignore leap seconds altogether, add ISO8086 style text, which assumes that leap seconds exist, but nominal duration knows nothing about them. Issue 67: DURATION property in VFREEBUSY Three options: 1) Remove, 2) Change in iTIP, 3) Do nothing ***Consensus on issue 67: do nothing in RFC2445bis for now; maybe change in iTIP Issues 8, 68, 69, 70: DST discontinuities Jonathan Lennox goes through the problems, and proposed solutions. See: the taxonomy for possible options. ***Consensus on the DST discontinuity issues: for repeated tiomes, go with R1; for skipped times, go with S2 (with the case of DTEND ending up before DTSTART being clearly *un*defined) Issue 79: TZ component; DTSTART always an onset date-time of an observance? Bernard presents proposed solution. Cyrus: still on the fence about RDATE < DTSTART; doesn't think it was completely closed ***Consensus on issue 79: No objection to proposed changes Issue not in tracker (but related to issue 80): Security considerations Eliot: current section is needs more work. Curys: iTIP a much bigger problem in terms of security No consensus, but text will be proposed on the list. Issue not in tracker: internationalization? Bernard: should the draft have an i18n section? Eliot: good point, any volunteers? Patrik Fältström (got) volunteered to work on it. Pete Resnick to help out. 4. RFC2446bis issues (Cyrus Daboo, remotely) -------------------------------------------- Eliot: two known issues; IANA considerations and description of SEQUENCE processing. No slides; Cyrus presented remotely (with Ted Hardie translating from VoIP to room mic). Issue iTIP#1: DURATION in VFREEBUSY (see Issue 67) Cyrus: This is allowed in RFC2445 but not defined in 2446. Useful to have, but is it currently in use anywhere? Issue iTIP#2: Which methods to keep? PUBLISH: keep REQUEST, REPLY: keep ADD, CANCEL: keep both but clarify behavior? Bernard: this is the most complicated feature of iTIP. Eliot: since CANCEL is deployed, may be too late to remove. REFRESH: keep COUNTER, DECLINECOUNTER: remove? Bernard: some implementors have indicated they are using those Cyrus: issue with both of these is in recurring events Issues left open; issues will be opened in the tracker for these. 5. RFC2447bis issues (Alexey Melnikov) --------------------------------- Eliot: reviews current planned timetable Alexey: concerned about available cycles if lots of issues surface on iMIP Cyrus: doesn't think iMIP will be that much work 6. All Other Business --------------------- There will be a conference call scheduled in the next 2 weeks; then resuming jabber sessions on a weekly basis. Oh, and we may not need to meet in Chicago if things move as planned! ;-) Adjourned.