[09:53:42] --- bernard.desruisseaux has joined
[09:56:00] --- pigdog has joined
[09:56:06] <pigdog> hi bernard!
[09:58:13] --- apn has joined
[09:58:18] <pigdog> hi aki!
[09:58:23] <apn> Hi Eliot & co!
[09:58:36] <bernard.desruisseaux> Hi!
[09:58:44] <apn> Hi Bernard!
[09:58:47] <pigdog> we'll start in a few minutes - looks like the usual suspects are online
[10:00:30] <bernard.desruisseaux> Hi Apn! (who are you?)
[10:00:44] <pigdog> bernard, do you have your list of remaining issues?
[10:00:46] <pigdog> that's aki, btw
[10:00:58] <bernard.desruisseaux> Hi Aki!
[10:01:24] --- alexeymelnikov has joined
[10:01:30] <pigdog> hi alexey
[10:01:44] <alexeymelnikov> Hello everybody
[10:01:47] <bernard.desruisseaux> I'm almost done with "23 27 42 47 59 61 62 65 66" in the text.
[10:02:03] <pigdog> ok, i think we're making progress on iana considerations, but i would like to go over a few things there
[10:02:06] <bernard.desruisseaux> Last week we talked about "19 21 54 55 63 64 67 68 69 70 71 72 73 74"
[10:02:23] <alexeymelnikov> I am sorry I didn't post the list of my issues to the mailing list. I have a codefreeze this week
[10:02:34] <bernard.desruisseaux> And I wanted to talk about 3 potentials additional issues... but we only had time to talk about one of them...
[10:03:03] <pigdog> ok...
[10:03:10] <bernard.desruisseaux> Since last week I did send emails to the list... Asking the chair to add some issues to the tracker.
[10:03:31] <pigdog> right - i've been traveling, but those issues will get added because they're old
[10:03:38] <bernard.desruisseaux> Right.
[10:03:50] <pigdog> ok, i propose the following agenda:
[10:03:55] <pigdog> - IANA considerations
[10:04:00] <pigdog> - other open issues
[10:04:07] <pigdog> any objections?
[10:04:15] <bernard.desruisseaux> That's good.
[10:04:29] --- cyrus_daboo has joined
[10:04:40] <pigdog> hi cyrus
[10:04:42] <alexeymelnikov> No objections
[10:04:43] <cyrus_daboo> Hi.
[10:04:44] <alexeymelnikov> Hi
[10:05:00] <pigdog> ok, so i took a first crack at IANA considerations and then Bernard followed up with that
[10:05:02] <cyrus_daboo> agenda is fine.
[10:05:13] --- jonlennox has joined
[10:05:13] <pigdog> we are still in the editing phase
[10:05:40] <pigdog> but the key issues that i would like cover are the various registries that use iana-tokens
[10:05:51] <pigdog> jon, what's your email address?
[10:05:57] <jonlennox> lennox@cs.columbia.edu
[10:06:12] <pigdog> ok, just a sec- i'm forwarding you a note from bernard that contains a nice summary
[10:06:18] <jonlennox> Thanks
[10:06:28] <bernard.desruisseaux> Hi Jon
[10:06:53] <pigdog> sorry for the delay
[10:07:32] <pigdog> so Bernard sent a note with a list of tokens and opinions of whether each should get registered
[10:07:37] <pigdog> starting with CUTYPE
[10:07:43] <pigdog> does everyone have that message?
[10:08:10] <pigdog> let's assume yes for the moment
[10:08:13] <cyrus_daboo> Looking at it now.
[10:08:16] <alexeymelnikov> The one that Bernard sent yesterday?
[10:08:20] <pigdog> yes
[10:08:23] <cyrus_daboo> I did go over it yesterday and will comment...
[10:08:59] <pigdog> ok, for some reason i can't find your comments cyrus
[10:09:12] <pigdog> but the overall issue is whether we want IANA registries for most of these
[10:09:18] <cyrus_daboo> I did not comment on the list, I mean I will comment here as we go through...
[10:09:24] <pigdog> and how all of this plays with interoperabiltiy
[10:09:31] <alexeymelnikov> Let's go over each and get some consensus
[10:09:43] <pigdog> that will work for me
[10:09:52] <pigdog> so let's start with CUTYPE
[10:10:01] <cyrus_daboo> One question first:
[10:10:08] <pigdog> ok?
[10:10:13] <pigdog> go cyrus
[10:10:15] <cyrus_daboo> Is the registry going to be populated with existing items, or only new ones?
[10:10:22] <pigdog> both
[10:10:24] <pigdog> (IMHO)
[10:10:28] <pigdog> we'll seed it
[10:10:31] <apn> agree
[10:10:33] <cyrus_daboo> OK - I meant both as the first optyion.
[10:10:35] <bernard.desruisseaux> I agree. The registry should be complete.
[10:10:50] <pigdog> so moving on
[10:10:53] <pigdog> CUTYPE
[10:11:05] <pigdog> the question i will have for each of these is this:
[10:11:21] <pigdog> what if you add a new one and it is seen by an implementation that doesn't understand it
[10:11:23] <pigdog> what happens?
[10:11:43] <pigdog> so what happens in the case of CUTYPE?
[10:11:54] <cyrus_daboo> Right - does the property/param have any significant bearing on the processing of calendar data or is it merely "deocoration"?
[10:11:56] <bernard.desruisseaux> It should be handled as UNKNOWN. Easy!
[10:12:03] <alexeymelnikov> I agree
[10:12:10] <pigdog> that will be the text we need
[10:12:13] <alexeymelnikov> But maybe it needs to be explicitly stated
[10:12:18] <pigdog> right
[10:12:33] <pigdog> ok, so i need to start adding notes into the case
[10:12:45] <pigdog> this is issue 19
[10:12:48] <cyrus_daboo> The registry ought to have some statement about a default value in the case of an "unknown" one. That will take care of backwards compatability.
[10:13:02] <cyrus_daboo> i.e. we bless one value as the "default" in the registry.
[10:13:03] <bernard.desruisseaux> Eliot, I'm taking notes in my table...
[10:13:11] <apn> Does that belong to the registry though. Each param/property definition needs to spell that out. right?
[10:13:30] <pigdog> i think text needs to be placed in the appropriate section of the doc
[10:13:32] <cyrus_daboo> I think it would be good to have an indication of the default one in the registry.
[10:13:37] <pigdog> not in IANA considerations itself
[10:13:59] <pigdog> because otherwise IANA considerations balloons into a huge amount of normative text
[10:14:09] <pigdog> and trust me we don't want that
[10:14:11] <bernard.desruisseaux> Not all properties / parameters have default values.
[10:14:19] <cyrus_daboo> Note this is the default for "unrecognized" values as opposed to no value at all. The later is a spec issue.
[10:14:25] <pigdog> we generally want only IANA to look at IANA considerations
[10:14:53] <pigdog> ok, so we have an answer for CUTYPE. moving on...
[10:15:06] <alexeymelnikov> So the text about unrecognized CUTYPE will be in the section describing different values
[10:15:25] <alexeymelnikov> and there would be another section with IANA registration for CUTYPEs?
[10:15:26] <bernard.desruisseaux> Alexey: Would make sense.
[10:15:33] <pigdog> right
[10:15:48] <pigdog> moving on to ENCODING...
[10:16:05] <cyrus_daboo> There should be a broad statement somewhere about how to deal with unrecognized values, and the fact that the "unrecognized default" will be listed in the registry for each prop/param. We don't need a statement in each prop/aparm about it.
[10:16:34] <alexeymelnikov> I agree with Bernard that we don't need new registry for ENCODING
[10:16:40] <cyrus_daboo> Encoding - we should discourage the use of any new encodings.
[10:16:45] <alexeymelnikov> We should reuse an existing one
[10:16:53] <pigdog> right - that says no registry
[10:16:57] <apn> Agree.
[10:17:18] <pigdog> objections?
[10:17:22] <bernard.desruisseaux> Allowing any content-transfer-encoding would hurt interoperability I think.
[10:17:24] <alexeymelnikov> We can restrict use of some encodings, e.q. no Q-P
[10:18:18] <pigdog> i think we're ready to proceed to FMTTYPE
[10:18:27] <bernard.desruisseaux> hold on
[10:18:49] <bernard.desruisseaux> For ENCODING.... No registry... and we remove iana-token ?
[10:19:03] <pigdog> right.
[10:19:06] <bernard.desruisseaux> So we now have a restricted list.
[10:19:18] <pigdog> right.
[10:19:28] <bernard.desruisseaux> One thing though...
[10:19:56] <bernard.desruisseaux> It would have been nice to be able to specify an attachment with FMTTYPE=text/plain for instance...
[10:20:10] <bernard.desruisseaux> but to be able to "gzip' it before doing the Base64 encoding...
[10:20:28] <cyrus_daboo> That's an issue with MIME messages too.
[10:20:49] <alexeymelnikov> Bernard: then you really wand other C-T-Es, like Deflate-something
[10:20:49] <pigdog> MIME allows for what, 3 encodings. right?
[10:21:00] <cyrus_daboo> One could argue that you gzip the entire calendar object anyway for transport.
[10:21:06] <alexeymelnikov> No, there are some experimental ones from Ned
[10:21:18] <alexeymelnikov> One of them is gzip
[10:21:30] <pigdog> do we want to allow all encodings used by the MIME standard?
[10:21:37] <cyrus_daboo> No.
[10:21:38] <pigdog> and does this also hold true for FMTTYPE?
[10:21:48] <cyrus_daboo> QP would be a mess when mixed with iCal's line folding.
[10:22:15] <pigdog> but let's not create ones that AREN'T registered with MIME
[10:22:34] <pigdog> right?
[10:22:45] <bernard.desruisseaux> Ok... sorry to have brought that up... Let's stick to 8BIT and BASE64 .
[10:22:49] <alexeymelnikov> Eliot: agreed
[10:22:51] --- reinhold has joined
[10:22:58] <pigdog> hi reinhold.
[10:23:04] <pigdog> we're going through registries that are required
[10:23:29] <pigdog> so is there agreement with bernard's suggestion or do we need to expand the list?
[10:23:43] <cyrus_daboo> +1 with Bernard.
[10:23:53] <pigdog> alexey? jon?
[10:23:53] <alexeymelnikov> A future revision or an extension can expand the list of encodings
[10:23:59] <pigdog> ok
[10:24:02] <pigdog> no registry needed
[10:24:13] <alexeymelnikov> So I agree with no registry
[10:24:18] <jonlennox> I mostly just care about recurrences, so I'm good with whatever you think is reasonable. :-)
[10:24:24] <pigdog> FMTTYPE
[10:24:43] <pigdog> just use the mime types registry, right?
[10:24:45] <cyrus_daboo> FMTTYPE - no registry needed. +1 with bernard
[10:24:49] <alexeymelnikov> +1
[10:25:04] <alexeymelnikov> But we need to decide if parameters are allowed here ;-)
[10:25:04] <bernard.desruisseaux> one question for FMTTYPE though...
[10:25:07] <bernard.desruisseaux> The ABNF...
[10:25:14] <pigdog> ...
[10:25:25] <bernard.desruisseaux> fmttypeparam = "FMTTYPE" "=" iana-token ; A IANA registered media type / x-name ; A non-standard media type
[10:25:47] <pigdog> is there ABNF that can be borrowed from the MIME RFCs?
[10:26:13] <alexeymelnikov> Eliot: I am not sure
[10:26:42] <pigdog> or should we just modify the text in the ABNF to say = see RFC 2045
[10:26:58] <bernard.desruisseaux> Actually... I brought this up when we were discussing Alexey's issues...
[10:27:01] <pigdog> or the registry created by thus
[10:27:33] <pigdog> so, i think we have some word smithing but I don't need that needs to happen in the jabber
[10:27:37] <pigdog> are people agreed to that?
[10:27:45] <cyrus_daboo> +1
[10:27:58] <alexeymelnikov> This almost looks like a separate issue
[10:28:13] <alexeymelnikov> I am fine with not discussing it now
[10:28:30] <pigdog> let's give Bernard a shot to solve it oob, perhaps with me
[10:28:37] <pigdog> or vica versa
[10:28:38] <bernard.desruisseaux> cool
[10:28:45] <pigdog> ok. FBTYPE
[10:28:58] <pigdog> what happens when you see an unknown FBTYPE?
[10:29:26] <bernard.desruisseaux> Handle as BUSY
[10:29:28] <cyrus_daboo> Either treat as BUSY-UNAVAILABLE or BUSY. I think the former makes more sense.
[10:29:43] <cyrus_daboo> I guess that is -1 with Bernard then...
[10:30:08] <pigdog> so here is a general rule: if we can't come to consensus as to what to do - no registry
[10:30:14] <pigdog> ;-)
[10:30:21] <cyrus_daboo> With the "OUT-OF-OFFICE" example, I think BUSY-UNAVAILABLE would be a better default.
[10:30:23] <bernard.desruisseaux> +1 w/ BUSY-UNAVAILABLE
[10:30:37] <pigdog> but what if the new value is some sort of "MAYBE"
[10:30:40] <cyrus_daboo> No - we agree on a registry, just not what the default for unrecognized should be.
[10:31:02] <pigdog> if you can't agree on the unknown behavior we can't have a registry. otherwise we create a mess
[10:31:16] <cyrus_daboo> Then whoever defines "MAYBE" will need to note that older clients will treat it as BUSY-UNAVAILABLE.
[10:31:30] <pigdog> so, if we can agree that unknown = busy then we in fact have consensus. bernard?
[10:32:03] <bernard.desruisseaux> I was fine with BUSY-UNAVAILABLE...
[10:32:06] <pigdog> ok
[10:32:13] <pigdog> PARTSTAT (VEVENT)
[10:32:37] <pigdog> what to do when it is not recognized?
[10:32:59] <bernard.desruisseaux> it depends on your ROLE...
[10:33:04] <cyrus_daboo> Can we add a new "UNKNOWN" value int he spec?
[10:33:20] <alexeymelnikov> Regarding PARTSTAT - should we have 1 registry for all components, listing to which ones they can apply?
[10:33:21] <bernard.desruisseaux> If you are the "Organizer" and receive "FOO" from an "Attendee"... what do you do...
[10:33:23] <bernard.desruisseaux> Nothing!
[10:34:05] <pigdog> what happens to your implementation if someone sends garbage in that field?
[10:34:05] <bernard.desruisseaux> Or is the question... what should the client display to the "Organizer" ?
[10:34:23] <pigdog> bingo. what happens?
[10:34:23] <bernard.desruisseaux> Fall back to "NEEDS-ACTION" seems reasonable...
[10:34:53] <pigdog> but what if you then send a reminder and the INVITEE sends the same response?
[10:34:58] <pigdog> are you sure you want a registry here?
[10:35:04] <cyrus_daboo> Not sure about that - I think a client could just display something like "unknwon", "???"
[10:35:24] <pigdog> what does yours do?
[10:35:24] <bernard.desruisseaux> What about existing clients?
[10:35:53] <pigdog> i would like to suggest that you probably DON'T want a registry here
[10:36:03] <bernard.desruisseaux> Humm....
[10:36:07] <cyrus_daboo> OK - these params do seriously effect what happens in iTIP. So shall we say no new ones, i.e. no registry?
[10:36:26] <pigdog> that would be my suggestion
[10:36:40] <bernard.desruisseaux> For VTODO components there are other possible parttstats
[10:37:17] <bernard.desruisseaux> You might what to report that you are "waiting on another task to be completed"...
[10:37:21] <apn> Wait. A registry also serves as an index to already defined (standard) components. Granted there's no risk of clashing with non-standard ones because of the X- prefix, but still...
[10:37:36] <cyrus_daboo> The use TENTATIVE and a COMMENT back to the organizer.
[10:37:44] <pigdog> you only need to add a registry for things you expect to change
[10:37:50] <pigdog> (expand, in particular)
[10:38:22] <pigdog> so what is the behavior for PARTSTAT in VTODO when you see UNKNOWN?
[10:38:48] <bernard.desruisseaux> NEEDS-ACTION!
[10:39:13] <pigdog> everyone agree?
[10:39:29] <alexeymelnikov> Fine with me
[10:40:17] <cyrus_daboo> +1
[10:40:35] <pigdog> so how about "registry needed. standards action required for VEVENTs. perhaps only expert review for VTODO"
[10:40:48] <pigdog> or even less
[10:40:51] <pigdog> thoughts?
[10:40:59] <bernard.desruisseaux> I also agree with Alexey that one registry for all three types of partstat should be sufficient... the table should simply have one more table to specify the component type to which it applies.
[10:41:14] <pigdog> right
[10:41:22] <alexeymelnikov> Expert review is fine
[10:41:27] <cyrus_daboo> Yes.
[10:41:33] <pigdog> ok... i have the note on this. moving on to RELTYPE
[10:41:56] <pigdog> what other RELTYPEs are there?
[10:42:00] <pigdog> could there be?
[10:42:28] <pigdog> and what would you do if you saw one?
[10:42:28] <bernard.desruisseaux> GRAND-CHILD ? DESCENDANT ? CLONE ?
[10:42:42] <bernard.desruisseaux> Ignore the value.
[10:43:14] <pigdog> is everyone agreed?
[10:43:30] <alexeymelnikov> Seems reasonable
[10:43:48] <cyrus_daboo> +1
[10:43:51] <pigdog> ok...
[10:44:37] <pigdog> ROLE
[10:44:51] <cyrus_daboo> Actually I have a lightly different problem with ROLE. Why can't you have multiple roles? I could be the "CHAIR" and a "SPEAKER".
[10:45:09] <cyrus_daboo> Sorry - that is a new issue.
[10:45:13] <pigdog> um... right
[10:45:30] <pigdog> default = ?
[10:45:35] <pigdog> OPT or REQ?
[10:45:54] <bernard.desruisseaux> Default: Ignore. ROLE is optional...
[10:46:03] <cyrus_daboo> REQ is the defult if not specified.
[10:46:22] <pigdog> ok... so treat as REQ if unknown?
[10:46:25] <cyrus_daboo> Bernard - it is optional but the default is REQ.
[10:46:38] <bernard.desruisseaux> Ok. Then REQ it is!
[10:46:53] <pigdog> ok
[10:46:57] <pigdog> VALUE...
[10:47:14] <pigdog> no way to have a default for unknown here
[10:47:24] <pigdog> right?
[10:47:27] <bernard.desruisseaux> Hold on!!
[10:47:29] <cyrus_daboo> VALUE is the same for me as ENCODING. We should leave all as-is. A new value should require a version bump IMHO.
[10:47:50] <bernard.desruisseaux> For RELTYPE... the default was PARENT... so shouldn't we fall back to PARENT ? I think so
[10:48:10] <cyrus_daboo> Yes to RELTYPE fallback.
[10:48:16] <pigdog> that seems fair
[10:48:26] <cyrus_daboo> PS I like the term "fallback" for dealing with unrecognized values.
[10:48:42] <pigdog> ok
[10:49:03] <pigdog> so no VALUE registry?
[10:49:07] <bernard.desruisseaux> BTW, the "fallback" also applies to x-name as well...
[10:49:17] <bernard.desruisseaux> Not sure about this...
[10:49:18] <pigdog> btw, no registry, no x-name
[10:49:24] <cyrus_daboo> Yes to x-name -> "fallback"
[10:49:33] <pigdog> if you can't have iana-token you can't have x-name
[10:49:38] <bernard.desruisseaux> All value types follow the "value" ABNF.
[10:50:06] <alexeymelnikov> Is it likely that new value types will be added?
[10:50:07] <bernard.desruisseaux> So a compliant parser should be able to parse any new type
[10:50:10] <alexeymelnikov> I think it is likely
[10:50:30] <pigdog> right.... we need a restriction on VALUE types that says something like - only on new properties or parameters
[10:50:52] <pigdog> which is the only thing i could imagine, anyway
[10:51:14] <pigdog> thoughts?
[10:51:21] <bernard.desruisseaux> Humm... But one could define a property that accept any value...
[10:51:24] <cyrus_daboo> The problem is there are restrictions on what values are allowed for properties anyway. It does not make sense for a new value type that defines some type of text to be used with DTSTART. So the registry would have to explicitly list the properties the new value would be allowed on.
[10:51:47] <bernard.desruisseaux> Nah...
[10:51:48] <alexeymelnikov> If there is a generic syntax for VALUE, then a new value type can be allowed anywhere: parsers can skip them
[10:51:51] <bernard.desruisseaux> The other way around...
[10:51:56] --- apn has left: Replaced by new connection
[10:52:13] <bernard.desruisseaux> Properties state the value type allowed.
[10:52:17] <cyrus_daboo> You mean properties list which values are allowed?
[10:52:27] --- apn has joined
[10:52:27] <bernard.desruisseaux> Yes. That's what we already do.
[10:52:40] <bernard.desruisseaux> When you define a new property you don't need to update the VALUE registry.
[10:52:41] <cyrus_daboo> OK - then in that case you can't create a new value without also creating a new property that supports it.
[10:52:49] <pigdog> right
[10:53:02] <bernard.desruisseaux> :-)
[10:53:05] <pigdog> and you specify the context in which it is allowed
[10:53:09] <pigdog> agreed?
[10:53:13] <bernard.desruisseaux> We already have BOOLEAN and ... well... it is not used.
[10:53:30] <cyrus_daboo> Given that you can always use VALUE=TEXT, but say the value is structured in some way (e.g. XML blob) I don't think we need new value types.
[10:53:33] <bernard.desruisseaux> I don't see the issue
[10:54:06] <bernard.desruisseaux> No. I think we should leave the door open.
[10:54:10] <cyrus_daboo> PS have to go at 11.00 est.
[10:54:30] <alexeymelnikov> I think we should allow for new value types
[10:54:38] <pigdog> so - i'd suggest we have the registry, but be clear about what needs to be specified
[10:54:38] <cyrus_daboo> I disagree.
[10:54:54] <pigdog> (only new props etc.)
[10:55:00] <pigdog> or only new params
[10:55:11] <bernard.desruisseaux> params don't have value type
[10:55:20] <pigdog> sorry - right
[10:55:45] <pigdog> also, standards action required?
[10:55:53] <pigdog> or expert review?
[10:56:00] <alexeymelnikov> We can require at least expert review
[10:56:29] <alexeymelnikov> This is a high enough obstacle to prevent bogus registrations
[10:56:37] <pigdog> fair enough cyrus?
[10:56:47] <cyrus_daboo> I still disagree - even with review - a new value type implies some new significant semantic change - it should be a version bump.
[10:57:00] <bernard.desruisseaux> I don't agree.
[10:57:07] <bernard.desruisseaux> You don't break the parsing.
[10:57:09] <pigdog> ok. we do not have agreement on this one yet. i propose we move on and circle back on the list
[10:57:18] <pigdog> perhaps an example or two would help
[10:57:28] <cyrus_daboo> OK - to the list.
[10:57:35] <pigdog> ok...
[10:57:55] <pigdog> CALSCALE
[10:58:00] <pigdog> no registry required.
[10:58:02] <pigdog> imho
[10:58:04] <cyrus_daboo> No registry for CALSCALE.
[10:58:07] <alexeymelnikov> +1
[10:58:14] <pigdog> METHOD
[10:58:16] <alexeymelnikov> I am also fine with deprecating it
[10:58:21] <cyrus_daboo> A change in CALSCALE involves a wholesale change to iCalendar - again a major version bump.
[10:58:21] <bernard.desruisseaux> Should we deprecate CALSCALE?
[10:58:35] <pigdog> i'd like not to have that discussion now
[10:58:37] <bernard.desruisseaux> The RRULE are foobar with any other CALSCALE
[10:58:40] <bernard.desruisseaux> ok
[10:58:47] <cyrus_daboo> No - do not deprecate. There are still some people interested in supporting other calscales directly.
[10:58:56] <pigdog> METHOD
[10:59:00] <pigdog> absolutely
[10:59:01] <bernard.desruisseaux> Hold on...
[10:59:14] <bernard.desruisseaux> CALSCALE... No registry... thus no iana-token nor x-name allowed... is that it?
[10:59:19] <pigdog> right
[10:59:23] <cyrus_daboo> +1
[10:59:27] <bernard.desruisseaux> Useful property!
[10:59:32] <pigdog> ;-)
[10:59:39] <pigdog> METHOD
[10:59:45] <pigdog> expert review or standards action?
[10:59:58] <cyrus_daboo> Yes to registry - needs standards action.
[11:00:05] <pigdog> ok, and unknown?
[11:00:08] <alexeymelnikov> stanrards action
[11:00:20] <bernard.desruisseaux> Well... method is used in a transaction...
[11:00:28] <bernard.desruisseaux> a REQUEST-STATUS should be returned...
[11:00:30] <cyrus_daboo> iTIP has an error code for unknown method, if I am not mistaken. It should be treated as an error.
[11:00:36] <bernard.desruisseaux> Right
[11:00:47] <jonlennox> Have to leave...
[11:01:01] <jonlennox> I'll try to address my todos from last week before next week
[11:01:14] --- jonlennox has left
[11:01:16] <cyrus_daboo> Me too - on ACTION I agree with registry and expert review - dump PROCEDURE.
[11:01:17] <pigdog> ok, so old components will error back on new methods. don't see how to avoid it. but still need to allow for new methods
[11:01:35] <pigdog> ok thanks. we'll end now if we're agreed on ACTION
[11:01:36] <alexeymelnikov> +1 on dumping PROCEDURE
[11:01:52] <alexeymelnikov> What about CLASS?
[11:02:04] <apn> For PROCEDURE, I'll update the ticket in the tracker. It's gone ;)
[11:02:06] <pigdog> good point.
[11:02:10] <cyrus_daboo> CLASS +1 for registry.
[11:02:11] <bernard.desruisseaux> Registry for CLASS. Fallback to PRIVATE
[11:02:15] <pigdog> ok
[11:02:21] <alexeymelnikov> +1 for registry
[11:02:29] --- cyrus_daboo has left
[11:02:38] <bernard.desruisseaux> Although the default for CLASS is PUBLIC... it doesn't make sense to fallback to PUBLIC... too dangerous
[11:02:52] <pigdog> ok.
[11:02:56] <alexeymelnikov> agreed
[11:02:59] <pigdog> what is the default for ACTION?
[11:03:09] <alexeymelnikov> DISPLAY?
[11:03:25] <apn> I'd say with unknown ACTION = no action at all
[11:03:46] <bernard.desruisseaux> No default for ACTION.
[11:03:54] <alexeymelnikov> Ok
[11:03:58] <pigdog> ignore?
[11:04:27] <apn> We done?
[11:04:31] <bernard.desruisseaux> I guess... One can specify multiple VALARM
[11:04:32] <alexeymelnikov> No :-)
[11:04:38] <alexeymelnikov> Not done yet
[11:04:40] <pigdog> right
[11:04:48] <alexeymelnikov> There are other things that need IANA registrations:
[11:04:54] <apn> :)
[11:05:02] <pigdog> alexey: ?
[11:05:03] <alexeymelnikov> new properties, parameters, components, other classes for the return status code
[11:05:28] <pigdog> isn't that iTIP?
[11:05:31] <alexeymelnikov> We don't need to discuss details now, but they should be mentioned in the tracker
[11:05:39] <bernard.desruisseaux> status codes for these classes. In addition, other classes for the return status code may be defined using the registration process defined later in this memo.
[11:05:49] <bernard.desruisseaux> Alexey is right... Do we REALLY need that?
[11:06:14] <pigdog> good question - Aki is going to take over from this point. thanks all.
[11:06:16] <alexeymelnikov> Experience with SMTP and other protocol suggest that we need that
[11:06:28] <bernard.desruisseaux> Actually... we will need a registry for each individual REQUEST-STATUS value...
[11:06:34] <alexeymelnikov> But this can be an iTIP value
[11:06:36] <bernard.desruisseaux> i'm not sure about needing more classes...
[11:06:45] --- pigdog has left
[11:07:16] <bernard.desruisseaux> Alexey: SMTP has more than 5 classes?
[11:07:32] <alexeymelnikov> No
[11:07:49] <alexeymelnikov> I am thinking about second/third level things
[11:08:00] <bernard.desruisseaux> I see.
[11:08:08] <bernard.desruisseaux> Okay for the registry.
[11:08:18] <bernard.desruisseaux> Was there anything else that needed a registry?
[11:08:56] <alexeymelnikov> The 4 things I've mentioned above + register iCalendar version number with IANA
[11:09:31] <alexeymelnikov> So, iCalendar version numbers
[11:09:49] <alexeymelnikov> As in "version X is defined in RFC Y"
[11:10:22] <bernard.desruisseaux> Ok.
[11:10:25] <apn> Maybe that should be the title for the registry?
[11:10:39] <bernard.desruisseaux> :-)
[11:11:32] <alexeymelnikov> Well, a future version can remain backward compatible
[11:11:48] <alexeymelnikov> So it will extend existing registries
[11:13:46] <apn> But the RFC would obsolete/update the old one, too.
[11:15:05] <apn> ping
[11:15:07] <alexeymelnikov> As long as it is clear which elements are allowed for which iCalendar version, it is Ok to reuse registries, IMHO
[11:15:31] <alexeymelnikov> But of course I can't predict the future of iCalendar ;-)
[11:16:46] <apn> Ok. Anything else we need to discuss today, or should we stop here?
[11:17:01] <alexeymelnikov> I think we are done for today
[11:17:12] <alexeymelnikov> I need to go back to my work anyway
[11:17:23] <apn> Allrightie then. See you next week! Bye!
[11:17:40] <alexeymelnikov> Bye
[11:17:42] <bernard.desruisseaux> Thanks! Bye!
[11:17:45] --- reinhold has left
[11:17:46] --- bernard.desruisseaux has left
[11:17:47] --- apn has left
[11:17:51] --- alexeymelnikov has left
[12:58:38] --- cyrus_daboo has joined
[12:58:49] --- cyrus_daboo has left