Calsify Working Group Minutes for July 12, 2006 Agenda: - Agenda Bashing - Status Update - RFC2445bis - RFC2446bis - RFC2447bis Status Update Aki Niemi: We've updated our goals and milestones to more accurately reflect what we think we can accomplish. We are seeking completion of our work in 2007. Bernard Desruisseaux next presented on open issues for the ICALENDAR specification (RFC2445-bis). version -01 is current. He covered eight issues: 1 need to clarify number of recurrence instances generated by multiple RRULE properties. An example was given. AI: Clarifying text will be added. 2 Is the first recurrence instance, defined by DTSTART, always excluded by RRULE? AI: Bernard to take to email 3 BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is date? Corner case. AI: Consensus to go with the proposal of "MUST NOT generate such stuff and MUST ignore any VEVENTs containing this. 4 4.3.10 on UNTIL rule. Should clarify whether UNTIL can use a DATE value type. AI: Room showing agreement that the draft should state that the UNTIL value type MUST match DTSTART value type. Another issue with whether UNTIL DATE-TIME should be allowed to float or not (currently UTC a MUST). Might still be a problem if DTSTART is a local time; however, JeffMc points out later that DTSTART is not allowed to float currently, so should not be an issue. 5 4.8.5.4 rrule: should clarify that it's not whether DTEND or DURATION were used in an object. What matters is the duration fo the first occurrence instance. Cyrus points out that the core problem here is really when an instance in the recurrence set coincides with a DST shift. Proposes that the draft should be left as-is, and a note added that implementations should inform the user if a DST shift will occur, and ask whether duration or end-time is important. Room seemed to agree on the approach. AI: Cyrus to propose text towards this proposal 6 In 4.8.5.4 Is RDATE required even when the recurrence instance is redefined in a separate component. AI: Agree that this can be relaxed. 7 Is DTSTART required in VTODO and VJOURNAL components when the RRULE or EXRULE properties are defined in those components? Cyrus floated another idea that in the case of VTODO, perhaps the recurrence could use the DUE property. Bernard suggested that perhaps in the absence of DTSTART, it could default to DUE. Lisa pointed out that this needs more discussion beyond the room, because different apps behave differently. In the end, some agreement that it's enough to clarify that for recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even if it's otherwise optional. AI: Go forward with above clarification 8 Long discussion about CAL-ADDRESS and whether we should restrict URI schemes. This links with a later discussion regarding a new URI scheme that we deferred. AI: The URI vAlue Definition (3.3.13) needsa better reference for URIs. Next came Cyrus and RFC2446bis Big difference between this version and last is fixes to component/property tables. Problems with itip mostly come from recurence so more changes coming related to that. There is a conflict between 2445 and 2446 regarding whether multiple recurrence-ids can be sent in a cancel. The proposal was to remove option (b) text in that section and there seems to be agreement. Then came a long discussion about how to extend COMMENT properties to indicate who added a comment, or to add an ATTENDEE property. There is interest but not as of yet any text. Next, should implementations discard VALARMs sent via iTIP? Most discard. We had a use case that counters this, where the Calsify authors failed to show for a meeting because there was no alarm, so Eliot resent an invitation *with* a VALARM. No consensus for a change here ;-) Next, there is no version number for iTIP. There was some discussion as to when the version number would be checked. Only if a VERB is changed or if some new mandatory VERB were added. No conclusion here. There next was a large discussion about forwarding of invites and security implications. The chairs will arrange with authors a followup discussion. Some text is clearly needed in security considerations. Alex presented RFC2447bis. There is an issue about mutlipart-mixed. Which part to pick if there are different versions. Conversation mutated around multipart/alternative. No decision here. URI Scheme Discussion led by Cyrus The ADs are both concerned that this is a very blunt instrument. Reachability is a factor in the discussion. There is broad impact also with other SDOs such as W3C. One goal is discovery. Another is s2s communication. No AIs from this discussion. No concrete proposal as of yet. No movement until we have one, according to the chairs. Meeting adjourned. Kudos to RL "Bob" Morgan for taking minutes/scribing.