imapext@conference.ietf.jabber.com - 2002/11/21
[07:23] %% aamelnikov has arrived.
[07:23] %% aamelnikov has left.
[08:38] %% sjosefsson has left.
[09:20] %% rjs3 has arrived.
[09:20] %% rjs3 has left.
[13:07] %% TonyHansen has arrived.
[13:16] %% rjs3 has arrived.
[13:19] %% kmurchison has arrived.
[13:19] %% leg has arrived.
[13:21] %% resnick has arrived.
[13:21] %% mrose has arrived.
[13:23] %% TonyHansen has left.
[13:28] %% TonyHansen has arrived.
[13:34] %% barryleiba has arrived.
[13:36] %% leg has left.
[13:37] %% leg has arrived.
[13:37] * leg jabber jabber jabber
[13:37] <barryleiba> Showoff
[13:38] <leg> well, i'm a little concerned because i see "[15:36] leg has left" followed by "[15:29] leg has arrived"
[13:39] * leg smiles
[13:40] %% randy has arrived.
[13:41] * rjs3 throws leg across the room.
[13:41] * rjs3 smiles
[13:46] <leg> are we ever going to start?
[13:46] <rjs3> chair: welcome to imapext
[13:47] <rjs3> Agenda additions: i18n document. Search Extentions
[13:48] <rjs3> Actually, the agenda isn't online, so: Condstore ,Acl, Listext, Annotate[more], sort/thread, i18n, and search extentions
[13:49] <rjs3> chair: this group is being stalled for too long, so we need to get done what we need to get done, and punt what we need to punt.
[13:50] <rjs3> CondStore.
[13:50] * rjs3 has changed the subject to: IMAPEXT - condstore
[13:51] <kmurchison>
[13:51] %% resnick has left.
[13:51] <rjs3> alexey: As far as I'm concerned its done, with only minor issues. Last document was published in july.
[13:51] %% randy has left.
[13:51] %% resnick has arrived.
[13:51] %% resnick has left.
[13:51] %% randy has arrived.
[13:51] <rjs3> Open issues: Suggestion about adding shared flag response.
[13:51] %% randy has left.
[13:52] %% resnick has arrived.
[13:52] %% resnick has left.
[13:52] <rjs3> (as an untagged response to select)
[13:52] %% NedFreed has arrived.
[13:52] %% NedFreed has left.
[13:52] <rjs3> cyrus: what flags will this apply to? Is it tied to acl?
[13:52] <rjs3> alexey: all flags stored on server stored between users.
[13:52] %% NedFreed has arrived.
[13:52] %% NedFreed has left.
[13:53] %% randy has arrived.
[13:53] <rjs3> mark: This is a server policy not changeable by client, yes? A: yes.
[13:53] %% randy has left.
[13:54] %% resnick has arrived.
[13:54] %% resnick has left.
[13:54] <rjs3> alexey: another minor issue: What kind of notification sequence should be returned if another session modifies a flag with or without condstore?
[13:54] <rjs3> chair: make a choice.
[13:55] <rjs3> alexey: I expect to last call this soon.
[13:55] <rjs3> (after one more ID)
[13:55] * rjs3 has changed the subject to: IMAPEXT - ACL
[13:55] <rjs3> ACL.
[13:56] <rjs3> alexey: 10 open issues.
[13:57] %% NedFreed has arrived.
[13:57] <rjs3> a: missing section with prior RFC. I have text.
[13:57] <leg> missing section on compatibility with previous acl rfc
[13:58] <rjs3> a: I also added a feature to do multiple mailboxes in one command:
[13:58] <rjs3> larry: I feel this is unnecessary because it can be done with pipelining.
[13:59] <rjs3> larry: We also currently don't have a medium for dealing with partial failures, and I'm not sure we want to introduce it.
[13:59] <rjs3> chair: we'll go forward with whatever alexey decides, and then see if people scream on the list.
[14:00] %% resnick has arrived.
[14:00] %% randy has arrived.
[14:00] <rjs3> chris: I'm very concerned that we're allowing different ACL models, and I know webdav tried to move forward with a similar system that got punted by the IESG. I would like AD approval.
[14:00] <rjs3> s/approval/opinion/
[14:03] <rjs3> ned: Webdav has a very complicated document overall. I don't think the IMAP ACL mechanism even comes close, but there is potential for problems if it has gotten overly complicated.
[14:05] <rjs3> mark: Let's not put an implementor with a legacy mailstore a way to reasonably implement acl and be compliant. I suspect many of these can be resolved with examples.
[14:07] <rjs3> chair: suggests getting the security area to look at the draft now. Ned agrees.
[14:09] <rjs3> mark: I just want to be sure that the mandatory minimum is possible with a unix filesystem semantics, and we not raise the bar above that. I think the current draft is there, but I'd like more examples (I'll help with them).
[14:12] <rjs3> larry: its okay to have an extention not implementable on all servers. It is necessary for all clients to know how a server will react to all commands from a security standpoint. Currently we are using an IANA registry for this, but the clients will need to keep up, and we need to be sure about that.
[14:12] %% leg has left.
[14:12] %% leg has arrived.
[14:13] <leg> what crap
[14:14] <rjs3> I just wanted to point out similarities between this and when we implemented UID, and we went ahead with it anyway. This might be how we go ahead with ACL.
[14:14] <rjs3> chair: moving on.
[14:15] <rjs3> cyrus: It might be nice to have a table of commands and rights.
[14:16] <rjs3> alexey: Tied rights.
[14:16] <rjs3> a: currently the model requires that clients do a listrights before setting an ACL. I suggest we just return NO to an ACL set with a listrights response code.
[14:17] <rjs3> [this is okay with everyone]
[14:17] * rjs3 has changed the subject to: IMAPEXT - LISTEXT
[14:17] <rjs3> LISTEXT.
[14:18] <rjs3> barry: 2 issues: capabilities. They should be listed in the CAPABILITIES command, not later discovered by the client. I missed the second one.
[14:19] <leg> second one is extensible attribute value pairs at the end of the response
[14:19] <rjs3> Ah, yes.
[14:19] %% john loughney has arrived.
[14:19] <rjs3> b: should there be a listext verb that returns annotations?
[14:19] <rjs3> (same issue with ACLs)
[14:20] <rjs3> mark: I would prefer that all such things happen through listext and the other versions become depricated.
[14:20] <rjs3> b: this will create a document dependency.
[14:21] <rjs3> b: I will have a new draft out next week.
[14:21] <rjs3> chair: is this okay with ACL and annotatemore editors?
[14:22] <rjs3> cyrus: annotatemore is going to require a GETANNOTATION command for /server annotations anyway
[14:22] <rjs3> alexey: I'm fine using listext for ACL
[14:22] <rjs3> chair: so is there any problem with the duplication of functionality in GETANNOTATION?
[14:23] <rjs3> larry: can I currently get STATUS information from listext?
[14:23] <rjs3> b: yes.
[14:23] %% john loughney has left.
[14:24] <rjs3> larry: we need to be really careful and be sure that this format is extensible so that so that any per-mailbox information can be returned through LIST.
[14:24] <rjs3> chair: I suspect that annotatemore should allow both, with the assumption that we will deprecate one some time down the road.
[14:26] <rjs3> some discussion on what documents should depend on what... and we decide to wait to see where listext is before we decide who depends on who (expecting that annotatemore and acl will depend on listext, and not the other way around)
[14:26] <rjs3> hum of consensus for that proposal.
[14:26] * rjs3 has changed the subject to: IMAPEXT - ANNOTATE[MORE]
[14:27] <rjs3> Quick summary of issues on a slide.
[14:27] <rjs3> cyrus: Flags: How to deal with system flags, keywords, and vendor flags.
[14:27] <rjs3> cyrus system flags \XXX for base spec flags
[14:27] <rjs3> - create IANA registry for $XXX flags
[14:28] <rjs3> - vendor flags are anything else, which require a vendor name registered in the ACAP registry
[14:28] <rjs3> - /message/flag/<<SYSTEM FLAG>>
[14:28] <rjs3> - /message/flag/vendor/vendor.XXX
[14:29] <rjs3> well, - /message/flag/vendor/<<vendorflag>>.<<flagname>>
[14:29] <rjs3> where <<vendorflag>> is the IANA registered vendor name
[14:30] <rjs3> mark: the vendor namespace doesn't make sense if I am using my own flags as a user.
[14:33] <rjs3> (discussion about the existence of user specified flags in the base spec)
[14:34] <rjs3> cyrus: we should just define a new symbol to carve off the vendor namespace
[14:34] <rjs3> (like \ in the system flags or $ in the keywords)
[14:35] <rjs3> ??: we should just define an annotation that contains all user flags as its values
[14:36] <rjs3> chris: we should move on, since we know what the issues are (vendor isn't a great name as a namespace0
[14:36] <rjs3> cyrus: okay, moving on.
[14:37] <rjs3> cyrus: removing dependency on sort, which will have i18n issues
[14:37] <rjs3> cyrus: Sort would add this functionality back in.
[14:38] <randy> User-named flags should be the *value* of an annotation, not the name; then we avoid a requirement that the flag *names* be internationalizable
[14:38] <rjs3> cyrus: switch to using /message/envelope containing 2821 MAIL FROM/RCPT TO stream. Also amending security considerations
[14:39] <rjs3> cyrus: also add a sieve-actions annotations. this brings up what entries should be in the base spec and what should be separate documents.
[14:39] <randy> (Jabber is really slow right now [16:30:02])
[14:39] %% rlbob has arrived.
[14:40] <rjs3> chair: right now to have an annotation we need an RFC, but we're changing that to just require expert review
[14:40] <rjs3> ned: this sounds fine
[14:40] <rjs3> pete: I suggest that we just remove as many as possible.
[14:40] <rjs3> cyrus: I'll send to the list which should be which.
[14:41] <rjs3> chair: we look good.
[14:41] <rjs3> Annotatemore.
[14:42] <rjs3> cyrus: includes issues with interaction with listext, holding on listext.
[14:42] <rjs3> also i18n (wait on stringprep draft), fix some examples.
[14:42] <rjs3> barry: Should we say something about private vs shared in the server hierarchy.
[14:44] <rjs3> cyrus: Its difficult because we lack acls in /server. I was thinking that they were generally shared.
[14:44] <rjs3> barry: I think we just need to make a decision.
[14:45] <rjs3> cyrus: we might want a /user annotation top level, but that is definitely another document.
[14:45] <rjs3> barry: question about unsolicited ANNOTATION responses
[14:45] <rjs3> barry: server annotations should be sent, and annotations for selected mailbox should be sent, but nothing else
[14:46] <rjs3> cyrus: seems reasonable.
[14:46] <rjs3> chair: moving on.
[14:46] * rjs3 has changed the subject to: IMAPEXT - SORT/THREAD
[14:46] <rjs3> mark: they're being held up by the specification of a mandatory minimum to implement i18n solution
[14:47] <rjs3> specifically coallation.
[14:48] <rjs3> john ??: Everything is in stringprep except for thing that require you to know stuff like language before you get started.
[14:49] <rjs3> chris: Randy and I volunteered to write up a i18n spec for imap that everything could reference at once, and just move everything forward.
[14:49] * rjs3 has changed the subject to: IMAPEXT - SORT/THREAD + i18n
[14:51] <rjs3> mark: I am nervous about making it harder/more confusing for implementations to comply.
[14:51] <rjs3> mark: I fear that we'll see binary compare last much longer than we should.
[14:52] <rjs3> chair: as long as we provide a collation parameter, we're okay, and market forces will either force compliance or not
[14:53] <rjs3> mark: perhaps we should document binary compare. (also propose combining sort and thread)
[14:54] <rjs3> larry: the obvious place for choosing the collation mechanism is the ACAP comparitor registry. i can't think of a good way to allow SORT/THREAD to go forward without a mandatory to implement comparator and a way of choosing comparator.
[14:54] <rjs3> chris: The default needs to be binary compare (required for back wards compatibility) [well ascii casemap]
[14:55] <rjs3> chris: however the comparator that will be mandatory to implement will be based on a profile of stringprep
[14:55] <rjs3> chris: my opinion about sort is to stringprep everything and run a binary compare on the outputs.
[14:55] %% kmurchison has left.
[14:56] <rjs3> chair: the open question that I will pass to the IESG: will we get pushback about not referring to the default unicode collation sequence.
[14:56] <rjs3> ned: I don't think this is a problem.
[14:56] <rjs3> chair: good then all we need is a stringprep profile.
[14:57] <rjs3> mark: I am concerned for the sake of interoperability about declaring things that exist today to be broken ex-post-facto.
[14:58] <rjs3> mark: I can see how people outside the US might find this inadequate, but it is important to me to maintain backwards compatibility.
[14:59] <rjs3> chris: my proposal was that we keep the current default behavior as the default behavior, but new implementations will be required to advertise/implement the compliant behavior.
[15:00] <rjs3> mark: I want to avoid the public relations nightmare of the difference between noncompliant and not yet implemented.
[15:00] <randy> Did the blue sheet get passed around?
[15:00] <rjs3> chris: we'll try that, but if it doesn't work we'll be more restrictive.
[15:00] <rjs3> [I haven't seen it]
[15:00] <rjs3> ned: I have no idea how this will go.
[15:02] <rjs3> cyrus: should this affect mailbox names as well?
[15:02] <rjs3> larry: no, since we already have a method of doing this even if it's not perfect.
[15:03] <rjs3> chair: so yes, this will limit itself to sort search and thread.
[15:03] <rjs3> chris: I know there was a LANG extention floating around for a while, but I think we should look into that as well.
[15:03] <rjs3> chair: my gut is that I'll leave it to the document editors to figure out what the right way to go is.
[15:04] <rjs3> cyrus: I'd like to avoid the client having to issue multiple commands on startup to set all these options.
[15:04] <rjs3> mark: I agree with cyrus, we only want to set this once and have a clear understanding of what is done if we do not send it.
[15:05] <rjs3> cyrus: conceivably we could have an annotatemore annotation that takes care of all of this in a persistent way.
[15:05] <rjs3> (it could even be per mailbox)
[15:06] <rjs3> mark: So, when we are dealing with the strings, there is a final step that says "run stringprep on it" after the "convert to utf8" step.
[15:06] <rjs3> mark: And then, in the issue of comparison, we will have a document that is normative to sort and thread to take care of that.
[15:07] <rjs3> chair: clarification "convert to unicode" then "run stringprep" and if you are doing a binary compare you then need to convert to utf8.
[15:08] <rjs3> mark: others have suggested other threading algorithms, and my feeling is that the current sort and thread document is already way too complicated and if we want additional sort/thread methods that should be a subsequent document.
[15:09] <rjs3> chair: that's your choice if its a subsequent document and/or an IANA registry.
[15:10] <rjs3> chris: I add the caveat that sort on annotations that's a capability if you advertise both sort and annotate.
[15:11] <rjs3> mark: I'd rather it in annotate, but I don't care that much.
[15:11] <rjs3> cyrus: yeah, we were only removing it from annotate to speed annotate.
[15:12] <rjs3> general consensus to leave sort for annotations in annotatemore and let it sit in the queue.
[15:12] <rjs3> chair: and it's up to mark if we combine sort/thread.
[15:12] <rjs3> search ext.
[15:12] * rjs3 has changed the subject to: IMAPEXT - SEARCH EXT
[15:13] <rjs3> Barry: some while ago I started a multi folder search draft.
[15:13] <rjs3> b: and recent interest has made me want to restart that.
[15:13] <rjs3> b: This morning at lemonade made me realize that I wanted to add a multiple groups of search criteria option, and a count parameter
[15:14] <rjs3> b: so you could then ask "for these folders do these searches and give back just the number of hits"
[15:14] <rjs3> b: this is related to status counters.
[15:15] <randy> But the idea behind status counts is that the server keeps the counts so it doesn't have to search
[15:15] %% mrose has left.
[15:16] <rjs3> b: in this case search would become the primary definition of this method and status counters would be a fast way of getting these same counts.
[15:17] %% tbamonti has arrived.
[15:17] <rjs3> mark: but status is supposed to be fast, while this method sounds comparatively slow. Maybe we don't care, since obviously some implementations don't. Also would you be interested in adding SCAN to searchext?
[15:17] %% tbamonti has left.
[15:17] <rjs3> where "move scan" == move that functionality
[15:18] <rjs3> barry: Yes, I agree, clients will do what they need to do. Note that the draft noted that the server may refuse "*" as the folder specification.
[15:19] <rjs3> chair: so there is some interest and you know what you needto move forward.
[15:20] <rjs3> chris: reminder to editors about the nitpicky things that IESG looks for, it's on the ietf internet-drafts webpage.
[15:21] <rjs3> chair: I have volunteered to do this for the working group, but it helps that the editors do a first pass.
[15:22] <rjs3> cyrus: do we need to amend our charter?
[15:22] <rjs3> chair: yes, the charter is out of sync, but after the next set of drafts comes out I'll be able to know what will get done and I'll suggest a new charter and send it to the list.
[15:22] <rjs3> chair: basic idea is that VIEW dissapears and i18n and listext get added.
[15:23] <rjs3> mark: how much interest do we continue to have in SORT.
[15:23] <rjs3> cyrus: my users definitely still care.
[15:23] <rjs3> cyrus: also sorting by size is generally useful.
[15:24] <rjs3> chair: there is clearly IMAP related stuff going on in LEMONADE, and we should watch for it.
[15:25] <rjs3> (brief summary of lemonade)
[15:26] <rjs3> rob: I know lyndon was interested in moving channel to imapext, but since lemonade has picked it up we should leave it there.
[15:26] <rjs3> chair: yes, especially given the state of our charter.
[15:26] %% barryleiba has left.
[15:27] %% resnick has left.
[15:29] %% leg has left.
[15:33] %% TonyHansen has left.
[15:38] %% NedFreed has left.
[15:41] %% rjs3 has left.
[15:49] %% rlbob has left.
[15:49] %% randy has left.
[17:15] %% TonyHansen has arrived.
[17:15] %% TonyHansen has left.
[18:49] %% rlbob has arrived.
[18:50] %% rlbob has left.