eai - Monday, 14 May 2012

eai

eai@jabber.ietf.org

Monday, 14 May 2012< ^ >

KIM Kyongsok has set the subject to: EAI @ IETF 82

Room Configuration

GMT+0
[08:43:32] fujiwara joins the room
[10:22:34] Jacky Yao11 (Health Yao) joins the room
[10:24:24] Jacky Yao11 (Health Yao) has set the subject to: EAI Interim Meeting
[11:43:46] JOUGASHIMA joins the room
[11:44:16] JOUGASHIMA is now known as Martin Dürst
[11:49:15] Klensin joins the room
[11:50:17] john.levine joins the room
[11:50:42] <Klensin> Hi everyone. For those who are not doing anything with the next 10 minutes than waiting, note that I just sent an email msg to the list that might be helpful (or not -- still trying to see if we can reach enough consensus to move on)
[11:51:48] <Jacky Yao11 (Health Yao)> yes, I have received it
[11:51:59] <Jacky Yao11 (Health Yao)> nice summary
[11:52:16] <Klensin> Thanks. We shall see what others think
[11:52:28] josephyee joins the room
[11:53:12] arnt joins the room
[11:53:25] <arnt> hi.
[11:53:33] Barry Leiba joins the room
[11:53:40] <josephyee> hello everyone
[11:53:45] <Barry Leiba> Hola
[11:54:26] <Martin Dürst> Good evening everybody :-)
[11:55:53] <Klensin> Is "good gray, wet, early morning" an appropriate response? :-)
[11:55:58] <fujiwara> Good evening
[11:56:31] <Jacky Yao11 (Health Yao)> good night
[11:56:41] <Jacky Yao11 (Health Yao)> :-)
[11:56:44] <Klensin> :-)
[11:57:23] <josephyee> (note to self: don't brag about the sunny weather in Toronto)
[11:57:41] <josephyee> :)
[11:57:43] <Barry Leiba> Well, we sent it up to you. Lovely here yesterday
[11:57:56] <john.levine> and we want it back now
[11:58:00] <Barry Leiba> ("here" being the northeast U.S.)
[11:58:09] <arnt> mumble.
[11:58:18] <Klensin> Barry: Yes, same here.
[11:58:37] <josephyee> few minutes to start, and I want to ask if everyone had a chance to read John Klensin's email sent 20 minutes ago?
[11:58:50] <Barry Leiba> (* reading now *)
[11:59:01] <arnt> a true klensingram can't be read in a twenty-minute sitting.
[11:59:16] <Barry Leiba> Oh, damn… it's John length!
[11:59:41] <Barry Leiba> We measure talking speed in EKRs… we should measure message length in JCKs.
[12:00:14] <Jacky Yao11 (Health Yao)> novel length
[12:00:28] <Klensin> Only because of the suggested text strategy in point 7. Look through the first six. The one-line summary of 7 is
[12:00:29] <josephyee> it's close to summary of recent discussion
[12:00:59] <Martin Dürst> Confirmation: I read the first six points of John's mail.
[12:01:09] <Klensin> "re-do some explicit text into the IMAP spec, reference it from POP, don't try to have the downgrade specs critique each other.
[12:01:38] <Jacky Yao11 (Health Yao)> I read 6 and 7.2 and 7.3
[12:01:41] <Klensin> @joseph: that is basically what I was trying to do with 1-6
[12:02:15] <john.levine> actually, it all seems pretty reasonable
[12:02:15] <arnt> what'll we do today — take each of the klensingram points in order, with an issue fifo in case more issues appear during the meeting?
[12:02:17] <Klensin> And 7 may be irrelevant if we can't get to near consensus on the issues in 1-6
[12:02:50] <Barry Leiba> Meta question:
[12:02:57] <josephyee> @jck, yes, and 7 is about how to deal with 'editing' in certain extent
[12:03:12] <Klensin> @arnt: I'd prefer to start, per Joseph's outline/agenda by doing a quick review to see if there are issues I didn't catch.
[12:03:13] <Barry Leiba> Should POP and IMAP "update" (in the metadata sense) the main POP and IMAP RFCs?
[12:03:16] <Jacky Yao11 (Health Yao)> I am not clear about why "> 7.3 All other text about downgrading should be removed from the
> IMAP spec.
>
> 7.4 All text about downgrading should be removed from the POP
> spec and a reference to the above substituted.
>
"
[12:03:23] <josephyee> @jck: agreed about comment of 1-6 consensus
[12:04:36] <josephyee> to all: although we are 3 minutes into meeting, I haven't call start yet because I want to see where Pete is
[12:04:52] <Jacky Yao11 (Health Yao)> josephyee: jck's 1-6 sometimes uses question sentence
[12:05:00] <arnt> fine with me. joseph, are you going to beat people over the head when they start digressing and/or flaming me?
[12:06:05] <Klensin> @Barry: Pro: They add commands, so yes. Con: Both of the base specs were designed for extensions and extensions don't change those specs any more than SMTP extensions change 5321. IMO, this is really a cross-IETF meta-issue about which the IESG and/or RFC Editor should say something definitive. As WG co-chair, I really want to say "you IESG folks make up your minds and do whatever you think best because the WG doesn't have any basis for a substantive opinion".
[12:06:54] <Barry Leiba> I raise the question because this in particular is something we want to highlight, and which will eventually cause interoperability issues between the haves and have nots when there's broad deployment.
[12:06:57] <josephyee> @arnt: if it becomes personal, yes. And I believed that we all are adult here that we focus on the issues
[12:07:12] <Klensin> @Arnt: The division of responsibility here is that Joseph runs meetings and determines consensus and I beat people over the head :-). Seriously, I hope we can keep flaming to a minimum and make progress instead.
[12:07:26] <arnt> barry: IMO, if a downgrade document updates the spec, it's wrong. a downgrade document exists to cater to unextended clients, so any spec update is a sign of some bug.
[12:07:29] <Barry Leiba> Sort of like rolling TOP into POP, because even though it's an "extension", good luck if you don't support it.
[12:07:55] <Klensin> @joseph: it is 7 minutes after that hour -- want to officially start?
[12:07:56] <Barry Leiba> Arnt, I didn't mention downgrade.
[12:08:21] <arnt> oh, right. sorry. I confused distinct things as they scrolled by.
[12:08:29] <Barry Leiba> Problem with jabber.
[12:08:36] <Barry Leiba> I wish we were doing this by voice. Sigh.
[12:08:44] <josephyee> @ALL: Let's start meeting, we have Barry with us, at least we have 1 AD
[12:08:46] <Klensin> @Barry, yes, but what should be done with TOP is probably an A/S that says "mandatory to implement (at least SHOULD)". And _it_ updates POP because it changes the conformance spec.
[12:09:25] <josephyee> First: Agenda
[12:09:33] <josephyee> Any issues from anyone?
[12:09:57] <Barry Leiba> Just the "updates" question that I'd like more discussion on if there's time.
[12:10:03] <Barry Leiba> But only if there's time.
[12:10:23] <Klensin> Yes. Can we please get finished, get these docs submitted, and move on? We can quibble forever, but I don't think anyone really wants that.
[12:10:51] <josephyee> 1 Agenda Bash
2 POP/IMAP Cluster
Discussion of the following drafts. A _short_ WG Last Call will
be initiated either immediately after the meeting or immediately
after new versions can be posted if the latter is necessary:
draft-ietf-eai-5738bis-03 (IMAP)
draft-ietf-eai-rfc5721bis-04 (POP)
draft-ietf-eai-popimap-downgrade-05
draft-ietf-eai-simpledowngrade-03
3 Other drafts
Discussion of status and plans for mailing lists and MAILTO.
4 AOB
[12:11:16] <josephyee> I believed that no one has issues to the agenda
[12:11:35] <josephyee> So let's talk about draft-ietf-eai-5738bis-03 (IMAP)
[12:11:52] <Klensin> Pls put the "updates" issue in front of "3 Other..." because if affects this set of docs.
[12:11:58] <josephyee> And since Barry started the "update"
[12:12:34] <josephyee> Ok, so let's start with "updates" in general
[12:12:43] <Klensin> Per my note, the only issues I know about with IMAP are the UTF-8 parameter and the LANG question.
[12:13:12] <Barry Leiba> UTF-8 param: I think you support UTF-8 or you don't.
[12:13:29] <Barry Leiba> I'd rather not add complexity to allow for partial implementations.
[12:13:45] <Klensin> @joseph: let's not. The updates question doesn't change the docs at all (plus or minus an obligatory sentence), so let's push it toward the end.
[12:13:57] <josephyee> @jck: ok
[12:14:22] <josephyee> @ALL: anyone has thought on LANG?
[12:14:36] <Barry Leiba> I think we should say that the lang list is in no specified order.
[12:15:12] <Klensin> @Barry: (personal opinion) Agree. Both or neither. But, remembering what we went through with the MAIL parameter in the SMTP spec, I wonder whether getting rid of the parameter (vs routinely requiring it) is a good idea?
[12:15:58] <Klensin> @Barry: I.e., if a language appears on the list, the server can pick whatever is convenient?
[12:16:04] <Martin Dürst> When I read the IMAP draft, I found I was confused about where it was talking about general ability, where about folders, and where about messages, and why. So reducing the number of options should help make this easier to understand.
[12:16:13] sean.s.shen joins the room
[12:16:33] <Martin Dürst> I have to admit I didn't see the LANG thing, otherwise I'd most possibly have an opinion.
[12:16:50] <Martin Dürst> Often, languages are given in order of preference.
[12:16:55] <Klensin> @Martin: agree (and I believe that lower complexity is almost always good). But some of that clutter is an intrinsic property of IMAP.
[12:17:24] <Martin Dürst> But that still means that the server can pick whatever it wants, because it can preted it doesn't know the others.
[12:17:26] <arnt> there's a LANG command in IMAP. an extension authored by myself and supported only by ned iirc. pointless thing. but if it's there I'd say that by default, pop ought to match that extension.
[12:17:43] <arnt> authored by chris newman and myself, actually.
[12:17:46] <Martin Dürst> And the client can try with another language if it prefers that and thinks the server knows it.
[12:18:27] <Barry Leiba> Martin, I don't see how those comments apply to this situation.
[12:18:46] <Barry Leiba> The server has no "preferred" language. Only a default, which it will then change at client request.
[12:18:47] <Martin Dürst> @john: Thanks for confirming that some of that is intrinsic to IMAP. I wasn't familliar enough with IMAP to judge that.
[12:18:54] <Klensin> @Martin: yes, but we need to be a little careful -- we've sort of got a scale of negotiation capabilities with HTTP, IMAP, POP, SMTP in declining order.
[12:19:03] <arnt> only small aprts of it are intrinsic to imap.
[12:19:05] <arnt> IMO.
[12:19:16] <arnt> I've implemented >50% of eai-imap now, btw.
[12:19:24] <josephyee> @ALL: the issus is whether some of ordering expected from the list of language return to client and document it if so
[12:19:44] <Barry Leiba> I suggest documenting that the list is in no specified order.
[12:20:33] <Barry Leiba> I do find it odd that "default" is actually returned as part of the list.
[12:20:33] <Martin Dürst> Ah, it's the list of languages that the server sends to the client? For the server, having order makes a lot less sense.
[12:20:39] <Klensin> @Martin, Arnt: The "sometimes it is about global capability, sometimes about one or more folders, sometimes about messages"... "and you'd better match replies to commands carefully" bits certainly are
[12:20:44] <josephyee> @barry: (personal opinion) agreed, no specific order
[12:21:18] <arnt> RFC 5255 says that in IMAP, the first supported language is used. if we don't have a specific reason to do it differently im POP, I think the first specified language should be used there too.
[12:21:43] <arnt> RFC 5255 is that way so that the client can send a single command and get what it wants, with no negotiation. only the server needs logic.
[12:21:56] <josephyee> quoted from Muarry's review...
[12:21:58] <josephyee> 1) Section 2: When LANG is issued with no parameters, thus requesting a list of supported languages, is that list expected to be ordered in any way?
It doesn't really matter, but the document should probably say one way or the other. If a list order is specified by one of the referenced RFCs, I missed it.
[12:22:02] <Martin Dürst> Of course there could be a quality issue, translation for some languages being much better done than for others, but it's a rarer case, and if it's the server that offers languages and the client can choose, then the client can always start a new session if it thinks the translation is crappy.
[12:22:15] <Martin Dürst> So agree with not giving meaning to order of languages.
[12:22:39] <arnt> oh. I agree too.
[12:22:44] <Klensin> Ok. Anyone want to make a strong case for a specific order?
[12:22:58] <Martin Dürst> BTW, HTTP is the other way round, the client sends a list, and the server sends a document in a single language.
[12:23:08] <Klensin> And do we want to spend time on "default", or just let it go.
[12:23:15] <Barry Leiba> Let it go.
[12:23:17] <arnt> let it go.
[12:23:23] <Martin Dürst> Agree, let it go.
[12:24:02] <josephyee> @ALL: anyone disagreed for letting it go?
[12:24:13] <josephyee> going once, going twice....
[12:24:31] <sean.s.shen> agree
[12:24:44] <josephyee> default will be gone
[12:25:06] <josephyee> UTF-8 param
[12:25:20] <Klensin> Did we finish with the UTF-8 parameter? I think we have agreement on "no partial implementations" but not sure about whether the parameter goes out.
[12:25:24] <josephyee> oh, saying one more time for LANG: no specific order
[12:25:59] <Martin Dürst> I hope "no partial implementations" means "no unnecessary parameters".
[12:26:36] <Barry Leiba> If the UTF-8 param on SEL/EX leaves, how does the client say "use UTF-8"?
[12:26:46] <arnt> ENABLE UTF8=ACCEPT
[12:26:55] <Barry Leiba> Ah, right. Sorry.
[12:26:57] <Barry Leiba> Brain check.
[12:27:36] <Klensin> Just reread the text again, ENABLE... wfm
[12:27:37] <Barry Leiba> We had originally thought that some mailboxes might go one way, and some the other. But I can't imagine that to really be client-related — it would be on the server, if at all.
[12:27:46] <arnt> yeah
[12:27:47] <Barry Leiba> So ENABLE, and that's it.
[12:27:50] <arnt> \noutf8 is the same
[12:27:58] sean.s.shen leaves the room
[12:28:17] <josephyee> (personal) I think we started moving away from multiple modes, so it may be safe to let ENABLE handle it
[12:28:30] <Barry Leiba> Looks like consensus looms.....
[12:28:35] sean.s.shen joins the room
[12:28:42] <josephyee> (personal) but Alexey is not here
[12:28:42] <arnt> if SELECT ... UTF8 goes away, then \noutf8 has to go away too, AFAICT
[12:28:51] <josephyee> I wonder if he had different opinions
[12:29:08] <Klensin> I think so. The client is either capable or it isn't. If it wants to handle some messages or mailboxes differently, its problem, not ours.
[12:29:30] <arnt> klensin, elaborate?
[12:29:32] <Barry Leiba> да
[12:29:44] <josephyee> @arnt: shouldn't all flags can go away? because the flag make no sense to non EAI client
[12:30:42] <Barry Leiba> If the server says "this mailbox doesn't support UTF-8", that might help the client not try to, say, APPEND or COPY a UTF-8 message into it.
[12:31:04] <Barry Leiba> But I'm ambivalent about how useful that really is.
[12:31:07] <Klensin> Just agreeing that we are better off cleaning this up - ENABLE only, no UTF-8 or \noutf8. If the client wants particular things handled differently, that is its problem not a protocol one -- or it breaks them up into separate connections/sessions. And we don't need to talk about that in the spec.
[12:31:24] <arnt> barry, mark's server supports that, but AFAICT mark tells people not to use that functionality...
[12:31:33] <Barry Leiba> Arnt: ok
[12:31:54] <Barry Leiba> So, yes, let's just clean all this up, as jck says.
[12:32:11] <arnt> and suddenly the percentage of 5738bis I've implemented rises dramatically.
[12:32:21] <Barry Leiba> he-he-he
[12:32:30] <josephyee> @ALL: sounds like agreement....
[12:32:30] <Martin Dürst> @arnt: congratulations!
[12:32:45] <sean.s.shen> thank arnt
[12:33:02] <josephyee> (personal) it really makes implementation easier
[12:33:03] <Klensin> @Barry: the only situation where that would arise in practice would be if one server is supporting two mail stores with different capability -- with public mailboxes as possible exceptions, that is a _really_ odd case.
[12:33:27] <Barry Leiba> I really wish Алексеи were here, though.
[12:33:44] <Barry Leiba> JCK: I agree.
[12:34:22] <Barry Leiba> A server I ran at IBM might have done that… but it wasn't a production server.
[12:34:23] <Klensin> Barry, yes to Alexey. And Pete too. But they do get to disagree on-list if they like.
[12:35:35] <Barry Leiba> Are we done with 1 and 2?
[12:35:39] <josephyee> @ALL: I believed that we had consensus here, and will bring this back to list
[12:35:47] <Klensin> @Barry not hard to think about how to make a server do that. But I don't think we want to increase complexity by encouraging it. As with all of the rest of this, the "right" solution is "upgrade everything" -- we need to remember these issues are all transitional.
[12:35:59] <Barry Leiba> JCK: d'accord.
[12:36:40] <Klensin> Ok, Joseph... are we done with IMAP, pending recycling on list?
[12:36:43] <josephyee> for the record:
[12:36:45] <josephyee> UTF8 param
- enable taking care all
- no /UTF8 and /noUTF8 @ LIST & SELECT
[12:36:54] resnick joins the room
[12:36:56] <josephyee> And pending to mailing list
[12:37:05] <Barry Leiba> Here's Pete!
[12:37:20] <Klensin> Good morning Pete.
[12:37:22] <josephyee> morning Pete
[12:37:23] resnick sheepishly enters the room after oversleeping. :-[
[12:37:50] <Jacky Yao11 (Health Yao)> welcome pete
[12:37:55] <Martin Dürst> Pete, you're excused, your the one most westwards, yes?
[12:37:56] <Barry Leiba> Well, it *is* an hour earlier for you.
[12:38:11] <resnick> Not even westward. It's only 7:30am.
[12:38:16] <resnick> Just stayed up too late.
[12:38:19] <Klensin> We just finished IMAP. If we slow down now, you might get sent back to sleep :-)
[12:38:26] <Barry Leiba> On (3) and (4), I say "no" to both.
[12:38:29] <josephyee> quick recap:
[12:38:34] <Martin Dürst> I'm sending regrets in advance just in case I fall asleep prematurely, I might be most eastwards.
[12:38:35] <josephyee> IMAP LANG list ordering
-- no specific order
-- default gone
UTF8 param
- enable taking care all
- no /UTF8 and /noUTF8 @ LIST & SELECT
[12:38:36] <arnt> joseph, please bang down teh digression and let's move on, please.
[12:38:43] <Barry Leiba> I want "updates" for the POP and IMAP specs, but NOT for the downgrade ones.
[12:39:03] <josephyee> (3) Do weintend to allow a critique of popimap-downgrade (or
other approaches) in simple=downgrade or vice versa?
[12:39:40] <john.levine> (3) Assuming there is some evidence that there are people who plan to implement them, just publish them as informational.
[12:39:52] <Martin Dürst> I think the downgrade documents should just say what they do. They may talk about where that's a good idea, but not more.
[12:39:53] <Barry Leiba> I think (3) is related to (6). I think they should both be Informational, and neither should address the other, apart from saying that these are different approaches.
[12:39:55] <Klensin> @Barry: Put on your AD hat and say that and you can consider it done (see earlier note). But expect the Shepherd's report to say "Barry told us to". I really don't want another long argument on the subject.
[12:39:56] <john.levine> (3) If we can't find people who plan to implement one or the other, don't bother.
[12:41:03] <Klensin> (sorry, that was about "updates" -- I'm somewhat agnostic on maturity level other than having some Charter worries)
[12:41:16] <arnt> as draft editor: if we "allow" one downgrade to critique the other, then I'd like someone to supply the text for "my" document, because that's not the kind of thing I do well. as WG member: I don't have an opinion. I'd prefer no, but maybe that's just my aversion to writing the text speaking.
[12:41:44] <Barry Leiba> Charter: if the WG sends them to IESG as Info, says the WG thought that was best, the IESG won't yell "But CHARTER says!" in response.
[12:42:00] <Jacky Yao11 (Health Yao)> I think that (3) information is ok, but Experimental may not be ok.
[12:42:30] <Barry Leiba> Arnt: don't worry… consensus appears to be going for "not critique".
[12:42:45] <josephyee> @ALL: (3) is about critiique, leave the draft type to (6)
[12:43:22] <josephyee> @ALL: for (3), any disagreement for "no critique"?
[12:43:41] <josephyee> silence...........
[12:43:51] <josephyee> no critique for (3)
[12:43:56] <arnt> ok assuming we get something like the textjck suggested
[12:44:06] <arnt> into the imap document
[12:44:25] <josephyee> @arnt: we will discuss that at (7)
[12:44:28] <arnt> y
[12:44:34] <josephyee> 4) popimap-downgrade: Does this update 5322?
[12:44:38] <Barry Leiba> no
[12:44:47] <resnick> +1: no
[12:44:54] <Klensin> (personal) I really question "Informational". They are protocol specs regardless of what we call them. There aren't any "known [technical] defects" in terms of quesitons about implementability for either. And they are WG products, produced with the intent of standardization. That description meets all of the requirements for Proposed Standard. If no one implements, that is ground for not advancing a level and maybe for an eventual A/S that says "forget it, Historic". But "informational" really leaves everything up in the air and provides little information.
[12:44:55] <Barry Leiba> I would not like to see the downgrade docs "update" anything.
[12:44:55] <josephyee> (personal) we have consensus on this before
[12:44:55] <arnt> IMO ti does, by disallowing downgraded-* in all messages
[12:45:01] <resnick> Anyone want to explain why it would?
[12:45:27] <josephyee> don't we agree to empty group for TO and CC?
[12:45:48] <fujiwara> I dislike to update 5322.
[12:45:48] <arnt> but I think that's inappropriate. it shouldn't do that. instead it should say what to do when someone does hand it a message full of prefabricated downgraded-*
[12:46:01] <john.levine> I'd make them informational because they have little if any effect on interoperation.
[12:46:14] <john.levine> It's just user interface, about which we are well known to be clueless.
[12:46:19] <Barry Leiba> Doc status is (6), and we're on (4) now.
[12:46:20] <josephyee> @fujiwara: dislike because of technical or foreseeing toughness in "passing" the draft?
[12:46:39] <resnick> @jck: I tend to agree. I'll go back and reread the transcript.
[12:46:46] <fujiwara> hmm. recent clients do not know updated 5322 specs.
[12:46:59] <arnt> I agree with fujiwara. tails should not wag dogs.
[12:47:13] <Klensin> @JohnL They have exactly no more impact on interoperation than IMAP and POP do. The client and user need to know what to expect/ do if one of these shows up. Yes, that is partially a matter of private agreements between client and server in the same
[12:47:23] <Klensin> presumed administrative domain, but so are IMAP and POP.
[12:47:30] <john.levine> re downgraded-*, MUAs already have issues with invalid messages, e.g. multiple subject lines, nothing new there
[12:47:58] <Barry Leiba> JCK: No, no… the downgrade docs are for talking to a client that does NOT support the protocol.
[12:48:12] <Barry Leiba> So they're not about protocol. They're about coping with old clients.
[12:48:49] <arnt> john, no... 5322 already says so-and-so is invalid, such as double subject. what I'm saying is that it's bad for downgrade to extend the list. I'm not saying that a nonempty list is bad.
[12:48:54] <Barry Leiba> But we're on (4). On (4): what's the argument for "updates" 5322?
[12:49:25] <josephyee> @Barry: it's server passing the downgraded mesage, not client reformat the message for display
[12:49:26] <arnt> barry, the argument is that popimap-downgrade defines new headers, Downgrade-*, and that its definition applies to everyone.
[12:49:42] <Barry Leiba> Arnt: that should be an IANA registry issue.
[12:50:03] <arnt> good point.
[12:50:10] <Klensin> @Arnt: But that isn't an update to 5322 because 5322 explicitly allows for arbitrary extension headers -- expecially after the xdash doc was approved.
[12:50:12] <john.levine> Lots of RFCs define new mail headers and haven't updated 5322, e.g. DKIM.
[12:50:24] <resnick> @Barry: It would update if it started to allow things that 5322 forbids.
[12:50:32] <Barry Leiba> PR: yes
[12:50:44] <Martin Dürst> Re. informational vs. standards track, I think the message we send is something like "here are the two ways the WG came up with, but there may be others" (for informational) and "these are the two best ways, use one or the other (if you have to downgrade)" (for standards track)
[12:51:02] <Barry Leiba> Martin: we're not discussing that yet.
[12:51:20] <Barry Leiba> Very hard to stay on track on jabber. Sigh.
[12:51:22] <Klensin> IMO, If there is an argument for "updates 5322" it lies, narrowly, in the logically empty To/Cc fields. And the group syntax solves that problem, so no non-conformace there either as far as I can tell.
[12:51:38] <Barry Leiba> jck: I agree
[12:52:08] <john.levine> @jck: agreed. Since this is entirely about supporting old existing software, it'd be pretty counterproductive to define new rules.
[12:52:50] <fujiwara> downgraded messages must be traditional 5322 messages.
[12:53:42] <josephyee> there are enough "undisclosed-recipient:;" message that hardly traditional
[12:53:53] <Klensin> Put differently, I think my test for "updates" in this case is whether 5322's conformance rules change, either by adding requirements or by permitting what is now prohibited.. They don't, as far as I can tell, with the possible other exception of group syntax in "From:"... and that strikes me as almost trivial.
[12:54:28] <Martin Dürst> Agree that ↓downgrade specs shouldn't ↑upgrade. It's a totally different direction.
[12:54:36] <Barry Leiba> And we should call out the "from" issue specifically as a deviation, not as an update.
[12:55:23] <Klensin> @barry: yes, "[necessary] deviation" seems exactly right. If we can agree on that (no "updates") I'll take the token to recommend text.
[12:56:14] <Barry Leiba> kewl
[12:56:19] <Klensin> So we have the POP and IMAP docs updating their base specs but the downgrade docs not updating anything, right?
[12:56:38] <Barry Leiba> да
[12:56:46] alexey.melnikov joins the room
[12:56:48] resnick cringes and re-looks at the jabber log
[12:56:49] <josephyee> @ALL: from observation, no one disagree from empty group syntax but not so sure that the draft updates RFC5322
[12:56:55] <Barry Leiba> Alexey, HI
[12:57:05] <alexey.melnikov> Sorry, lost track of time :-(
[12:57:34] <Jacky Yao11 (Health Yao)> it is not too late
[12:57:36] <josephyee> @ALL: and seems like taking it as deviation works for both
[12:57:54] <josephyee> * works for both situations
[12:58:10] <josephyee> @ALL: any other idea or disagreement?
[12:58:46] <resnick> So we are not saying, "5322 implementations need to start looking out for group in the From field"
[12:58:49] <resnick> ?
[12:58:49] <josephyee> @alexey: we used JCK's email sent earlier as discussion
[12:58:51] <Jacky Yao11 (Health Yao)> I think that downgrade doc should not update rfc5322 since downgrade doc may go informaitonal. informaitonal doc can not update std doc
[12:58:53] <josephyee> we are at (4)
[12:59:43] <Barry Leiba> PR: I think we're using "group in from" as a transitional hack.
[12:59:55] <Barry Leiba> I would hate to permanently record that as "updates 5322".
[13:00:01] <arnt> I agree that the downgrade docs don't update 3501/1939/5322, but I'd like to examine the IMAP text including the changes we agreed on today before making my mind up on whether it updates 3501
[13:00:23] <fujiwara> downgrade need to generate rfc 5322 message. And empty group syntax is prohibited by 5322.
[13:00:55] <resnick> @fujiwara: Empty group is allow in 5322. Group in From is not.
[13:01:23] <john.levine> @resnick: then wouldn't that be a problem if the goal is to support existing MUAs?
[13:01:29] <Klensin> @barry, Yao: the problem with "updates" isn't Info vs Stds Track. It is "good chance that we will look at these downgrade docs in 5-10 years and say "no longer needed, Historic" or "wasn't such a good idea, Historic". And that would leave 5322 in a very odd state.
[13:01:30] <fujiwara> @pete: I see. From, Sender fields need another format.
[13:01:34] <Barry Leiba> We spent 90 minutes in Beijing trying to come up with a better way for this.
[13:01:50] <Barry Leiba> We couldn't. I think we have to accept that it's a transitional hack, and document it as such.
[13:02:00] <arnt> did you consider foo@foo.invalid?
[13:02:05] <josephyee> @barry: +1 (personal)
[13:02:20] <Barry Leiba> And I agree with the last thing JCK said.
[13:02:21] <fujiwara> foo@foo.invalid or foo@server-host-name
[13:02:49] <Klensin> @pete, johnl: Of course. If the existing MUA obeys the robustness principle, it won't get too upset. If it decides that any deviation from 5322 equals "deviant, evil, mail" then it is in trouble regardless.
[13:03:16] <Barry Leiba> Our sense in Beijing was that this isn't great, but will probably cause very little breakage in practice.
[13:03:36] <Barry Leiba> Clients understand groups (including empty ones), and most will not have special cases for "from" to forbid it.
[13:04:02] <john.levine> Seems odd, but in that case, just document it and move on.
[13:04:08] <Barry Leiba> Exactly.
[13:04:10] <arnt> I sent out inviations for some party with a hand-rolled group from, all the potential guests received the mail ;)
[13:04:12] <resnick> (hatless) I am personally ambivalent about group-in-From vs. foo@foo.invalid <mailto:foo@foo.invalid>.
[13:04:32] <Klensin> (as co-chair explicitly): Let's not rerun that long and painful Beijing discussion and subsequent decisions unless someone really has a new argument or bit of information.
[13:04:46] <Barry Leiba> Absolutely!
[13:04:54] <josephyee> agreed!
[13:04:59] <fujiwara> Ok
[13:05:13] <arnt> jck, barry: I am curious, though: did you consider foo@foo.invalid in beijing?
[13:05:22] <Barry Leiba> I dismember.
[13:05:29] <Barry Leiba> You could go back and listen to the audio.
[13:05:31] <Barry Leiba> :-D
[13:05:32] <josephyee> the last consensus of empty-group-from-sender still hold
[13:05:34] <resnick> The only question in my mind is whether we think (because of Arnt's case among others) it is worth document group-in-From as an update to 5322, because it will get used for other than EAI.
[13:05:50] <resnick> s/document/documenting
[13:05:52] <Barry Leiba> IF we should decide to do that.......
[13:06:05] <Barry Leiba> I would suggest a separate small doc that updates 5322 to add group in from.
[13:06:13] <Barry Leiba> And then have downgrade normatively reference that.
[13:06:13] <josephyee> @arnt: this still has security issues although the exposure is less compare to other domain/TLD
[13:06:33] <arnt> yeah. there are always such issues when rewriting addresses.
[13:07:05] <Barry Leiba> I'll be happy to write up the small doc, if we want to go that way.
[13:07:14] <arnt> I confess to a certain relaxedness about it. we've eaten the beans, no sense in being uptight about the farting.
[13:07:26] <Barry Leiba> Arnt has a way with words.
[13:08:19] <Klensin> @Pete: Since I volunteered to write the text, I'm planning to do something a little different (unless told otherwise). 5322 is about communication on the _Internet_ wire. Technically, IMAP/POP aren't about 5322 header fields, they are about a close approximation but an after-delivery one. So is a transitional kludge in the POP/IMAP vocabulary, not a 5322 change. That justifies not "updates 5322" and also justifies the MTA and in-transit filtering chain being really rude if they see the construction and judge that wise.
[13:08:57] <josephyee> @ALL: 2 discussions going on here, so let's try to focus one at a time
[13:09:15] <arnt> pick one.
[13:09:28] <josephyee> @ALL: anyone favors using email address with dot invalid over empty group?
[13:09:44] <Barry Leiba> no
[13:09:56] <Martin Dürst> Agree with JohnK: empty groups in From can be seen as only allowed for IMAP, not in general.
[13:09:56] <josephyee> (personal): no
[13:09:57] <arnt> hm... not enought to reopen the discussion, really.
[13:10:02] <Barry Leiba> Bashed out in Beijing; leave it.
[13:10:22] <Klensin> No. First because I think we have been here. in Bejing. Second and more important, let me try to
[13:10:28] <josephyee> I want to see any new arguments, and we did discussed it in Beijing
[13:10:30] <resnick> @jck: There is an argument to be made for "IMAP requires 5322 on the wire. Group-in-From isn't 5322. Therefore, either you're updating IMAP to accept non-5322 or you're updating 5322."
[13:11:02] <Barry Leiba> PR: and JCK is saying he's going to write text explaining the deviation from IMAP using 5322.
[13:11:07] <josephyee> (as co-chair) for the record again, dot invalid address didn't get WG consensus
[13:11:31] <josephyee> and to the other "thread" of discussion how we handle the text
[13:12:07] <josephyee> (personal) sound like very important (gating) work but out-of-scope of EAI
[13:13:10] <Barry Leiba> Joseph: I'm not sure what you're talking about there.
[13:13:15] Jacky Yao11 (Health Yao) leaves the room
[13:13:15] josephyee leaves the room
[13:13:15] Klensin leaves the room
[13:13:15] Martin Dürst leaves the room
[13:13:34] <resnick> Whoops. A dump of people.
[13:13:41] <Barry Leiba> Uh-oh.
[13:13:42] <resnick> Waiting for rejoin.
[13:14:06] <Barry Leiba> While we wait: Pete, I saw you requested last call for Alexey's smtp-priority doc.
[13:14:12] <Barry Leiba> I thought we were going to wait for one more spin.
[13:14:25] <arnt> what's the next subject?
[13:14:33] <alexey.melnikov> IMAP document: One issue from Dave Cridland: he suggested not to invent new "UTF-8 quoted string" syntax and just re-use quoted strings after calling ENABLE UTF8...
[13:14:34] <resnick> @Barry: Let's not clutter the jabber log with that. Over to apps-ads if you want.
[13:14:38] <Barry Leiba> KO
[13:14:46] joseph.yee joins the room
[13:14:52] <resnick> One chair back.
[13:15:01] <arnt> I always read drafts ahead of all meetings.
[13:15:02] <joseph.yee> sounds like it's jabber.org <http://jabber.org> issue
[13:16:52] <arnt> joseph: what's the next subject?
[13:17:11] <joseph.yee> I believed that many try to get conenction back on jabber.org <http://jabber.org> and failing right now
[13:17:40] <joseph.yee> dont' know if I missed a lot, we are discussing the text from JCK on empty group deviation
[13:17:59] <joseph.yee> and I believed that many agreed?
[13:18:03] <arnt> noone has said a word since you were out in orbit.
[13:18:07] <Barry Leiba> JCK will write text. No point in talking about his text 'til he proposes it.
[13:18:08] <resnick> http://www.ietf.org/jabber/logs/eai@jabber.ietf.org/2012-05-14.html
[13:18:15] <arnt> noone has said a word while you were out in orbit.
[13:18:31] <joseph.yee> :)
[13:19:27] <sean.s.shen> jck is keeping trying reconnecting
[13:19:54] <resnick> Jabber.org <http://Jabber.org> does seem to be the problem. If people have other accounts, they should use them.
[13:19:56] <joseph.yee> @ALL: while waiting many to join back, any thought on this apporach?
[13:20:14] <arnt> reusing quoted-string?
[13:20:26] <arnt> I like it. simplifies life for me.
[13:20:49] <alexey.melnikov> arnt: it would
[13:21:11] <resnick> Sorry: Reusing quoted-string for what?
[13:21:23] <joseph.yee> John Klensin
@Pete: Since I volunteered to write the text, I'm planning to do something a little different (unless told otherwise). 5322 is about communication on the _Internet_ wire. Technically, IMAP/POP aren't about 5322 header fields, they are about a close approximation but an after-delivery one. So is a transitional kludge in the POP/IMAP vocabulary, not a 5322 change. That justifies not "updates 5322" and also justifies the MTA and in-transit filtering chain being really rude if they see the construction and judge that wise.
[13:21:35] <Barry Leiba> Instead of defining UTF-8-string.
[13:21:56] <resnick> Ah.
[13:21:56] <arnt> resnick, the eai document adds new string syntax, only to be used after ENABLE EAI=ACCEPT. dwd suggests to instead extend some existing syntax.
[13:22:36] <joseph.yee> @arnt: my questino is not about quoted-string
[13:23:28] <joseph.yee> before disconnect, the "other" discussion was to make another writing about empty-group-from so that EAI drafts do not update RFC5322
[13:23:56] <resnick> @jck: There is an argument to be made for "IMAP requires 5322 on the wire. Group-in-From isn't 5322. Therefore, either you're updating IMAP to accept non-5322 or you're updating 5322."
[13:24:10] <resnick> (I asked that before the hangup)
[13:24:20] <arnt> neutral
[13:24:54] <joseph.yee> I think it's important but seems gating EAI drafts moving forward and a bit out of scope
[13:25:22] <Barry Leiba> PR: and I pointed out that JCK will be writing text explaining the deviation from IMAP using 5322.
[13:25:31] <Barry Leiba> That does NOT need this to update 5322.
[13:25:35] <joseph.yee> @pr: also discussed in Beijing, some do find it useful like "do-not-reply@mailinglist-company"
[13:26:04] <resnick> @Joseph: Right. That also argues for an update to 5322.
[13:26:16] <resnick> (Though in a separate document and not gating EAI.)
[13:26:20] <resnick> (As Barry said)
[13:26:33] sean.s.shen leaves the room
[13:26:37] <Barry Leiba> Want me to write the little mini-doc?
[13:27:41] <resnick> @Barry: ambivalence.
[13:28:34] sean.s.shen joins the room
[13:28:43] <Barry Leiba> OK, I think we really need to move forward, even if JCK isn't back.
[13:28:49] <joseph.yee> @barry: thank you, but think best to chat with JCK about writing
[13:29:23] <joseph.yee> @barry and all: agreed
[13:29:38] <joseph.yee> (5) popimap-downgrade: Given that we are going to publish this
spec, is the rewrite model acceptable or do we intend to change
it? Personal note: the model that is there has been refined,
presumably, by many months of exposure in the WG. Do we really
have sufficient consensus for restarting that discussion.
[13:30:08] <Barry Leiba> I think we have consensus to publish, and we should go ahead.
[13:30:23] <joseph.yee> and I believed that (4) also helps the direction
[13:30:27] <Barry Leiba> The compromise is to publish both downgrade docs.
[13:31:05] <joseph.yee> hearing none, moving on...
[13:31:07] <joseph.yee> (6) The two downgrade specs are currently on track for Proposed
Standard? Do you we have consensus for starting a discussion
about Information or Experimental instead?
[13:31:38] <Barry Leiba> I think Informational, because they give strategies for coping with old, non-compliant clients.
[13:31:50] <Barry Leiba> JCK clearly feels that these are protocol docs, and should be PS.
[13:31:59] <Barry Leiba> I think it's not protocol.
[13:32:08] <Barry Leiba> BUT......
[13:32:27] <Barry Leiba> If we last-call them as PS and then we (or IESG) decides to go with Info, no harm done.
[13:32:40] <Barry Leiba> If we last-call them as Info, and IESG thinks they should be PS, we have a second last call.
[13:33:03] <Barry Leiba> So maybe go for PS, and put something in the PROTO writeup about maybe doing Info instead for <these reasons>.
[13:33:11] <john.levine> Is the IESG likely to prefer PS?
[13:33:15] <Barry Leiba> I think we should not consider Exp.
[13:33:20] <alexey.melnikov> Also having 2 docs as PS doing almost the same will confuse people
[13:33:27] Jacky Yao11 (Health Yao) joins the room
[13:33:29] <Barry Leiba> AM: agreed.
[13:33:34] <alexey.melnikov> I tend to agree that IETF LC as PS is fine
[13:33:38] <Jacky Yao11 (Health Yao)> come back
[13:34:17] <Barry Leiba> Levine: it's hard to say what the IESG will want: it does not speak with one voice.
[13:34:43] <joseph.yee> @alexey: if imap/pop mentions pick either one, will it be less confused?
[13:34:44] <alexey.melnikov> Barry Leiba: I don' think Experimental is bad either. They are sort of experiments
[13:34:48] Klensin joins the room
[13:34:54] <Barry Leiba> JCK's back!
[13:34:57] <arnt> they're no experiments
[13:35:00] <arnt> they're transition hacks
[13:35:04] <Barry Leiba> I agree with Arnt.
[13:35:05] JOUGASHIMA joins the room
[13:35:11] <Klensin> At least temporarily. That was fun (NOT)
[13:35:23] <alexey.melnikov> Hacks can be experiments ;-). But never mind, not a big deal
[13:35:25] <Barry Leiba> Talking about doc status now.
[13:35:40] <Barry Leiba> Repeating for John, I said this:
[13:35:40] <joseph.yee> we are on (6) docs status
[13:35:41] <Barry Leiba> I think Informational, because they give strategies for coping with old, non-compliant clients.
JCK clearly feels that these are protocol docs, and should be PS.
I think it's not protocol.
BUT......
If we last-call them as PS and then we (or IESG) decides to go with Info, no harm done.
If we last-call them as Info, and IESG thinks they should be PS, we have a second last call.
So maybe go for PS, and put something in the PROTO writeup about maybe doing Info instead for <these reasons>.
[13:35:41] <arnt> PS or I, I'd say PS but really, let's just get the text out.
[13:35:46] <resnick> It's having two documents going for PS doing the same thing that is worrying to me. We are proposing two standards?
[13:36:14] <JOUGASHIMA> Pity we didn't have StPeter here, he might have been able to help with the jabber.org server.
[13:36:23] JOUGASHIMA is now known as Martin Dürst
[13:36:30] <Barry Leiba> I think Info is better for many reasons.
[13:36:43] <Barry Leiba> But I'm not falling on sword for it.
[13:36:52] <joseph.yee> @pr: because we don't have a clue which one will helps better
[13:37:19] <resnick> And we're not planning to try them out and see which works better (i.e., do an experiment)?
[13:37:25] <Klensin> FWIW, I like the "go for PS and leave it in the IESG's hands" plan for multiple reasons. I also think that PS is fine and that we can justify competing standards in this case (and actually not just the two but several we haven't written up for good reasons). And, yes, I think I get to write that part of the Shepherd's report ::-(
[13:37:32] <resnick> @Barry: I *hate* protocol in Informational.
[13:38:12] <Barry Leiba> Pete: Then how do you address not wanting Info, and not wanting two similar PS?
[13:38:17] <Barry Leiba> You think Exp?
[13:38:18] <joseph.yee> @pr: (personal) I don't think the problem lies in technical (client), but adoption and preference
[13:38:38] <resnick> I'm fine with "PS, explain in the shepherd report, and let the IESG deal with it."
[13:38:49] <arnt> +1
[13:38:53] <Barry Leiba> I'll repeat, though, that I DON'T think this is protocol.
[13:39:11] <Barry Leiba> It's using protocol that's already defined.
[13:39:17] <resnick> @Barry: I think either PS or Exp. I don't see what Info has to offer.
[13:39:20] <Klensin> @pete: yes, that too, and I agree. IMO (personally) what we should do here is to push them both to PS and then, when we know enough, produce an A/S that says when one(s) to not use. My proposed (in email) text outline more or less says "use neither if at all possible", so takes a step in that directly.
[13:39:39] <Barry Leiba> It's telling the server how it might adapt the data it sends with that protocol, in order to have an old, non-compliant client understand it.
[13:39:40] <arnt> A/S means...?
[13:39:54] <Klensin> @barry: if this isn't Protocol, then 5322 isn't either. Both specify data formats and data elements, not negotiation
[13:39:59] <Barry Leiba> OK
[13:40:08] <Barry Leiba> I'll agree with the penultimate JCK message.
[13:40:08] <resnick> "A/S" == "Applicability Statement". A small PS which says which other PS's to use.
[13:40:10] <Klensin> A/S = AS = Applicability Statement
[13:40:12] <joseph.yee> applicability statement
[13:40:23] <resnick> See 2026.
[13:40:26] <arnt> afaict we have rough consensus for barry's procedure, and please let's progress, I'm short of time.
[13:40:53] <john.levine> I'd hope neither gets enough use for an AS to be worthwhile, because people who want EAI will use EAI clients.
But whatever
[13:40:53] <Barry Leiba> Go for PS, address the issue in the PROTO writeup, move on. Sounds good.
[13:41:18] <joseph.yee> (7)...
[13:41:30] <joseph.yee> too long to copy and paste
[13:41:34] <Klensin> @JohnL: that is the "AS comes along and moves both to historic as well as making them "not recommended". plan. Perfectly orderly
[13:42:11] <joseph.yee> (7) is about adding new text to IMAP doc wrt to client and downgrade
[13:42:41] <Barry Leiba> I'm happy with the proposal in (7).
[13:42:48] resnick reads 7, which is long and has many subparts.
[13:42:51] <Klensin> Summary of (7) (for those who came in late) is that we take as much discussion of downgrading as possible out of the POP and IMAP specs, add text to IMAP that says "upgrading clients is better, but...", references that text from POP, and we move on.
[13:42:56] <arnt> I'm happy with 7.
[13:43:05] <Klensin> If the general idea is ok, I'll try to propose text on-list.
[13:43:14] <joseph.yee> (personal) like
[13:43:22] <john.levine> (7) is fine, less redundant verbiage is better
[13:43:50] <Barry Leiba> JCK propose text on list, quantity measured in micro-jcks.
[13:43:59] <joseph.yee> consensus: to propose text to list
[13:44:07] <resnick> Seems reasonable.
[13:44:07] <joseph.yee> generally accpted
[13:44:24] <joseph.yee> * should say generally accepted at interim meeting
[13:44:50] <joseph.yee> 7.2 The two "downgrade" specs should be reference from that
section as examples -- nothing more or less.
[13:44:50] <Klensin> @JohnL: the goal is less redundancy, avoiding giving either downgrade spec priority or a need to comment on the other, and focusing as much as possible on "upgrading clients is the right thing to do, everything else is a choice among horrible options".
[13:45:16] <Klensin> @Joseph: yes to "examples".
[13:45:53] <Klensin> Devil will be in the details of text, but, if we are agreed on the principles (which we appear to be), I think we can deal with that.
[13:46:08] <Barry Leiba> kewl
[13:46:11] <alexey.melnikov> Klensin: the proposal seems reasonable
[13:46:11] <joseph.yee> @ALL: any disagreement on (7.2)?
[13:46:24] <Klensin> When the text shows up on the list, I hope people can focus on "good enough" not "perfect" or "completely aligned with personal views".
[13:46:27] <arnt> what's 7.2?
[13:46:31] <arnt> spinning up maio now...
[13:46:34] <Barry Leiba> 7.2 The two "downgrade" specs should be reference from that
section as examples -- nothing more or less.
7.3 All other text about downgrading should be removed from the
IMAP spec.
7.4 All text about downgrading should be removed from the POP
spec and a reference to the above substituted.
[13:47:02] john.levine leaves the room
[13:47:11] john.levine joins the room
[13:47:28] <arnt> 7.2 is fine with me. as are 7.3 and 7.4.
[13:47:43] <Jacky Yao11 (Health Yao)> i am not clear about 7.3 and 7.4
[13:47:44] <Jacky Yao11 (Health Yao)> 7.3 All other text about downgrading should be removed from the
IMAP spec.
7.4 All text about downgrading should be removed from the POP
spec and a reference to the above substituted.
[13:47:51] <Martin Dürst> fine with 7.2/3/4 here too
[13:48:31] <Jacky Yao11 (Health Yao)> The two "downgrade" specs should be reference from that
section as examples -- nothing more or less.
that section means which section?
[13:48:42] <Barry Leiba> Jacky: the point is that text saying what 7.1 says will go into the IMAP spec, and that's the only thing the IMAP spec will say about downgrading. POP will reference IMAP for that discussion.
[13:48:51] <Klensin> Jiankang, the idea is to get all discussion of downgrading principles (as distinct from details) into one place and avoid both redundancy and bouncing people back and forth among docs. I think
[13:49:21] <Klensin> the relevant text could go in Framework (which we don't want to reopen), POP, or IMAP, and I tentatively selected IMAP for several reasons.
[13:50:08] <Jacky Yao11 (Health Yao)> ok, understood. thanks barry and john
[13:50:36] <joseph.yee> @all: hear no disagreement
[13:50:56] <joseph.yee> silence.....
[13:51:10] <Klensin> The most important of those reasons, FWIW, is that, while we haven't decided to write it up, it is perfectly clear how to deliver as "no you can't have that particular message because" response in POP... but not in IMAP.
[13:51:27] <arnt> hm
[13:51:50] <arnt> some servers do that by sending NIL replies
[13:52:23] <arnt> * 42 FETCH (UID 123 BODY[1] NIL)
[13:52:26] <arnt> that kind of thing
[13:52:50] <arnt> it happens e.g. when a server expunges a message and doesn't tell the client about that
[13:52:57] <Klensin> @arnt: yep. But no standard or stanard framework, afaik. Anyway, moving on (I hope)...
[13:53:05] <joseph.yee> 7.2 - 7.4 was agreed
[13:53:25] <joseph.yee> (personal) I think this does not change to keep the text at IMAP
[13:54:11] <joseph.yee> and we discussed everything from the list sent from JCK before this meeting
[13:54:40] <joseph.yee> (co-chair) any other issues from anyone?
[13:55:15] <Martin Dürst> the agenda said something about mailto, or didn't it?
[13:55:22] <Klensin> Looks to me like we have six minutes -- want to start a discussion on mailing lists and MAILTO (noting that Martin has apparently dropped off), or give up for today.
[13:55:38] <Klensin> Sorry Martin -- didn't see you on my participant list.
[13:56:15] <Martin Dürst> I haven't dropped off. I don't want to start a discussion about mailto. I just want to know when the WG wants to take the document as a WG document, to then discuss it.
[13:56:25] <Klensin> @joseph? Four minutes.
[13:56:41] <Martin Dürst> But I'm fine if that happens on the mailing list.
[13:57:02] <joseph.yee> @all: yes 4 minutes, but up to everyone
[13:57:20] <joseph.yee> I think we may bring mailto discussion to mailing list
[13:57:23] <arnt> one minor point.
[13:57:30] <joseph.yee> (that's personal)
[13:57:35] <arnt> the WG has decided against using .invalid
[13:58:02] <joseph.yee> @arnt: yes
[13:58:02] <arnt> simpledowngrade explicitly doesn't say what to use, but does mention .invalid, one might even say it does so prominently.
[13:58:30] <arnt> there is a bit of dissonance here. comments?
[13:58:38] <Barry Leiba> I think there's no issue.
[13:58:49] <Barry Leiba> We say not using .invalid in the OTHER downgrade doc.
[13:58:53] <john.levine> It's an alternative. I think we agree that all downgrade alternatives are lousy.
[13:59:21] <Klensin> (personal) I agree with Barry, but am willing to read the text again to see if my mind changes in the light of today's discussion.
[13:59:52] <joseph.yee> @arnt: I believed that it's an editorial issue?
[14:00:44] <arnt> john, personally I think simpledowngrade is fine, considering how easy it is to implement. it'd be lousy if it required thousands of lines, but I did it in ~30. at that level of effort I'm prepared to accept imperfect results.
[14:00:54] <Klensin> @joseph: it is an editorial issue unless the WG has a strong opinion, which I think is the question Arnt is asking. But we are out of time, so it should probably go to the list.
[14:01:16] <arnt> that's exactly the question I meant to ask.
[14:01:22] <arnt> have a nice day.
[14:01:30] <Klensin> @arnt: that has been the assumption from the beginning, so wfm.
[14:01:40] <joseph.yee> @jck: right. I did asked if anyone favor dot invalid solution and the answer is no, but it will be asked again in mailing list
[14:02:07] <joseph.yee> quick recap before finish the meeting:
[14:02:21] <joseph.yee> LANG: no specific order, 'default' dropped
[14:02:37] <joseph.yee> UTF8 param: enable manages mode switch
[14:02:54] <joseph.yee> no /UTF8 /no-UTF8 (simply no flags) at LIST, SELECT, etc
[14:03:04] <joseph.yee> no 'updates' at downgrade doc
[14:03:32] <joseph.yee> dot invalid email address does not get WG consesus (will ask again at miling list)
[14:03:50] <joseph.yee> mini doc about emtpy group deviation (Barry volunteered)
[14:04:09] <joseph.yee> both downgrade doc go for PS, will address in proto write up
[14:04:36] <joseph.yee> agreed on the proposed text to add to IMAP wrt to client and downgrade
[14:04:38] <Barry Leiba> Correction: mini-doc is "mini doc about group in from".
[14:04:53] <Klensin> @joseph: please post "recap" to list ASAP. Let'e work together on getting more detailed minutes (and an action item list) together, draft to list by, I hope, mid-week.
[14:05:00] <joseph.yee> both downgrade docs and pop will reference the proposed section
[14:05:03] <Martin Dürst> @joseph: "dot invalid email address does not get WG consesus (will ask again at miling list)
" should say "for pop-imap-downgrade, dot invalid email address does not get WG consesus (will ask again at miling list)" (because it's fine for simple downgrade, at least as far as I'm concerned)
[14:05:14] <joseph.yee> @barry: thank you
[14:05:33] <joseph.yee> @jck: will do
[14:05:45] <joseph.yee> @martin: noted
[14:05:45] <Klensin> And I really would like to avoid the mini-doc if we can, but let's take that to the list and see if the text/ model I was proposing when I first got dropped is helpful
[14:05:55] <Barry Leiba> Yes
[14:06:25] <Klensin> I'm not against it in principle, just don't want to add more tasks to the list, however "mini", if that can be avoided.
[14:06:30] <joseph.yee> I will bring minutes and issues to the list asap
[14:07:07] <Barry Leiba> OK, everyone…. 谢谢 !
[14:07:12] <joseph.yee> @ALL: that's the quick recap, detailed wil lcome in mailing list
[14:07:13] <Klensin> As I said, get the summary/recap up ASAP; let's colleaborate on the minutes.
[14:07:14] <joseph.yee> thanks to all
[14:07:27] <sean.s.shen> thanks
[14:07:28] <Martin Dürst> Have a nice day everybody, especially for those that still have a relevant part of their day left :-)
[14:07:30] <Klensin> thanks everyone. Very productive, IMO
[14:07:43] <resnick> +1. Very productive.
[14:08:00] <Klensin> Martin and others in Asia, sleep well and thanks for staying up
[14:08:21] <resnick> Jabber log <http://www.ietf.org/jabber/logs/eai@jabber.ietf.org/2012-05-14.html> worked even when folks dropped off. Re-read as needed.
[14:08:23] <sean.s.shen> good night & morning
[14:08:24] <joseph.yee> yes, thanks for everyone in Asia staying up
[14:08:37] resnick goes in search of coffee
[14:08:45] Barry Leiba leaves the room
[14:08:48] john.levine leaves the room
[14:08:49] <fujiwara> good night and good day
[14:08:49] <Martin Dürst> thanks for you guys to get up early!
[14:08:50] sean.s.shen leaves the room
[14:09:00] <Jacky Yao11 (Health Yao)> thanks everyone
[14:09:11] Klensin leaves the room
[14:09:20] Martin Dürst leaves the room
[14:09:27] fujiwara leaves the room
[14:25:21] Jacky Yao11 (Health Yao) leaves the room
[15:42:28] joseph.yee leaves the room
[16:18:34] arnt leaves the room
[17:01:57] alexey.melnikov leaves the room: Logged out