[09:55:43] --- eliot.lear has joined
[10:02:35] --- fabio.silva has joined
[10:02:41] <eliot.lear> hello fabio
[10:02:44] <eliot.lear> waiting for others
[10:03:03] <fabio.silva> hello, eliot!
[10:05:09] --- cyrus_daboo has joined
[10:05:17] <eliot.lear> howdy cyrus!
[10:05:26] <cyrus_daboo> Hi
[10:05:32] <eliot.lear> waiting for more
[10:05:52] <cyrus_daboo> I just pinged Bernard
[10:05:56] <eliot.lear> thanks
[10:06:08] --- bdesruisseaux has joined
[10:06:24] <eliot.lear> hi bernard.. we'll start in a few moments
[10:07:30] <bdesruisseaux> hi
[10:07:49] <eliot.lear> ok, let's go ahead and start.
[10:08:06] <eliot.lear> everyone saw the email i sent last week
[10:08:12] <eliot.lear> on 5/24/07
[10:08:26] <eliot.lear> in that email i asked for text for issues that had none. we had one taker
[10:08:30] <eliot.lear> issue #11
[10:08:36] <eliot.lear> we'll discuss that text as well as
[10:08:45] <eliot.lear> issues 81 and 82
[10:08:52] <eliot.lear> this would be agenda bashing
[10:09:01] <eliot.lear> any objections to this?
[10:09:20] <eliot.lear> ok
[10:09:26] <cyrus_daboo> OK
[10:09:39] <bdesruisseaux> ok
[10:09:43] <eliot.lear> issue 11 text proposal came from nigel swinson
[10:10:03] <eliot.lear> have you had a chance to review?
[10:10:15] <bdesruisseaux> I have not.
[10:10:22] --- aki has joined
[10:10:28] <eliot.lear> ok, now is as good a time as any. hi aki!
[10:10:40] <aki> Hi all, sorry I'm late!
[10:10:43] <eliot.lear> should i paste the text in or do you have it?
[10:10:51] <eliot.lear> (issue 11, nigel swenson proposal)
[10:10:53] <cyrus_daboo> I tghink Nigel is proposing changing the way rules work now, so some bits of it I did not like, but I did not get a chance to do a full review.
[10:11:13] <eliot.lear> i think some of his text does that
[10:11:18] <eliot.lear> some is clarifying in nature
[10:11:49] --- jonlennox has joined
[10:11:59] <eliot.lear> personally i think his second comment (adding "this rule is not valid for WEEKLY or MONTHLY") is not particularly useful
[10:12:13] <jonlennox> Hello!
[10:12:19] <eliot.lear> hi jon!
[10:12:56] <eliot.lear> taking comments about nigel swinson's contribution
[10:13:55] <eliot.lear> ok, if nobody has comments, i'd like to ask that people respond on list
[10:14:04] <eliot.lear> the issue remains open for now
[10:14:23] <eliot.lear> Issue 81
[10:15:23] <eliot.lear> jon, i think this one is yours
[10:15:38] <eliot.lear> your specific proposal is the text from Eric's old revision?
[10:15:38] <jonlennox> Yes
[10:16:08] <eliot.lear> that text is as follows:
[10:16:10] <eliot.lear> BYSETPOS operates on a set of events in one interval of the recurrence rule. For a WEEKLY rule, the interval is one week, for a MONTHLY rule, one month, and for a YEARLY rule, one year.
[10:16:24] <jonlennox> Possibly with some additional clarification that the start of the set is the recurrence of the start time before the expanding rules applied
[10:16:55] <eliot.lear> can you propose a very specific textual amendment to that to the list, then?
[10:17:03] <cyrus_daboo> I think the Busboom text is correct and helps clarify things a bit more, so something like that would be god to include.
[10:17:26] <jonlennox> Well, there the problem is that this breaks the "DTSTART is a set member" invariant.
[10:17:47] <jonlennox> I'm not sure that's avoidable.
[10:17:59] <eliot.lear> in that case, shall we leave the text as is?
[10:18:10] <eliot.lear> (in other words... as proposed)
[10:18:15] <eliot.lear> (by you)
[10:18:20] <eliot.lear> ?
[10:18:54] <jonlennox> No, I think the DTSTART thing is a problem either way, it just leaves it un-called-out.
[10:19:33] <jonlennox> Sorry, that was terribly unclear. Let me re-word.
[10:19:41] <eliot.lear> ok, i am trying to determine whether i need new text from you or whether you think the text you've already proposed is good
[10:19:48] <eliot.lear> for *this* issue
[10:20:05] <eliot.lear> i understand that the DTSTART thing is a hairball
[10:20:10] <jonlennox> Okay
[10:20:49] <eliot.lear> so... does Eric's text satisfy you or do you want to amend it?
[10:21:03] <jonlennox> Eric's text is a good starting point. I think adding additional wording to it to describe where the set starts would be useful, but I'm not sure how to word it.
[10:21:25] <eliot.lear> ok. barring additional proposals to reword, I propose that we run with it.
[10:21:39] <jonlennox> Yes, I think it's good enough.
[10:22:08] <eliot.lear> Issue 82, please.
[10:22:20] <bdesruisseaux> Hold on...
[10:22:30] <eliot.lear> ok...
[10:22:31] <bdesruisseaux> So I need to add 3 lines of text?
[10:22:48] <bdesruisseaux> Eric Busboom's 2445 revision draft at the time defined this by saying BYSETPOS operates on a set of events in one interval of the recurrence rule. For a WEEKLY rule, the interval is one week, for a MONTHLY rule, one month, and for a YEARLY rule, one year.
[10:23:17] <eliot.lear> yes
[10:24:41] <eliot.lear> I think this is specifically for 3.3.10
[10:24:54] <eliot.lear> (bottom of page 40?)
[10:25:33] <eliot.lear> so... Issue 82?
[10:25:41] <jonlennox> I think 82 might be the same as 11, or at least it's covered by Nigel's proposal for 11 on the list.
[10:25:45] <bdesruisseaux> Ok. I will insert this text write after the 1st sentence that talk about BYSETPOS, that is, right after: The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of events specified by the rule.
[10:26:04] <eliot.lear> ack
[10:27:25] <eliot.lear> is there anything wrong with jonathon's proposed text?
[10:28:17] <jonlennox> Are we still talking about 81?
[10:28:22] <eliot.lear> Issue 82
[10:28:45] <eliot.lear> Your text was accepted for Issue 81 (with mailing list confirmation, of course)
[10:28:54] <jonlennox> Did I ahve text for 82?
[10:29:09] <eliot.lear> i think you simplified the description by a little
[10:29:14] <eliot.lear> or at least it doesn't match what is there
[10:29:29] <jonlennox> I thought I just quoted out of somewhere
[10:29:35] <jonlennox> It might have been a different revision
[10:29:39] <eliot.lear> ok, that could be
[10:29:55] <eliot.lear> so you do not have text. in fact the text in the doc is somewhat more explanatory
[10:30:01] <jonlennox> Yes
[10:30:37] <eliot.lear> so what is your proposal for this issue?
[10:30:42] <eliot.lear> (is it really an issue?)
[10:31:09] <eliot.lear> btw, i view timezones as requiring special handling. is that how others handle them?
[10:31:51] <jonlennox> I think this issue is handled by the whole discussion we had ... two weeks ago? When you weren't here.
[10:32:18] <jonlennox> How to handle BYDAY numbers in rules with FREQ=YEARLY BYMONTH=...
[10:32:55] <eliot.lear> (std by)
[10:34:05] <eliot.lear> ok. so we have a proposal from bernard but i don't see that it was taken to the list
[10:34:40] <bdesruisseaux> humm?
[10:34:56] <eliot.lear> yes, but I think that needs to happen on the list next.
[10:35:09] <eliot.lear> bernard, your proposal was as follows form the log:
[10:35:39] <eliot.lear> For the case of BYDAY, I was wondering if we should simply change: If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY "RRULE".
[10:35:56] <jonlennox> (brb, getting coffee)
[10:35:58] <eliot.lear> and just add ", with some special case behavior as described in the notes with the recurrence table shown in section NN"
[10:36:06] <cyrus_daboo> The table to #11 is supposed to cover all this.
[10:36:12] <eliot.lear> right
[10:36:15] <bdesruisseaux> right
[10:36:29] <eliot.lear> so this issue is a dup, right?
[10:36:32] <eliot.lear> (82, that is)
[10:36:35] <bdesruisseaux> but we need consensus on the table!
[10:36:42] <eliot.lear> yep.
[10:37:46] <eliot.lear> ok, so we need for people this week to respond to nigel swinson's comments.
[10:38:15] <eliot.lear> I think that is it for now as far as 2445bis is concerned.
[10:38:18] <bdesruisseaux> 82 looks like a dup of 12 which was marked as a dup of 11...
[10:38:25] <eliot.lear> ok
[10:39:12] <eliot.lear> moving on briefly to rfc2446bis
[10:40:16] <eliot.lear> fabio has posted a draft and pointed people to it. it is too early to comment on it, but question for fabio: is this meant to be merged with rfc2446bis?
[10:41:20] <eliot.lear> hello fabio?
[10:41:32] <cyrus_daboo> No - these are extensions - they should not affect 2446bis.
[10:41:53] <fabio.silva> I don't think so, but maybe discussion on it can bring some issues about iTIP
[10:42:09] <eliot.lear> ok. to be read and discussed at a later time.
[10:42:10] <eliot.lear> cyrus,m
[10:42:37] <eliot.lear> cyrus, i've opened an umbrella issue for you for ADD and CANCEL as we discussed some time ago. also we have a session at IETF Chicago where the focus will be 2446bis
[10:43:19] <eliot.lear> as to 2445bis, barring hearing anything else the other issues currently listed will close. the chairs need to chat and then we need to start WGLC.
[10:43:32] <eliot.lear> are there any objections from this group to that?
[10:44:02] <eliot.lear> let me put that another way
[10:44:03] <cyrus_daboo> FYI I am out at Apple next week and the week after. My bedtime reading will be iTIP - i.e. a thorough review with issues being determined. Plus I will start work on the organizational revisions to the document.
[10:44:13] <eliot.lear> cool
[10:44:14] <cyrus_daboo> i.e. full steam ahead on iTIP...
[10:44:28] <eliot.lear> so.. to be clear: does everyone on this call agree that the doc is ready for WGLC?
[10:44:38] <jonlennox> Do I still owe some text on some issues?
[10:44:51] <aki> I think for 2445bis, the i18n and security considerations need some fine-tuning still.
[10:44:55] <jonlennox> I think I was on the hook for the DST and the leap-seconds bits
[10:45:03] <cyrus_daboo> We still need to close on #11 as the addition of that table is a big and important piece...
[10:45:06] <eliot.lear> i think we decided to ignore leap seconds
[10:45:33] <cyrus_daboo> On i18n - all that needs to be said is "we are using utf-8 and that solves all issues".
[10:45:34] <eliot.lear> so we have two issues: i18n and Issue 11. Right?
[10:45:43] <jonlennox> I thought we decided that the spec should say that implementors should ignore leap seconds, which is not the same thing as the spec ignoring leap seconds
[10:45:45] <eliot.lear> I18N was Issue 1
[10:45:55] <cyrus_daboo> That is what we determined in a meeting after the WG session in Prague.
[10:46:01] <eliot.lear> the spec already does not ignore leap seconds
[10:46:06] <bdesruisseaux> Aki is right
[10:46:08] <eliot.lear> (at leat not entirely)
[10:46:15] <jonlennox> I mean for event durations
[10:46:54] <eliot.lear> so you are saying that we should explicitly state that implementations should ignore leap seconds?
[10:46:59] <jonlennox> Yes
[10:47:04] <eliot.lear> i think that jives with what we had agreed
[10:47:16] <aki> cyrus: yup, and for security considerations something like "this is just the data format, and the real considerations are in iTIP, et al."
[10:47:22] <jonlennox> The problem is I'm not sure where in the spec it should go
[10:47:37] <eliot.lear> right, and that is bernard's problem as well.
[10:47:50] <eliot.lear> It could go into the intro
[10:48:01] <eliot.lear> as a note
[10:48:25] <aki> I'll take an action to propose some text for the security considerations.
[10:48:30] <eliot.lear> ok
[10:48:39] <eliot.lear> so, now we have three actions that we need to close this document:
[10:48:44] <eliot.lear> 1. security considerations cleanup
[10:48:52] <eliot.lear> 2. leap second sentence
[10:48:53] <aki> I know the presence data format has some text we can use as template.
[10:49:02] <eliot.lear> 3. issue 11 table discussion
[10:49:04] <eliot.lear> is that correct?
[10:49:15] <jonlennox> The resolution of the DST discussions
[10:49:18] <aki> And that one paragraph for the i18n ;)
[10:49:20] <bdesruisseaux> Update introduction section!
[10:49:24] <jonlennox> Unless Bernard put that in
[10:49:36] <bdesruisseaux> I would need text
[10:49:50] <eliot.lear> we need agreed upon text.
[10:50:40] <eliot.lear> this is issue 70? here again we have text but don't know where to put it
[10:50:49] <eliot.lear> perhaps this also gets into the intro?
[10:50:50] <bdesruisseaux> Eliot we are also missing the templates to register new values in each registry
[10:51:16] <eliot.lear> ok, i will take that one.
[10:51:52] <bdesruisseaux> We also never closed the issue about whether we should have a registry for the CLASS property
[10:52:17] <eliot.lear> hang on a sec.
[10:52:22] <eliot.lear> i think we did. just a moment.
[10:52:59] <bdesruisseaux> My opinion was that we should have a registry, but that if you don't recognize the new value you should not default to the default value of PUBLIC, but rather fall back on PRIVATE.
[10:53:37] <eliot.lear> and the opposing view?
[10:53:41] <eliot.lear> (i'm searching)
[10:54:49] <bdesruisseaux> euh... the opposing view was... euh.. that it wasn't clear that we should accept iana-token for CLASS...
[10:54:56] <bdesruisseaux> If I remember correctly
[10:55:33] <cyrus_daboo> I agree with Bernard's position on this one.
[10:56:07] <bdesruisseaux> Simple use case.. I have two accounts on two different systems using the same vendor's software...
[10:56:18] <bdesruisseaux> I want to export from one system to import in the other system...
[10:56:38] <eliot.lear> So we need an additional table. The rule on additional tables was that we had to have a default for implementations that don't understand it. if the default is private that is fine, and the text must reflect it. other defaults would be dangerous
[10:56:44] <bdesruisseaux> This vendors support 5 levels of access classification: NORMAL, PRIVATE, CONFIDENTIAL, PUBLIC, TOP-SECRET
[10:57:01] <bdesruisseaux> iCalendar should allow me to be able to not lose this information..
[10:57:24] <bdesruisseaux> This vendor would use either X- value for NORMAL and TOP-SECRET... and perhaps register them to IANA.
[10:57:24] <eliot.lear> just a sec...
[10:58:15] <eliot.lear> So what we are saying *here* is that the default treatment when you don't understand a class is not the default for class
[10:58:18] --- alexeymelnikov has joined
[10:58:24] <eliot.lear> correcT?
[10:58:29] <eliot.lear> the default for class is public
[10:58:38] <eliot.lear> but if you don't understand what is there you should treat as private
[10:58:41] <bdesruisseaux> You are correct!
[10:58:44] <eliot.lear> that will need to be stated in the table
[10:58:53] <eliot.lear> Bernard, can you cut and paste a table?
[10:59:03] <bdesruisseaux> Actually, such statement goes in the section that describe the property.
[10:59:17] <bdesruisseaux> I have the action item to move all such statement in their respective sections.
[10:59:22] <bdesruisseaux> hold on
[10:59:28] <eliot.lear> yes, but it's worth putting it in both sections because it's peculiar to CLASS
[10:59:49] <bdesruisseaux> 9.5. Calendar User Type Values Registry Calendar user types (CUTYPEs) are used to indicate the sort of user associated with a CAL-ADDRESS. It is described in more detail in Section 3.2.3. Expert review is required for an IANA assignment. The following values are currently allowed: +--------------------+---------+------------------------+ | Calendar User Type | Status | Reference | +--------------------+---------+------------------------+ | INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 | | GROUP | Current | RFCXXXX, Section 3.2.3 | | RESOURCE | Current | RFCXXXX, Section 3.2.3 | | ROOM | Current | RFCXXXX, Section 3.2.3 | | UNKNOWN | Current | RFCXXXX, Section 3.2.3 | +--------------------+---------+------------------------+ Implementations that do not recognize a calendar user type MUST treat the CAL-ADDRESS as an INDIVIDUAL.
[11:00:35] <eliot.lear> you're concerned about the normative text at the bottom??
[11:01:07] <cyrus_daboo> Actually we also have the issue of FBTYPE vs TRANSP and STATUS and PARTSTAT. If iana-tokens are defined for TRANSP those should also indicate how FBTYPE is generated for an event with that TRANSP value. Same for STATUS
[11:01:18] <bdesruisseaux> Well, I just think it should be moved into the section that describe CUTYPE for this particular example....
[11:01:33] <eliot.lear> that's fine.
[11:01:37] <cyrus_daboo> PARTSTAT vs FBTYPE was soemthing Bernard and I have been discussing wrt caldav-scheduling, and that may make it into iTIP.
[11:01:45] <bdesruisseaux> Cyrus: Not sure that's iCalendar's problem.
[11:02:02] <bdesruisseaux> Cyrus: Yes, iTIP!
[11:02:35] <eliot.lear> the only issue here is to make sure that we have the correct level of review.
[11:02:53] <eliot.lear> so that new entries don't screw up iTIP
[11:03:08] <cyrus_daboo> So the derivation of FBTYPE from an event's properties is left up to iTIP to define? But it may affect how we do the IANA templates, because some templates may need to include that interaction.
[11:03:32] <eliot.lear> cyrus, let me run a few templates by you to see what you think.
[11:03:33] <bdesruisseaux> <Folks, I have to run to a meeting>
[11:03:43] <eliot.lear> hopefully we can sort that quickly.
[11:03:48] <eliot.lear> ok, same time next week.
[11:03:56] <eliot.lear> and thanks all
[11:03:59] <cyrus_daboo> Bottom line - iTIP will deal with this but we may need to go back and wteak some things in 2445bis (which we have anticipated needing to do anyhow).
[11:04:09] <eliot.lear> ok
[11:04:12] <eliot.lear> bye for now
[11:04:20] --- eliot.lear has left
[11:04:22] <aki> Thanks all. Bye.
[11:04:26] --- aki has left
[11:04:54] --- cyrus_daboo has left
[11:05:05] --- jonlennox has left
[11:05:35] --- fabio.silva has left
[13:09:39] --- bdesruisseaux has left
[20:09:19] --- alexeymelnikov has left