IETF67 ====== Calsify Working Group minutes for November 6, 2006 ================================================== Agenda: ------- - Agenda Bash (chairs) - Administrativia (timeline / etc) (chairs) - draft-ietf-calsify-rfc2445bis-02.txt address any remaining issues (chairs, Bernard) - simplification of RRULEs - draft-ietf-calsify-2446bis-02.txt open issues (Cyrus) - draft-ietf-calsify-rfc2447bis-02.txt open issues (Alexey) 1. Agenda bash -------------- No changes. 2. Administrivia (Eliot Lear) ----------------------------- Good progress recently in closing out the reported issues of RFC2445bis. Having good use of weekly Jabber chat sessions. We are issuing a last call on opening new issues tomorrow, Nov 7. This means that no new issues shall be opened in the tracker after that. Link to the issue tracker: http://ofcourseimright.com/cgi-bin/roundup/calsify/ Once RFC2445bis is nearing completion, we'll focus on RFC2446bis and RFC2447bis. Extra credit to Bernard for producing two new draft versions in very fast pace prior to the IETF meeting, as well as the authors of the other two drafts for being active in the work. 2. Proposal for additional simplification of RRULEs (Cyrus Daboo) ----------------------------------------------------------------- Background: in last CalConnect meeting, feedback on issues both with using iCalendar and vCard from the Open Mobile Alliance (OMA) Data Synchronization (DS) Group. Most mobile clients have restricted screen real-estate to work with. Lisa Dusseault did research on desktop clients on what sort of editing capability regarding recurrence they offered. Neither mobile or desktop calendar clients today implement the full set of recurrence features of iCalendar. Analysis of the used UIs can give some guidance of the subset mostly in actual use. Concrete proposal: remove i) FREQ=SECONDLY/MINUTELY and ii) BYSECOND/BYMINUTE. Neither of which are really useful for interpersonal communications. Might remove HOURLY as well, but that would seem useful for instance if a person has to take their medicine every hour. Core issue is whether to do profiling or simplification, i.e., whether to remove from RFC2445bis. Dave Crocker: to get maximum amount of interop, you start with the smallest usable stuff, then add to it. Profiling on the other hand is something where you overspecify, then make a profile a subset that's actually usable for people. Cyrus: How much richer do you want the desktop experience to be from a mobile experience? Maybe they aren't different after all. Maybe the minimun is just enough. Eliot: Since this is a revision of RFC2445, this is about pulling stuff out. Dave: Need to satisfy "existence proof". Cyrus: Should we also start to restrict BY-rule combinations, using a table? Eliot: May be added complexity for clients that need to check table on legality of a combination. So need to see the table to be able to answer that. 3. RFC2445bis issues (Eliot Lear, Bernard Desruisseaux) ------------------------------------- The rest of the meeting will be spent on RFC2445bis issues. May not get through all of the outstanding issues, but will aim at a rate of a resolved issue / 5min. - Issues 13,14,24,25: RRULE simplifications Status: text is in draft already Does anybody object the simplification? None. Unless anybody objects during the week, this is accepted as is currently in the draft. - Issue 16: BY rule beyond duration (This is the February 30th issue) Status: an example has been proposed Bernard Desruisseaux: Relates to the previous issue somewhat. Also, do you ignore non-existent instances, rather than the whole rule. TJ Kniveton: Could you just add a DST=1 or DST=0 with the rest of the information? Eliot: Should really just clarify the example; if someone wants to open a more general issue with DST discontinuities, should propose text as well. Issue closed. - Issue 19: IANA considerations There is no text, but this needs to be addressed before forwarding the document. Cyrus: Need to also populate the IANA registry with initial valules. Eliot: or we simply say that RFC2445bis simply contains the base values. Bernard: A lot of registries needed: components, properties, parameters. Aki Niemi: We need to also decide on which policy to assign new values from these various registrys. For instance, first-come first-served is probably fine for some, RFC required perhaps for others. Lisa Dusseault: Would suggest alternatives to Expert Review, at least. Eliot: Need text for this. - Issue 27: DTEND/DURATION Bernard: This issue is about the corner case of when a DST change occurs. Do you then want to follow the nominal duration (DTEND), or the exact duration (DURATION). Jonathan Lennox: It may even be more complicated than that -- the DTEND might simply not exist, if it hits the DST change (e.g., 2:30 am on a DST change). Cyrus: Might be a good idea to check what implementations do now. No consensus. Need text. - Issue 28: Is RDATE required even when the recurrence instance is defined in a separate component? Bernard: Suggest to relax the requirement. Eliot: General consensus for the change, but still need text. - Issue 33: New definition of an iCalendar Stream -- a sequence of iCalendar objects Status: text proposed, no discussion. Bernard: It makes difference for a stream containing multiple component. Does each object has to have own timezone definitions, or can one object reference timezones in another? This is a change in the ABNF - Issue 34: methods with multiple objects Bernard: Can a stream contain objects with multiple methods - yes, but don't specify METHOD= in Content-type Action: Bernard/Alexey to decide on text. - Issue 36: X-name Status: no consensus Bernard: the issue is namely with the word "bilateral". Eliot: Suggestion to drop the "bilateral agreement" Issue remains open. - Issue 42: ALARM actions Status: this is open, and there's no text. Bernard: The action property is extensible, yet the VALARM component only allows certain actions. Should allow for extensions. Consensus. Closed, but need text. - Issue 43: proper form of DTSTART Status: this is open, and there's no text. Bernard: Issue is whether DTSTART can use UTC in a VTIMEZONE component. I think "no". Jonathan Lennox: Isn't UTC just one case of a timezone without DST? Ted Hardie: There is a difference between saying that something is not advisable and saying that something is invalid Eliot: Consensus to have this restriction in VTIMEZONE, but not in the other cases. - Issue 44: Non-standard properties Bernard: Problem is, x-param is not allowed to in a non standard property. Why is that? Also existing practise. Consensus to remove this restriction. - Issue 45: Bad LDAP URLs in examples All fixed in current draft. - Issue 47: Trigger relative to DATE value type Eliot: No text. Bernard: Issue is whether DATE is relative to Zulu or localtime. Cyrus to propose text. - Issue 46: ABNF Consensus not to rewrite ABNFs, but remove before * - Issue 48: Deprecate RANGE Bernard: RANGE=THISANDFUTURE doesn't seem to ever be used in the wild. Proposal to deprecate. Eliot: Concensus pretty clear; please propose text on how to do it. - Issue 51: Non-inclusive end on events with DATE Bernard: Cyrus has proposed text on this that looks good to me. Eliot: Closed, pending confirmation on the list. - Issue 52: disallow x-name in RRULEs, namely additional rules Bernard: No-one uses those. Eliot: Consensus to remove. - Issue 53: Content- lines and non-US-ASCII Consensus to just update the ABNF for NON-US-ASCII with the ABNF in UTF-8 specification. - Issue 54: Version value bump Eliot: Some years down the road, people could write implementations that could be strictly compliant with the new iCalendar. Bumping the version could enable this. Bernard: Did some tests with iCalendar implmentations, and most just ignored the version. (Discussion) Eliot: Let's take it to the list. Proceeding to the new issues, not yet in the tracker (from the mailing list). - New issue: Section 4.3.10: Order of rule parts (ABNF issue) Bernard: FREQ= is not necessarily the first one, or chane the text to say that FREQ= has to be the first? Chris: Could simply say that FREQ neds to be first. No consensus. - New issue: Section 4.6.1 Event Components: DURATION when DTSTART is DATE Bernard: Proposal to restrict so that in this case, the DURATION can't be hours. - New issue: Transparency of full-day events Bernard: If DTEND is missing and DTSTART is DATE, the event takes 1 day. How does this affect transparency? (Text elsewhere say that the event takes no time. Text inconsistent) Cyrus: Depends on what you want to happen. What is the default transparency in that case. Eliot: What do actual clients do? Need facts. - New issue: Journal component: DESCRIPTION property Bernard: Problem is vJournal ABNF doesn't allow multiple DESCRIPTION properties, but text does. Proposal is to fix it to match text. - New issue: Section 4.6.5: Time Zone Component Bernard: Not required when DTSTART is a DATE? (Issue dropped) - New issue: Section 4.1.2 Multiple Values: Language parameter Bernard: If there is a DESCRIPTION in English and in French: is one the transaltion of the other? Or are they just updating each other? Eliot: Another suggestion to use MIME to handle alternatives. - New issue: ABNF modification Bernard: Change x-param to other-param that can be either iana- or x-param (allows for IANA params everywhere) - New issue: Section 4.8.3.1 Time Zone Identifier: Scope of TZID Bernard: Uniqueness of TZIDs; should specify what is the scope. (Should be calendar object) (Skipping one moot issue) - New issue: Section 4.8.4.4 Recurrence ID: RECURRENCE-ID of an instance might change? Bernard: When the RRULE changes, the RECURRENCE-ID might also change. But how do you correlate recurrence instances if the ID changes? Cyrus: Probably the biggest issue in iTIP is handling changes to RRULE. Should be: cannot change an RRULE, can only send exceptions to RRULE. - New issue: Section 4.8.5.3 Recurrence Date/Times: RDATE