[10:11:17] --- fabio.silva has joined
[10:13:05] --- fabio.silva has left
[14:00:35] --- apn has joined
[14:01:37] --- bdesruisseaux has joined
[14:01:46] --- alexeymelnikov has joined
[14:02:05] <apn> Hi all, we're on.
[14:02:35] --- resnick has joined
[14:02:46] <resnick> Agenda bash
[14:03:03] <resnick> Added 2445bis
[14:03:16] <resnick> 2446bis - Cyrus
[14:03:20] <resnick> AOB
[14:03:35] <resnick> Important first issue:
[14:03:38] <resnick> Bernard:
[14:03:49] <resnick> Hummmming
[14:04:07] <resnick> Bernard officially ages
[14:04:23] <resnick> Conclusive hum of consensus had
[14:04:31] <resnick> Back to real business.
[14:04:41] --- Darryl has joined
[14:05:18] <resnick> most focus currently on 2446bis. Post those concerns (and those on 2447bis) *NOW*.
[14:05:36] <resnick> 2445bis: In WGLC (until Aug 10)
[14:05:54] <resnick> Have a bit of time.
[14:06:43] <resnick> Yes, there's been lots of editing, but please distinguish between "I don't like it, but good enough" and "show-stopper; this needs fixing"
[14:06:57] <resnick> Any open issues on 2445bis?
[14:07:04] <resnick> (*Pause*)
[14:07:46] <resnick> Eliot (not as chair): Prior to release - We haven't specified which URIs can be used in caladress in 2445.
[14:08:03] <resnick> Need to have some understanding of what to do with any allowed URI.
[14:08:15] <resnick> Need a registry with informational text for allowable URIs.
[14:08:51] <resnick> Lisa: If there are more than 20 things, then a registry is worth it. For a short list, an RFC is probably sufficient (and more efficient).
[14:09:10] <resnick> Cyrus: Does this have to be a normative requirement? Can we just have an informational doc on this?
[14:09:38] <resnick> Eliot: If you use a URI that others don't understand, won't there be interop issues?
[14:09:51] <resnick> Lisa: How about a mandatory to implement list of URIs?
[14:10:29] <resnick> Cyrus: No binding between calendar user address and iTIP. Should that be defined in iTIP, 2445, separate doc?
[14:11:23] <resnick> Eliot: If there are other than iTIP related properties, shouldn't it go into 2445?
[14:11:33] <resnick> Cyrus: Send text.
[14:11:50] <resnick> Bernard will write that text.
[14:11:53] --- cyrus_daboo has joined
[14:12:02] <resnick> Other issues?
[14:12:46] <resnick> Jonathan: I'll work with Bernard on known issues.
[14:13:28] <resnick> Anything else?
[14:13:33] <resnick> Next: Cyrus.
[14:14:22] <resnick> iTIP issues.
[14:14:44] <resnick> Goals (blah blah blah)
[14:14:58] <resnick> Cutting things out is a good thing.
[14:15:06] <resnick> Can make changes if needed.
[14:15:25] <resnick> Issues
[14:15:30] <resnick> - Recurrences
[14:16:23] <resnick> Changes: Removal of RANGE.
[14:17:17] <resnick> Need to update iTIP.
[14:17:36] <bdesruisseaux> RANGE was deprecated in rfc2445bis.
[14:18:23] <resnick> How to cancel a range: If you need to cancel "This and for the future", resend original event with a new end.
[14:19:31] <resnick> Currently if you want to remove a range, you have to do this anyway on the client end.
[14:19:51] <resnick> This just means you're sending more data, but you achieve the same effect.
[14:20:05] <resnick> Same thing for changes to all future instances.
[14:20:36] <resnick> Have to truncate current event and make a new event with the change.
[14:20:57] <resnick> Perhaps you have to use RELATED-TO to get the two events connected.
[14:22:19] <resnick> Bernard: Who gets which UID?
[14:22:50] <resnick> Cyrus: New event gets new UID. Truncated thing gets old UID.
[14:23:16] <resnick> Avoids the cancel.
[14:24:49] <resnick> Eliot: Adding an attendee seems like a bad time to blow away everyone's UID.
[14:25:37] <resnick> Cyrus: Yes, this may end up with loss of information.
[14:26:24] <resnick> Eliot: Need UID semantics now.
[14:26:54] <resnick> Cyrus: Client reaction is the real issue: Does the client react to any particular request?
[14:27:57] <resnick> Pete: Why are we replacing one complication with another?
[14:27:59] <apn> Pete: seems like if you need to add complications to solve the problem, perhaps better leave it alone
[14:28:17] <resnick> Cyrus: RANGE doesn't interoperate well.
[14:28:46] <resnick> Eliot: It might be simpler to do a new method or something else?
[14:28:57] <resnick> Bernard: Some sort of sibling thing?
[14:30:26] <resnick> Cyrus: There are going to be multiple messages. If you truncate first, then you lose the info on the original.
[14:31:07] <resnick> Eliot: Let's come up with some suggestions (one per person please) and come up with the best.
[14:31:51] <resnick> Next issue: SEQUENCE
[14:32:26] <resnick> When should SEQUENCE change?
[14:33:31] <resnick> DTSTAMP already exists, so there's no need for SEQUENCE for sync issues.
[14:33:57] <resnick> Might have to say that DTSTAMP must change for every change.
[14:34:39] <resnick> Hard for organizer to tell that any particular change is significant.
[14:34:51] <resnick> Up to the attendee to decide.
[14:35:35] <resnick> Proposal: Deprecate SEQUENCE.
[14:36:11] <resnick> (in 2445bis)
[14:37:53] <resnick> Bernard: DTSTAMP was simply the tie-breaker. SEQUENCE meant significant change.
[14:38:10] <resnick> SEQUENCE tells you when UA should notify.
[14:38:25] <resnick> Cyrus: UA could figure this out.
[14:40:21] <resnick> Eliot (not as chair): Indication from the sender is only a suggestion to the receiver.
[14:41:32] <resnick> Is there a need for a sender signal to the receiver?
[14:41:40] <apn> Eliot: still up to the CUI whether to prompt the user regardless of whether a SEQUENCE was bumped or not
[14:41:46] <apn> Pete at the mic
[14:44:23] <resnick> Pete: Is there a time that you want to bump SEQUENCE where it is not equivalent to re-RSVP?
[14:51:15] <resnick> Folks try to make the distinction between RSVP (where I really want you to tell me what your status is, even if it hasn't changed) and bumping SEQUENCE (which means you might want to re-check your status, whether or not you tell me)
[14:53:24] <resnick> Bernard: Can't we just say that it's just a suggestion?
[14:55:06] <resnick> (More discussion)
[14:55:19] <resnick> Straw poll: Sequence go away?
[14:56:15] <resnick> A few more ditch it vs. a few less keep it.
[14:57:06] <resnick> If we keep SEQUENCE, there's a lot of clarifications to do.
[14:57:20] <resnick> Next issue: COUNTER
[14:58:00] <resnick> COUNTER can be done by declining REQUEST and sending suggested alternative.
[14:58:16] <resnick> Proposal: Remove COUNTER/DECLINE-COUNTER
[14:58:53] <resnick> Eliot (not as chair): Changing from "structured text" to "unstructured text" is not a good thing.
[14:59:18] <resnick> Q to implementors: Is this used?
[15:00:35] <resnick> Lisa: COUNTER is something that could be considered "impolite". Must recognize implications.
[15:01:18] <resnick> Bernard: Is this just a free/busy access problem?
[15:03:20] <resnick> Aki (not as chair): Not used often, but seen it.
[15:04:10] <resnick> Next issue: ADD/CANCEL
[15:04:27] <resnick> Can be emulated by sending a new REQUEST
[15:04:30] <apn> Link for the issue tracker: http://www.ofcourseimright.com/cgi-bin/roundup/calsify/
[15:04:44] <resnick> Propsal: Keep them
[15:05:22] <apn> And remember to file issues under the 'rfc2446bis' topic
[15:06:22] <resnick> Bernard: They're not required.
[15:07:27] <resnick> Cyrus: In the future, we might need another extension, but that's not for now.
[15:08:49] <resnick> Next issue: CANCEL
[15:08:56] <resnick> How to cancel more than one.
[15:09:09] <resnick> There are already lots of ways.
[15:10:06] <resnick> (I missed the proposal)
[15:10:11] <resnick> Next issue: ADD
[15:10:37] <resnick> Current text is screwy. Can't use it to modify. Only to add new instances.
[15:10:45] <resnick> Proposal: simply clarify.
[15:12:57] <resnick> ADD/CANCEL: Should clarify for CANCEL, add an EXDATE. For ADD, add an RDATE.
[15:13:14] --- hippasus has joined
[15:14:19] <resnick> Eliot: Let's make that non-normative.
[15:15:37] <resnick> Clients might have reason to use one or the other.
[15:16:03] <resnick> Next issue: VFREEBUSY
[15:16:30] <resnick> Proposal: Fix the table to say that it could be 0+
[15:16:45] <resnick> Clarify FBTYPE is never FREE.
[15:17:47] <resnick> Other issues are little bits, but that's it for the big ones.
[15:18:47] <resnick> Eliot: Let's publicize these issues during August and get the CalConnect people to get comments in September.
[15:19:02] <resnick> October, move toward WGLC by the end of the month.
[15:19:25] <resnick> (People feel that's aggressive, but OK)
[15:20:25] <resnick> Bernard: Maybe give a little more time due to summer holidays.
[15:20:50] <resnick> CalConnect is Sept 17. That's the time to get people to review these issues.
[15:21:16] <resnick> Bernard (a few more issues):
[15:21:25] <resnick> - Versioning in iTIP?
[15:22:01] <resnick> Only way right now is name of the meta (Pete's not sure what that means)
[15:22:07] <resnick> No good clean solution now.
[15:22:22] <resnick> Is there anything other than a new property?
[15:23:20] <hippasus> Why not use VERSION attribute.
[15:23:42] <hippasus> Give it more syntax to represent components of protocol?
[15:23:59] <hippasus> Assume some useful defaults for components not named?
[15:24:25] <resnick> - What's the use of TENTATIVE?
[15:25:07] <resnick> (John - I think extending VERSION was one of Bernard's possible suggestions, but he's not sure)
[15:25:18] <resnick> (Someone else will have to explain why)
[15:25:20] <hippasus> It might be out of scope for bis
[15:26:11] <resnick> There is currently no MUST NOT for TENTATIVE.
[15:26:14] <hippasus> apologies for being behind on mailing list.
[15:26:43] <resnick> - For META PUBLISH, there's MUST NOT send the attendees.
[15:27:00] <resnick> Sorry, METHOD PUBLISH
[15:27:33] <resnick> Why?
[15:31:01] * resnick wonders why we use PUBLISH
[15:31:21] <hippasus> For Group calendars.
[15:31:33] <resnick> For exporting
[15:31:37] <hippasus> Yes.
[15:31:52] <resnick> But then why use any METHOD at all.
[15:32:24] <hippasus> I'm not sure I have an opinion on it. ;-)
[15:32:28] <resnick> But people are currently using PUBLISH and still including attendees.
[15:32:50] <resnick> - COMMENT property
[15:32:58] <resnick> You can only specify it once now.
[15:33:08] <resnick> Maybe you want to preserve old ones.
[15:33:33] <resnick> Perhaps I want to add a comment to a forwarded event
[15:34:23] <resnick> Eliot: Bernard, please send text to the list
[15:34:42] <resnick> Any other proposals/issues wrt 2446bis?
[15:35:35] <resnick> (Note to everyone: Use the change tracker on the tools web site to see the changes)
[15:37:01] <hippasus> (url for tools website not on calsify page at ietf.org
[15:37:21] <resnick> tools.ietf.org?
[15:37:47] <resnick> Cyrus: WG future?
[15:38:34] <resnick> Eliot: 1. We would need to recharter.
[15:38:47] <resnick> 2. We probably don't need a WG to review extensions.
[15:39:00] <resnick> An expert review team might be enough.
[15:39:14] --- bharris has joined
[15:39:16] --- bharris has left
[15:39:27] <resnick> Also: Shutting down the WG might be a good "sign of success"
[15:39:45] <hippasus> I agree.
[15:39:58] <hippasus> Consider extensions in different venue.
[15:41:06] <resnick> Lisa: A review team doesn't judge consensus, but some things are appropriate to do as individual submissions.
[15:41:09] <bdesruisseaux> hippasus: Check http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html
[15:42:04] <hippasus> btw, hippasus is jwn2@qualcomm.com
[15:42:39] <hippasus> thx for the pointer.
[15:44:23] <resnick> Sorry, missed which document we were talking about.
[15:44:49] <resnick> End of meeting.
[15:44:53] <hippasus> 2445bis.
[15:45:01] <resnick> (Thanks John)
[15:45:04] <apn> Thanks everyone. See you (maybe?) in Vancouver!
[15:45:05] <hippasus> That gets me in the neighborhood. Should be good enougn
[15:45:11] <hippasus> bye-bye!
[15:45:19] --- bdesruisseaux has left
[15:45:21] --- hippasus has left
[15:45:26] --- resnick has left
[15:46:31] --- apn has left
[15:49:51] --- alexeymelnikov has left
[15:51:13] --- cyrus_daboo has left
[16:11:37] --- alexeymelnikov has joined
[16:14:10] --- marc.blanchet.qc has joined
[16:14:24] --- marc.blanchet.qc has left
[16:19:33] --- Darryl has left: Replaced by new connection
[16:31:27] --- alexeymelnikov has left