[14:13:08] --- cyrus_daboo has joined
[15:02:10] --- resnick has joined
[15:05:15] --- pguenther has joined
[15:05:38] --- randy has joined
[15:06:26] <cyrus_daboo> lisa, we did VIEW then WINDOW. I'm not sure whether the drafts still exist online.
[15:07:12] <cyrus_daboo> I think I have local copies of the last ones.
[15:18:19] <randy> Cyrus, what are you saying (I can hear your voice from Pete's Mac but can't make out the words)
[15:18:54] --- robsiemb has joined
[15:33:14] --- resnick has left: Disconnected
[15:33:14] --- resnick has joined
[15:33:14] --- resnick has left: Lost connection
[15:40:44] --- resnick has joined
[15:43:23] <randy> Discussion on ways to transport iCal objects
[15:44:26] --- resnick has left: Disconnected
[15:47:36] --- randy has left: Logged out
[15:47:41] --- randy has joined
[15:48:08] --- smaes has joined
[15:49:07] --- resnick has joined
[15:56:38] --- corby has joined
[16:00:40] <resnick> Someone care to jabber?
[16:00:52] <robsiemb> I can do it
[16:00:56] <resnick> thx
[16:00:58] <robsiemb> we're starting
[16:01:06] <robsiemb> i18n draft
[16:01:15] <robsiemb> Lisa: is there anything for us to not submit it?
[16:01:34] <robsiemb> obviously it is pending on the comparator draft but we can let it sit with the rfc queue
[16:01:47] --- resnick has left: Disconnected
[16:01:51] <robsiemb> Alexey: has it been last called even?
[16:01:56] --- resnick has joined
[16:02:00] <robsiemb> lisa: ok, we'll do a WGLC
[16:02:28] <robsiemb> 2086bis
[16:02:49] <robsiemb> Lisa: we did a last call, the changes seem minor enough that we don't need to recycle, alexey?
[16:03:07] <robsiemb> Alexey: there is a d right issue -- should it return d on any instead of all, (but keep all on setting).
[16:03:35] <robsiemb> Phillip: Clients shouldn't be checking the acl to decide what they can do, this is a problem in the unix world
[16:05:20] <robsiemb> ...we might want text saying that this is bad.
[16:06:51] <robsiemb> Rob: is there a known client application that will break?
[16:07:38] <robsiemb> Cyrus [by video]: Yes, mulberry is affected by this
[16:08:16] <robsiemb> General consensus that saying any instead of all is probably desirable.
[16:08:34] <robsiemb> Lisa: this will not cause a recycle
[16:08:46] <robsiemb> Phillip: clarify that this is both 'c' and 'd', not just 'd'
[16:12:51] <robsiemb> (discussion of what bits are tied to 'c' and 'd' for this specifically)
[16:13:09] <robsiemb> What do implementations do: Cyrus ties delete mailbox to 'c'... others?
[16:14:18] <robsiemb> Lisa: I feel we are over-shining this, lets just pick one.
[16:14:44] <robsiemb> Alexey: we probably want to not include 'c' and 'd' in ACL2.
[16:14:47] <robsiemb> Rob/Phillip: YES
[16:15:42] <robsiemb> Alexey: 'd' rights and LISTRIGHTS - do we report 'd' if any are allowed (previously we were discussingMYRIGHTS)
[16:17:22] <robsiemb> one proposal is extend LISTRIGHTS
[16:18:38] <robsiemb> ...
[16:18:46] <robsiemb> Rob: Is this actually a problem in implementations today?
[16:19:27] <robsiemb> Lisa: We need to focus on real issues for this interim document, not ones we invent.
[16:19:49] <robsiemb> Rob: Add a short note about the issue and mention that this is an interim solution anyway.
[16:20:00] <robsiemb> Lisa: Are there any remaining annotate references?
[16:20:03] <robsiemb> Alexey: No
[16:20:04] <robsiemb> annotate
[16:20:47] <robsiemb> Cyrus: some text to be verified on behavior of unsolicited responses (you only get entry names and not the values)
[16:21:34] <robsiemb> Lisa: so once that is fixed, we can WGLC? when will this be available?
[16:21:40] <robsiemb> Cyrus: Yes, realisticly 1.5 weeks
[16:21:49] <robsiemb> Lisa: Jan 31 then?
[16:21:53] <robsiemb> Cyrus: Sure
[16:24:01] <robsiemb> Alexey will post changes to 2086bis approx end of next week, after which if no meaningful comments in 3 days we will send to Scott for call.
[16:25:15] <cyrus_daboo> Sorry iChat just crashed on me. I would like to discuss annotatemore process...
[16:26:20] <randy> Cyrus, what is the new wording going to be for ANNOTATE and unsolicited responses?
[16:26:42] <randy> How will it change from the wording in -11 (in section 3.4)?
[16:26:51] <robsiemb> Cyrus: What is procedure for "WGLC" of non-WG documents, I'd like to do it in parallel with annotate.
[16:27:31] <robsiemb> Lisa: Sure
[16:27:36] <randy> Since WGLC is itself an informal process, it can be whatever we want
[16:27:41] <robsiemb> Cyrus: I'm done!
[16:28:18] <robsiemb> Other Extensions: LISTEXT, CONDSTORE (yanked back from IESG!), and ACL2
[16:28:36] --- cyrus_daboo has left: Disconnected
[16:29:30] <robsiemb> Alexey: I want to yank back from IESG. 2 reasons: procedural, stuck with dependency on annotate
[16:29:58] <robsiemb> I'd rather cut and paste ABNF bits from ANNOTATE rather then waiting on that document.
[16:30:24] <robsiemb> I also want to make it work for expunges (that is, update the MODTIME on expunges). It probably should
[16:30:35] <robsiemb> where "I" == "alexeey"
[16:31:31] <robsiemb> Pete: First issue is minor, but should only be fixed if we pull back for the second reason.
[16:35:57] <robsiemb> (Discussion of how this would actually work ensues... using EXPUNGED responses in response to FETCH CHANGEDSINCE...)
[16:36:52] <robsiemb> Lisa: what does this mean procedurally? Ted: It will probably go atleast back to the IESG, and possibly the IESG will send it back to the IETF with working group counsel.
[16:39:34] <randy> Why not use EXSPONGE :-)
[16:40:19] <robsiemb> Alexey will write text, then we will make a decision.
[16:40:43] <robsiemb> an ex-sponge sounds like the end of an overused mop
[16:40:52] <resnick> FORMERSQUAREPANTS?
[16:41:24] <robsiemb> LISTEXT
[16:42:51] <robsiemb> Phillip: Issue is the set of HasParent, IsSubMailbox, etc... most of these try to deal with an oddball behavior in LSUB NoSelect flag
[16:43:34] <robsiemb> LSUB whose last character is % must responds with matching hierarchy levels with subscribed children -- and unsubscribed mailboxes must return NoSelect, which overloads the meaning
[16:44:50] <robsiemb> When LSUB is merged into list as SUBSCRIBED we still need some way to say "this has children that are subscribed, but do not match this pattern"
[16:46:17] <robsiemb> There are also cases with non-subscribed mailboxes where we want to know that there are sub-mailboxes that do not match the pattern but do match the criteria (e.g. SUBSCRIBED or even a hierarchy level that doesn't exist but has children that do)
[16:46:25] <robsiemb> Initial idea: \Placeholder
[16:47:14] <robsiemb> It is also necessary to return "presense of children" even when the name *does* match (where Placeholder does not apply)
[16:47:27] <randy> Rob, "an ex-sponge sounds like the end of an overused mop" -- fitting, no?
[16:48:51] <robsiemb> Phillip: Mark said that LSUB foo and LSUB (\NoSelect) foo to indicate that foo was subscribed and foo had submailboxes that were subscribed
[16:49:18] <robsiemb> Phillip: this is actually even worse for the non-subscription case
[16:53:11] <robsiemb> Barry: it might be reasonable to say that Placeholder can't be sent for unsolicited responses and clients can't pipeline to cause this
[16:54:07] <robsiemb> Phillip's Proposal: The Base Spec, however unclear, required that this information be returned whenever the pattern ended with % and only then.
[16:55:22] <robsiemb> Instead of match parent option, follow the % usage of the base spec.
[16:56:37] --- cyrus_daboo has joined
[16:56:42] <robsiemb> That is "the existance of children that match the criteria"
[16:57:19] <robsiemb> Also, instead of marking them as hasSubMailbox or Placeholder return list extension data that says "child period" "child subscribed" etc.
[16:57:28] <robsiemb> Phillip gets up to draw this on the board
[16:58:03] <robsiemb> Lisa: Is anyone against getting rid of match parent
[16:58:04] <robsiemb> [no one is]
[16:58:17] <robsiemb> Lisa: second question, does anyone else besides phillip say hear-irchy?
[16:58:22] <robsiemb> [only alexey]
[16:59:59] <robsiemb> syntax on board:
[17:00:22] <robsiemb> * LIST () "/" foo ((CHILDINFO ()))
[17:00:24] <robsiemb> or
[17:00:27] --- tonyhansen has joined
[17:00:46] <robsiemb> * LIST () "/" foo ((CHILDINFO ("\\Subscribed")))
[17:01:03] <robsiemb> In response to LIST () "" "%"
[17:01:13] <robsiemb> First line is "foo exists and has a child"
[17:01:46] <robsiemb> but child is not subscribed
[17:02:16] <robsiemb> hierarchy is
[17:02:16] <robsiemb> foo
[17:02:18] <robsiemb> foo/bar
[17:02:21] <robsiemb> bar/baz
[17:03:04] <robsiemb> To rephrase: to interpret placeholder you have to know the command that prompted it. Here, you don't
[17:04:51] --- corby has left: Disconnected
[17:09:08] <robsiemb> [complicated discussion]
[17:17:56] <robsiemb> Barry proposes:
[17:18:03] <robsiemb> LIST (MARKED MATCH-PARENT) "" "%"
[17:18:15] <robsiemb> * LIST () "/" "Foo" (HasChildren)
[17:18:31] <robsiemb> * LIST (Marked) "/" "Fie" (HasChildren)
[17:18:42] <robsiemb> * LIST (Marked) "/" "Foe"
[17:19:31] <robsiemb> Foo: HasChildren indicates that somewhere under Foo there is a Marked folder (because we specified matched parent)
[17:20:01] <robsiemb> Foe: Is marked, no children are.
[17:20:14] <robsiemb> Fie: Does this mean that it has marked children or it just has children?
[17:20:27] <robsiemb> And this is why we have hasSubMailboxes
[17:20:56] <robsiemb> Now we do LIST (MARKED CHILDREN MATCHP) "" "%"
[17:21:01] <robsiemb> now I know even less about Fie
[17:21:33] <robsiemb> Perhaps I should have said "Barry Says" instead "Barry Proposes"
[17:21:59] <robsiemb> Lisa: does anyone else do something similar?
[17:23:04] <robsiemb> (sort of ldap)
[17:24:14] <robsiemb> Lisa: What if we have HaveMatchedChildren instead of the full specificity?
[17:25:54] <robsiemb> Cyrus: the client knows what its query was, so it can tell.
[17:26:21] <robsiemb> Barry: maybe Children is a special case that is overloaded now?
[17:26:34] <randy> Putting which criteria matched in the response would allow the client to not need to remember the query and just process the response
[17:27:52] <robsiemb> Rob: Reminder that CHILDREN is *not* a match criteria, but more of a mode switch
[17:29:58] <robsiemb> * LIST (\HasSubChild) "/" foo
[17:30:01] <robsiemb> (on board now)
[17:31:21] <robsiemb> where HasSubChild == HasSubscribedChild
[17:32:07] <robsiemb> Back to Barry's example:
[17:32:21] <robsiemb> * LIST (Marked) "/" "fum" (HASMATCH)
[17:32:31] <robsiemb> * LIST () "/" "FOO" (HASMATCH)
[17:32:58] <robsiemb> fie and foe stay the same
[17:33:22] <robsiemb> foo: "I don't match but I have children that do"
[17:33:56] <robsiemb> fie: "I match and I have children but they do not match"
[17:34:04] <robsiemb> foe: "I match, no children"
[17:34:12] <robsiemb> fum: "I match, I have children that match"
[17:34:47] <robsiemb> Lisa: I want this to be easy to explain, I want nothing overloaded and there is only one meaning
[17:34:55] <robsiemb> that is easy to explain
[17:35:51] <robsiemb> (discussion of current children extension)
[17:37:17] <robsiemb> Phillip: if you are asking for subscribed, do you ever want to know unsub children?
[17:37:19] <robsiemb> Cyrus: no
[17:37:36] <robsiemb> Barry: ???? (I missed the question) Cyrus doesn';t think its a problem
[17:44:52] <robsiemb> We appear to be approaching consensus on Barry's version
[17:46:44] <robsiemb> Phillip: we still have a problem if you specify MATCH-PARENT and it ends in a star
[17:49:08] <robsiemb> Does anyone care about children info if pattern doesn't end in a percent?
[17:49:14] <robsiemb> (barry)
[17:49:17] <robsiemb> Cyrus: no, probably not
[17:49:27] <robsiemb> (FWIW, Rob agrees)
[17:50:28] <robsiemb> Ok, we're going to now go through a bunch of cases
[17:50:50] <robsiemb> Using the foo, fie, foe, fum from before:
[17:50:57] <robsiemb> LIST (CHILDREN) %
[17:51:15] <robsiemb> * LIST () "foo" (HASCH)
[17:51:43] <robsiemb> But we're going to sketch out the hierarchy first
[17:51:47] <robsiemb> foo
[17:52:14] <robsiemb> foo/x * (* means marked)
[17:52:17] <robsiemb> fie *
[17:52:19] <robsiemb> frie/x
[17:52:21] <robsiemb> foe *
[17:52:22] <robsiemb> foe/x
[17:52:24] <robsiemb> fum *
[17:52:25] <robsiemb> fum/x *
[17:52:30] <robsiemb> whoops
[17:52:33] <robsiemb> there is no foe/x
[17:52:58] <robsiemb> OK: we do LIST(CHILDREN) %
[17:53:05] <robsiemb> * LIST () "foo" (HASCH)
[17:53:14] <robsiemb> * LIST () "fie"
[17:53:22] <robsiemb> * LIST () "foe"
[17:53:47] <robsiemb> errrrrr -> * LIST () "fie" (HASCH)
[17:53:55] <robsiemb> * LIST () "fum" (HASCH)
[17:54:44] --- corby has joined
[17:54:45] <robsiemb> The first LIST () % lacks all of the stuff to the right of the mailbox names
[17:56:16] * robsiemb tries to do his best with the transcription
[17:56:35] <robsiemb> OK, now we do LIST (CHILDREN MARKED) %
[17:56:49] <robsiemb> Where MARKED can be SUBSCRIBED or any other *selection* criteria
[17:57:17] <robsiemb> all 4 will still be returned
[17:57:29] <robsiemb> (side note that syntax here is being played a bit fast and loose)
[17:57:39] <robsiemb> * LIST () "foo" (HASMATCH)
[17:57:51] <robsiemb> * LIST (MARKED) "fie" (HASCH)
[17:57:58] <robsiemb> * LIST (MARKED) "foe"
[17:58:06] <robsiemb> * LIST (MARKED) "fum" (HASMATCH)
[17:59:29] <robsiemb> Philip: subscribed doesn't work for this because you can be subed to an nonexistent mailbox
[17:59:35] <robsiemb> Barry: I don't want to fight with people, you can do it.
[17:59:39] <robsiemb> So we actually have:
[17:59:44] <robsiemb> * LIST () "foo" (HASCH HASMATCH)
[18:00:05] <robsiemb> * LIST (MARKED) "fie" (HASCH)
[18:00:15] <robsiemb> * LIST (MARKED) "foe"
[18:00:27] <robsiemb> * LIST (MARKED) "fum" (HASCH HASMATCH)
[18:00:33] <robsiemb> Barry:
[18:00:35] <robsiemb> Is this confusing?
[18:00:40] <robsiemb> Does it not solve all the use cases?
[18:01:22] <robsiemb> MATCH-PARENT hasn't been discussed here, but we agreed that it only makes sense with % and is only there to tell the server if the client cares or not
[18:02:07] <robsiemb> Lisa: I like other names better, but we definately want MATCH-PARENT as a flag instead of DEPTH=
[18:02:50] <robsiemb> Jutta: I have one remaining qualm, if I don't specify RECURSIVEMATCH or whatever, then what does HASMATCH mean?
[18:03:05] <robsiemb> Barry: if you don't say RECURSIVE or whatever don't return HASMATCH
[18:03:09] <robsiemb> seems reasonable to the room
[18:03:37] <robsiemb> all previous examples assumed RECURSIVE or whatever
[18:03:48] <robsiemb> If we omit that, we get:
[18:04:46] <robsiemb> * LIST (MARKED) "FIE" (HASCH)
[18:04:50] <robsiemb> * LIST (MARKED) "FOE"
[18:04:59] <robsiemb> * LIST (MARKED) "FUM" (HASCH)
[18:05:36] <robsiemb> And LIST (MARKED RECURSIVE) % does:
[18:05:43] <robsiemb> * LIST () "FOO" (HASMATCH)
[18:05:55] <robsiemb> * LIST () "FIE" ()
[18:06:02] <robsiemb> errrr
[18:06:07] <robsiemb> * LIST (MARKED) "fie" ()
[18:06:13] <robsiemb> * LIST (MARKED) "foe" ()
[18:06:21] <robsiemb> * LIST (MARKED) "fum" (HASMATCH)
[18:06:49] <robsiemb> Jutta points out that there is still confusion about the bizarre behavior of the trailing %
[18:07:16] <robsiemb> For *LIST (RECURSIVEMATCH CHILDREN) %
[18:07:19] <robsiemb> RECURSIVEMATCH is a NOOP
[18:08:14] <robsiemb> Barry/Phillip: If there is no selection critieria, the criteria is implied to be "SELECT EXISTS"
[18:08:40] <robsiemb> Discussion: do we want to forbid RECURSIVEMATCH without selction criteria?
[18:09:00] <robsiemb> Phillip's Example:
[18:09:25] <robsiemb> LSUB % (and make the * on the mailbox list be "subscribed")
[18:09:40] <robsiemb> * LSUB \NoSelect Foo
[18:09:48] <robsiemb> * LSUB Fie
[18:09:53] <robsiemb> * LSUB Foe
[18:10:05] <robsiemb> * LSUB FUM
[18:10:21] <robsiemb> (there is an argument that you may also get):
[18:10:27] <robsiemb> * LSUB \NoSelect fum
[18:11:01] <robsiemb> Now we do *LSUB %o
[18:11:06] <robsiemb> And the entire list dissapears!
[18:12:41] <robsiemb> The question is: LIST () % -- does this have the "odd" behavior of LIST % ?
[18:14:05] --- corby has left: Disconnected
[18:17:41] <robsiemb> Jutta continues to ask if the current behavior of LSUB where CHILDREN meansd there "might" be children still works?
[18:17:48] <robsiemb> Some confuison in the room about that
[18:19:54] <robsiemb> That is, do any current servers try to save themselves work here?
[18:20:20] <robsiemb> Currently the document forbids RECURSIVE (er, MATCH_PARENT) without selection criteria
[18:21:13] <robsiemb> Phillip: Also, if CHILDREN is specified, the current draft allows the server to ignore other flags
[18:21:33] <robsiemb> barry: I thought it was "if you didn't specify it" the server could choose to send or not, but if you specified it, it HAS to be accurate
[18:21:48] <robsiemb> Phillip: That wording hasn't existed for 6+months
[18:22:59] <robsiemb> Barry: Specifically, we don't want children to prevent someone from implementing it?
[18:23:43] <robsiemb> Phillip: there are also those who do not want a proliferation of options
[18:24:02] <robsiemb> Pete: can we maybe overlap this with the CHILDREN extension (if you advertise both, then you always get children or something)
[18:26:34] <robsiemb> Decision to make CHILDREN integral....
[18:26:48] <robsiemb> Phillip: Given that, how is RECURSIVE different from CHILDREN?
[18:29:52] <robsiemb> So here we can say RECURSIVE with no selection criteria and it will effectively mean CHILDREN.
[18:30:47] <robsiemb> Here is an example of what we mean:
[18:30:56] <robsiemb> LIST (RECURSIVEMATCH) %
[18:31:02] <robsiemb> * LIST FOO (MATCH)
[18:31:06] <robsiemb> * LIST FIE (MATCH)
[18:31:12] <robsiemb> * LIST FUM (MATCH)
[18:32:04] <robsiemb> * LIST FOE ()
[18:32:45] <robsiemb> Lisa: here they may mean the same thing, but in other cases they provide nonredundent information.
[18:32:51] <robsiemb> Jutta: its an amusing IETF bar bet.
[18:34:16] <robsiemb> Phillip: If we don't get rid of CHILDREN altogether, then it doesn't matter.
[18:34:37] <robsiemb> Pete: We should deny recursivematch with no selection criteria. Phillip gets out the big BAD stick in his imap parser
[18:35:18] <robsiemb> Barry will summarize afterwards.
[18:35:59] <robsiemb> (a) Placeholder goes away
[18:36:04] <robsiemb> (b) each thing we can match on has a specific flag
[18:36:09] <robsiemb> (c) has children is the same
[18:36:15] <robsiemb> (d) has subfolders becomes has matching children
[18:36:50] <robsiemb> (e) we can drop hasnochildren since haschildren must be accurate if it is asked for
[18:37:18] <robsiemb> Lisa: what about LIST (RECURSIVEMATCH) * ?
[18:37:53] <robsiemb> Lisa: I suggest that we make RECURSIVEMATCH allowed only when there is a trailing %, and no selection criteria
[18:37:59] <robsiemb> Phillip: it is more complicated than that
[18:38:12] <robsiemb> Phillip: It might be "not containing a * and has a trailing %"
[18:38:29] <robsiemb> Lisa: "when the pattern indicates that you look at only 1 level of mailboxes"
[18:38:47] <robsiemb> Barry: wording is needed, but "it only works when it should work
[18:38:54] <robsiemb> We send BAD when it is wrong.
[18:39:10] <robsiemb> Note that this requires analyzing the pattern string
[18:41:45] <robsiemb> Lisa sumarizes her notes
[18:44:28] <robsiemb> Discussion on exactly what sorts of patterns we want to deny?
[18:44:37] <robsiemb> Losing network soon.
[18:45:07] <robsiemb> sorry all
[18:45:18] --- robsiemb has left: Disconnected
[18:45:25] --- resnick has left: Disconnected
[18:45:57] --- cyrus_daboo has left
[18:46:27] --- randy has left: Disconnected
[18:46:29] --- pguenther has left: Disconnected
[18:46:41] --- resnick has joined
[18:49:14] --- corby has joined
[18:49:51] --- corby has left
[18:50:00] --- smaes has left: Disconnected
[19:02:02] --- resnick has left: Disconnected
[19:17:55] --- tonyhansen has left: Disconnected