[12:19:06] --- Barry Leiba has joined [12:19:44] --- aki has joined [12:19:57] Starting in 3 minutes! [12:21:26] --- cyrus has joined [12:27:29] --- bdesruisseaux has joined [12:28:07] Eliot just welcomed Bernard in "voice-land". B, are you on the voice channel? [12:28:24] I'm listening now! [12:28:30] Hello everyone! [12:28:31] Bon. [12:28:38] Hi Bernard! [12:28:56] --- resnick has joined [12:29:23] * resnick now jabbering. [12:29:48] Admin things: Finishing up 2446bis. Moving on to Alexey's doc. [12:30:17] Cyrus: vCard is doing some things that play into what we're doing. [12:30:44] CD: XML schemas should be compatible. [12:31:00] Eliot Lear: Should huddle with AD about whether we will do XML. [12:31:26] ED: Proto writeup will be done by Eliot for 2446bis. [12:31:41] ED: Hope that 2447bis will be handled on the list only. [12:32:11] Pause while getting Cyrus's slides... [12:32:37] Are the slides available online? [12:32:54] Yes, on the meeting materials site. [12:33:12] iTIP 2446bis: [12:33:28] Slides: http://www.ietf.org/proceedings/08mar/slides/calsify-1.pdf [12:33:31] CD: No new issues in the issues tracker. [12:33:39] Thanks Aki! [12:33:39] -04 is now out [12:34:25] Sorry, that's -05 [12:35:21] Backing up, wrong set of slides are up. [12:35:46] OK, new slides will be put up in a moment. [12:35:55] Changes in 05 [12:36:02] Minor text changes [12:36:06] remove EXRULE [12:36:17] remove PROCEDURE alarms [12:36:20] Fixed examples. [12:36:29] Issue 85 still outstanding [12:36:32] RANGE parameter [12:36:53] Re-instated in 2445 bis (THISANDFUTURE only) with some limitations. [12:37:02] Changes needed in 2446bis: [12:37:02] The correct set of slides should now be at the materials site [12:37:13] Remove references to THISANDPRIOR [12:37:21] Explain how to delete prior instances [12:37:41] Explain when it is necessary to "reset" an event by truncating and sending out a new one. [12:38:36] Issue 86 [12:38:38] I take that back. The slides on the materials site are still the wrong set. Sorry! [12:38:44] SEQUENCE number [12:38:55] Proposed additional text in 2.1.4... [12:39:07] * resnick isn't typing all of that... [12:43:16] It is not clear what "brought to the attention of a calendar user" means. Do you want the user agent to simply bring the change to the attention of the user, or rather suggest to the user to re-consider his participation status? [12:43:40] * resnick will send text to clarify to say that SEQUENCE is not necessarily determinative (either way) of whether to bother the user or not. [12:44:49] PR: Semantics of the thing need to be explained. [12:45:15] EL: Do we need/want normative text here. [12:45:30] Lisa Dusseault: I'm OK with the current text. [12:45:49] (I missed who was pushing back on this text that CD mentioned) [12:46:06] Should the situtation where the Organizer bump the SEQUENCE and leave my PARTSTAT to ACCEPTED be treated differently from the case where the Organizer bumps the SEQUENCE *and* also reset my PARTSTAT to NEEDS-ACTION? [12:46:14] resnick: I believe it was Tim Hare on the list [12:46:41] CD: Also wants to clarify whether changing a SEQUENCE number on a set changes the SEQUENCE number on the members. [12:47:58] CD (in reply to BD): Yes, but you have to take into account other items too. [12:48:24] The idea here would be that if the Organizer reset my PARTSTAT to NEEDS-ACTION then [12:48:26] CD (wrt SEQUENCE): Need to think this out. [12:48:33] --- eliot.lear has joined [12:48:38] that would be a very clear indication that I should re-consider, [12:48:48] but I agree that it shouldn't be the only condition [12:49:42] Bernard, PARTSTAT indicates that you need to reply to the Organizer, but in some cases you may not even bother the user with that. It's *all* a UI question. [12:49:47] Issue 90: [12:49:59] Better guidance for ADD/CANCEL [12:50:15] Waiting on RANGE= resolution [12:50:24] Issue 95: [12:50:33] Pete: Actually, RSVP is the parameter that indicates that the Organizer wants a reply from you (or maybe we are not talking about the same thing) [12:50:49] REQUEST-STATUS multiple times with different top level codes? [12:50:58] iTIP really needs to clarify all this... SEQUENCE / PARTSTAT / RSVP [12:51:02] Bernard, Of course. My mistake. [12:51:43] Proposal for 95: restrict REQUEST-STATUS to the same top-level code in a single iTIP message. [12:51:59] Text on the mailing list. [12:52:26] http://lists.osafoundation.org/pipermail/ietf-calsify/2008-March/001939.html [12:52:27] Bernard, if the Organizer changes PARTSTAT (How rude!), then you're going to have to talk to the user. [12:53:07] In my opinion, it is completly acceptable to change my PARSTAT to NEEDS-ACTION. [12:53:17] ... and only to NEEDS-ACTION... [12:53:43] I agree. It's actually polite: "I changed the details, and don't want to assume you're still OK with it" :) [12:54:19] The next time I invite you two to meetings, I'm going to constantly reset your PARTSTAT just to annoy you. :-) [12:54:31] More to it... If the Organizer doesn't change my PARTSTAT, then other attendeees won't know whether I have ACCEPTED this new version for real or not... very bad [12:55:17] (Sorry, losing the thread of this discussion....) [12:55:34] resnick: there are also other, easier ways to annoy me. ;) [12:56:13] aki: I'm sure your kids know them all! [12:57:51] * resnick asks if there is resolution [12:58:15] CD: Existing text allows other codes. We could stick with status quo. [12:58:43] EL: Make clear that unrecognized codes should not blow things up, but new codes ought to be documented. [12:58:56] EL (qua chair): Everyone OK with that? [12:59:04] (*Silence*) [12:59:07] Issue 67: [12:59:16] DURATION and VFREEBUSY requests? [12:59:27] Need consensus on: [12:59:37] a) Remove statement from iCalendar [13:00:08] b) Change iTIP to allow the DURATION property in a VFREEBUSY request [13:00:16] or c) Status quo [13:01:26] Looks like we should setup a registry for REQUEST-STATUS values... rfc2445bis didn't take care of that... Should rfc2446bis take care of that? [13:01:32] Barry Leiba: I thought we chose a), and c) is a non-starter. [13:01:50] :-) [13:01:55] CD: I prefer a) [13:02:14] I don't really care... [13:02:29] Status quo doesn't really hurt though [13:03:09] CD: If you have a strict iTIP engine, it will generate an error. That hurts. [13:03:28] BL: Even if it was not an operational problem, it's inconsistent. [13:03:34] That being said... I don't like the fact that VFREEBUSY would allow DURATION and DTEND to be used at the same time... unlike VTODO and VEVENT... [13:04:12] If we want this feature later one, perhaps we could introduce another property for this purpose... So we could go with (a) for now... [13:04:54] bdesruisseaux: we might need to look at defining IANA considerations for REQUEST-STATUS, including policy for registering new codes. [13:05:03] Chair: a) seems OK with folks. [13:05:16] Removing text is easy! [13:06:32] EL: Only reason to meet in Dublin is for big bad Last Call/IESG feedback. [13:07:02] EL: 2447bis update (Alexey) is next. [13:07:07] Any other business? [13:07:07] --- Chris Newman has joined [13:08:08] Point of interest: Spam messages with iCalendar objects. [13:08:15] I've got 2 calendar spam lately, 1 standard based one, another non-standard based [13:10:38] Discussion of mechanisms of this thing being useful for spammers..... [13:11:28] 1 from gmail.com (iMIP), the other was from yahoo.fr [13:12:38] Neither of them were legitimate at all! [13:12:51] CD: Does this cause any real security concerns that would require text in iMIP? [13:15:10] BL: DOS attack at least. [13:15:49] *Barry nods* [13:15:59] --- Barry Leiba has left [13:16:02] End of discussion. Meeting adjourned. [13:16:17] Bye! [13:16:28] Bye and thanks all! [13:16:33] --- aki has left [13:16:33] --- bdesruisseaux has left [13:16:37] --- resnick has left [13:17:42] --- eliot.lear has left [13:35:30] --- Chris Newman has left [14:14:04] --- cyrus has left