IETF69 ====== Calsify Working Group minutes for July 26, 2007 ================================================ Chairs: Eliot Lear Aki Niemi Agenda: #. Topic presents time ------------------------------------------------- 1. Agenda Bashing 1 minute 2. Administrativia Chairs 3 minutes 3. RFC2445bis Status Chairs 5 minutes 4. RFC2446bis Discussion Cyrus the rest Documents: - RFC2445bis: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-07 - 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: Focus is now on RFC2446bis and RFC2447bis. People should post issues for either. RFC2445bis is in WG last call until August 10; the extended period is because of the IETF meeting overlap. Remember there have been over 80 edits already, so people should keep that in mind. Goal is to get the document to be "good enough" as opposed to "perfet". (Eliot as not-chair) One issue that may need to be addressed is what type of URIs should be allowed as calendar user address in RF2445bis. At a minimum, should have a registry of URIs that are allowed and with information on what to do with a particular URI scheme. Lisa Dusseault: If there are more than 20 things, then a registry makes sense. But if there are much less, then revising the specification may actually be less work. Bernard Desruisseaux to propose text. 3. iTIP issues (Cyrus Daboo) ---------------------------- (Slides: ) Cyrus: First a bit about the goals for the rfc2446bis work. Same as with rfc2445bis: simplify, fix bugs, clarify. As iTIP is used much less in the field, there's some more leeway in making changes. o Issues - Recurrence As RANGE was removed from RFC2445bis, it needs to be removed from iTIP. To remove a range of instances from a recurring set, however, RANGE can't be used. The only way is to truncate the current recurrence set and then create a new set with the modifications. Perhaps use RELATED-TO to relate these together? Bernard Desruisseaux: As the original set is broken, what happens with the UID? Curys: The truncated portion would keep the old UID; the modified part would get a new UID. Allows avoiding a CANCEL. Discussion about adding semantics to UID, new methods etc. Eliot: There was four different proposals to fixing this problem. Propose to take it on the list, with one proposal per person and then try to find the best out of those and go with it. o Next issue - SEQUENCE Cyrus: when should sequence change? Used for synchronization as well as to indicate a change in the event. DTSTAMP is already used for the first, could also be used for the second. Proposal is to deprecate SEQUENCE (in RFC2445bis). Discussion about indicating significant change, and who gets to decide significance of a change, vs. requesting reconfirming attendance. Group decided to take a straw-man poll: Should SEQUENCE go away? A few more were for deprecating SEQUENCE than against it. Cyrus: If we keep SEQUENCE, there's a lot of clarifications to do. o Next issue - COUNTER Cyrus: COUNTER/DECLINE-COUNTER is rarely used; can achieve the same by declining a REQUEST, then sending an alternative suggestion in a comment. Eliot (not as chair): Changing from "structured text" to "unstructured text" is not a good thing. Lisa: COUNTER can be perceived as impolite. Cyrus: There has also been a suggestion to do "fuzzy" scheduling, i.e., rather than the organizer setting a specific time, it would ask for a meeting like "any afternoon next week". Discussion will be taken to the list. o Next issue - ADD/CANCEL Cyrus: Can be emulated by sending a new REQUEST (related to RANGE). Proposal is to keep these. Cyrus: Texts for CANCEL as well as ADD are misleading, need to clarify. Should also fully explain what a calendar user agent does when it receives an ADD or a CANCEL. o Next issue - VFREEBUSY Cyrus: currently says that should always send at least one VFREEBUSY. Proposal is to fix to say can also send zero, i.e., table should say 0+. Also clarify that FBTYPE is never FREE. Also other smaller issues. Eliot: seems the list of issues are not many but are all important and need eyeballs. In August, these should get on the list and in the tracker, and in September we should get the discussion going, especially with the CalConnect folks, and have the issues settled and the document in WG LC in October. This way we might not need to meet in Vancouver. Thoughts? Cyrus said that the CalConnect roundtable might arrange break-out sessions for these issues. (One of the co-chairs will make an effort to join, CalConnect starts on the week of Sep 17th.) People indicated that the schedule is tight, but sounds ok. Bernard also has some issues that he's intending to post. Will discuss some of them now. o Additional issue - versioning in iTIP There is a VERSION number in iCalendar, but not in iTIP. The only way is to detemine based on the iTIP method. Discussion about this ensued. Eliot: Bernard needs to send a proposal. If no proposed text, issue will go away. o PARTSTAT cannot be reset Bernard: participant can't revert PARTSTAT back to original state of "I don't know". Eliot: How about just using Tentative? Cyrus: It says "tentatively accepted"; don't have a way to say, "I just don't know" Eliot: Send proposal o For METHOD PUBLISH, there is a MUST NOT send attendees Bernard: Seems wrong. Why not? Cyrus: There's no way to forward an event with attendees, because then it's not a REQUEST, it's a PUBLISH since you're not expecting a response. o COMMENT property Bernard: Currently only possible to be specified once. Should allow more than one. Eliot: Please send a proposal. 4. Any other business --------------------- Cyrus: About WG future: should the WG shut down or perhaps take on additional work in extensions to iCalendar? Eliot: This came up recently, and is about extensions like the VVENUE extension Lisa sent out to the chairs a while ago. Eliot: First, seems these extensions need not necessarily have a WG. Seconly, it would be a good message to the industry if the WG was to close successfully. Lisa (as AD): Review teams can't determine consensus. VVENUE might be a generic enough spec to warrant wider review than a review team. Cyrus: Should not push the reviews of these extensions away from the CALSIFY WG. It should be OK for people to discuss the work in parallel to chartered work. Eliot: Ultimately the chairs will be responsible not to let VVENUE drop on the floor. Adjourned.