[09:42:50] --- Marcos has joined
[09:43:35] * Marcos has changed the subject to: EAI WG meeting, Chicago [Room Adams
[09:43:50] * Marcos has changed the subject to: EAI WG meeting, Chicago [Room Adams]
[09:44:06] --- Marcos has left
[10:00:04] --- Dave Cridland has joined
[10:01:07] --- Marcos has joined
[10:01:28] --- eric has joined
[10:01:57] --- tonyhansen has joined
[10:02:00] <Marcos> Session starts. Chair is greeting attendants.
[10:03:04] --- Jaeyoun Kim (KRNIC) has joined
[10:03:39] <Marcos> Xiaodong is not here because of problems with inmigration papers
[10:03:46] <Marcos> So Harald will chair on his own.
[10:04:15] --- fujiwara has joined
[10:04:16] --- yone has joined
[10:04:34] --- healthyao has joined
[10:04:47] <Marcos> Unfortunately, the agenda is not online yet
[10:04:55] <Marcos> Chair report:
[10:05:01] <Marcos> RFC 4952 published
[10:05:13] <Marcos> SMTP and UTF8HDR believed to be ready
[10:05:22] <Marcos> (modulo choiche of MIME type)
[10:05:58] <Marcos> DSN has open issues
[10:06:30] <Marcos> Downgrade is in good form. Need to discuss "unknown header" handling, multiple "downgrade" headers and the downgraded no-alt address format
[10:06:38] <Marcos> Other drafts depend on completion of the core
[10:06:39] --- herve.prigent has joined
[10:07:15] <Marcos> Next agenda point: "SMTP EXT status and open issues"
[10:08:29] <Marcos> Klensin: (paraphrased) If you have comments to the docs, it is NOW time to get them out there. Don't wait!
[10:09:00] <Marcos> Issue tracker at rt.psg.com
[10:09:27] <Marcos> REsolved issues: 1483, 1484, 1486, 1492, 1493, 1495
[10:09:33] <Marcos> If somebody think they are not solved, please say so
[10:09:34] --- Jim Galvin has joined
[10:09:54] <Marcos> Are there any unresolved issues?
[10:09:58] <Marcos> Please speak now
[10:10:49] <Marcos> Question to the room: Do you believe this is ready for WGLC?
[10:11:04] <Marcos> Who have read it? 12 hands count
[10:11:19] <Marcos> About the same number of ppl think it is ready for WGLC
[10:11:28] <Marcos> None think that it is NOT ready for WGLC
[10:11:32] <Marcos> WGLC will be sent out today
[10:11:42] <Marcos> Next agenda item; UTF8 Headers status an dopen issues
[10:11:57] <Marcos> Resolved issues: 1487, 1488, 1490, 1491, 1494
[10:12:07] <Marcos> If somebody think they are not solved, speak out
[10:12:14] <Marcos> There is one outstanding issue:
[10:12:29] <Marcos> 1485: "Choice of body part for transport of UTF8SMTP messages"
[10:12:36] --- bruce has joined
[10:12:50] <Marcos> Is there any other issue that would stop the doc for going WGLC?
[10:13:00] <Marcos> About 10 ppl in the room have read the doc (hand count)
[10:13:37] <Marcos> About 10 ppl thought this is the only issue open outstanding
[10:14:02] <Marcos> Klensin: He is concerned about a LC'ing this doc before the DSN doc
[10:14:13] <Marcos> Harald: This is a normative dependency
[10:14:22] <Marcos> About the 1485 issue:
[10:14:43] <Marcos> Some bad types were eliminated in poll. Not clear that any remaining type will have really bad effects, not clear that it won't, either.
[10:14:49] <Marcos> We need to pick ,not design, a method:
[10:14:54] <Marcos> Instant Runoff voting
[10:14:59] <Marcos> Concordet Voting?
[10:15:02] <Marcos> Throw dice?
[10:15:04] <Marcos> Others?
[10:15:28] --- levigner has joined
[10:15:57] --- randy has joined
[10:16:24] <Marcos> Hansen: Let's flip a coing
[10:16:49] <bruce> (coin between instant runoff and concordet)
[10:17:00] <Marcos> Klensin: Discard the less likely option and have a lottery on the rest
[10:17:09] <Marcos> s/option/options/
[10:17:24] --- secastro_scl has joined
[10:17:45] <Marcos> Klensin; There are some options which are equally bad
[10:18:09] <Marcos> which are very short-sighted and we will regret it in the future
[10:18:51] <Marcos> Chair asks the room for how going on
[10:19:20] <Marcos> Harald suggests that Klensin sends to the list which are these bad options and some rationale on it
[10:19:54] <Marcos> Klensin; Happy to do that.
[10:20:31] <Marcos> Klensin: His rationale will be how people will think about EAI in 10/15 years
[10:21:48] <Marcos> It should be long-term neutral, not hang on protocols/encodings/whatever that we come up with now.
[10:22:13] <Marcos> Harald has a coin in his hand
[10:22:32] <Marcos> Harald suggests that Dave C. comes and flips it
[10:23:03] <Marcos> Harald flips himself and we'll go for concordet voting
[10:23:28] <Marcos> Stephane B.: It's not Concordet, it's Condorcet
[10:23:51] <Marcos> Next item in agenda: DSN status
[10:24:10] <Marcos> Report by Alexey M.
[10:24:32] <Marcos> If an SMTP server can't deliver an EAI DSN to the next hop, need to use a 7bit encoding, downgrade or discard?
[10:24:49] <Marcos> Also need resolving the 1485 issue
[10:25:13] <Marcos> Opinions?
[10:25:28] <Marcos> Pete R.: Why would you not do the downgrade?
[10:26:02] <Marcos> Alexey: He thought reencoding using the MIME-types would suffice, no need to downgrade
[10:26:23] <Marcos> Klensin; Downgrades don't always succeed, you could end up with silly states
[10:26:35] <Marcos> Klensin; This is a non-issue
[10:27:02] <Marcos> Harald: Is this about the DSN itself?
[10:27:14] <Marcos> Alexey: The machine parsable part and the headers
[10:27:38] <Marcos> Pete R: DSN reencoding will be a problem if this is handled by some non-EAI-aware part
[10:28:23] <Marcos> Randy G: Downgrade is more complicated to implement.
[10:28:26] --- kimk has joined
[10:29:23] <Marcos> Randy G: The corner case of non-EAI-aware part shouldn't be the point to decide on (paraphrased). This is a bizarre case.
[10:29:23] --- Jaeyoun Kim (KRNIC) has left: Replaced by new connection
[10:29:23] --- Jaeyoun Kim (KRNIC) has joined
[10:29:59] <randy> More misconfiguration rather than bizarre
[10:30:01] <Marcos> ???: Implicit requirement that all MTAs have to downgrade?
[10:30:09] <bruce> ??? = eric allman
[10:30:31] <Marcos> Alexey: Do you think many initial implementations won't downgrade at all?
[10:30:47] <Marcos> Eric A: He doesn't know. While reading, it could be very difficult or very easy
[10:31:15] <Marcos> Philip: What's meant with the discard option in the slide?
[10:31:38] <Marcos> Philip: Discard the message? The machine-readable part?
[10:31:53] <Marcos> Alexey: Machien-readable part can contain EAI addresses
[10:33:25] <Marcos> Philip: Not require downgrading if you want implementations right
[10:34:04] <Marcos> Klensin: His prediction is that early-on implemantations won't downgrade
[10:35:14] <Marcos> Philip concurs
[10:35:29] --- resnick has joined
[10:35:40] <Marcos> The general feeling is that we should tried to encode and not downgrade.
[10:35:49] <Marcos> For the return message/headers, either encode them or not generate them at all
[10:35:52] --- resnick has left
[10:35:53] <Marcos> We will move this to the list
[10:35:57] --- resnick has joined
[10:36:05] --- lisa has joined
[10:36:42] <Marcos> Klensin: We shouldn't decide this here
[10:37:24] <Marcos> Harald: Downgrade is off-the table. Some part of encoding is on the table. We'll take the issue to the list.
[10:37:39] <Marcos> Sense of the room (hum) supports that.
[10:37:44] <Marcos> Next agenda issue
[10:38:03] <Marcos> Downgrade status
[10:38:23] <Marcos> Report by Fujiwara
[10:38:41] <Marcos> How many ppl have read it? Not many hands raised
[10:38:59] <Marcos> Issue 1000: Downgrade (unresolved)
[10:39:06] <Marcos> Need for simple downgrade procedure?
[10:39:27] <Marcos> Advisability of "group syntax"? (international address = ?utf8?b?asdf?=removed:;M)
[10:39:34] <Marcos> Handling of "unknown" header fields?
[10:39:47] <Marcos> Are multiple downgraded header fields difficult to handle?
[10:39:55] <Marcos> Harald would like to have feedback on that
[10:40:03] <Marcos> What do we do with DKIM header fields?
[10:40:53] <Marcos> Philip: MUAs would misshandle empty groups? He thinks so.
[10:41:13] --- bruce has left
[10:41:21] <Marcos> No further comments
[10:41:23] --- bruce has joined
[10:41:44] <randy> I think Phil was saying that MUAs won't mishandle empty group syntax because this is already common
[10:42:18] <Marcos> Thanks, randy. I coudln't deal with his irony.
[10:42:29] <eric> yes, that's what philip was saying
[10:42:45] <Marcos> Klensin: NEed a comment in the doc about the attempt to balance on downgrading easy cases or not
[10:43:39] <Marcos> Harald suggests to add a note that "reject complex" is permitted
[10:43:51] <Marcos> Klensin says that's fine
[10:44:39] <Marcos> Now aobut unknown header fields with UTF8
[10:45:10] <Marcos> The current doc says that the field is downgraded and the original one is dropped
[10:45:53] <Marcos> This is done to preserve original as much original information as possible
[10:46:02] <Marcos> Pete: I support that
[10:46:39] <Marcos> pete: Lots of experience with bad things happening with multiple occurrences of the same header
[10:47:07] <Marcos> Pete: So it's better not to have one "downgraded:" header that repeats again and again
[10:47:48] <bruce> instead have 'downgraded-to', 'downgraded-from', 'downgraded-cc' etc.
[10:48:37] <Marcos> Eric: Are you suggesting that downgraded- is a prefix?
[10:49:09] <Marcos> PEte: We are now making the parsing of header fields a requirement to take action
[10:49:21] <Marcos> header field names
[10:49:45] <Marcos> "Downgrade: field-name" will disappear in strange ways
[10:50:07] <randy> Eric and Pete agree that 'downgraded-' as a special header name prefix is bad
[10:50:38] <randy> But Pete says it is less bad than having a 'downgrade: foo'
[10:51:20] <Marcos> Harald thinks that the feeling of the room is for "downgraded-*"
[10:52:05] <Marcos> He asks for humming
[10:52:27] <Marcos> 7 hands raised for "downgraded-*" (no humming)
[10:53:14] <Marcos> Klensin says something, but nobody can hear it, because he doesn't use the mic
[10:53:45] <randy> John said if anyone has a third approach he or she should speak now
[10:54:05] <Marcos> Pete answers D.Williams: There's experience with implementations that choke with really long header fields
[10:54:58] <Marcos> Going through multiple levels of MTAs makes today received headers increase and this causes problems
[10:55:20] <Marcos> making downgrade- is problematic, accepted, but it's still less bad (repeating what was said)
[10:55:39] <bruce> (randall g?)
[10:56:05] <Marcos> Klensin: There's experience that admittedly it will go wrong (again)
[10:56:36] <randy> discussion is about putting all downgraded headers in one super-long 'downgraded' header
[10:56:47] <randy> Agreement that this is bad for various reasons
[10:56:51] <Marcos> Philip: Encoding will expand size of content. Downgraded line will be longer. He concurs with Klensin
[10:57:16] <randy> Speakers agree that 'downgrade-' is best (or least bad) choice
[10:58:02] <Marcos> Pete: He would like the decission of using a prefix "downgrade-" to go beyond the mailing list of the wg and hear from other people about reserving this word
[10:58:28] <Marcos> What do we do with DKIM header fields?
[10:58:56] <Marcos> Pete: We break DKIM signature and need to warn the DKIM folks that our experiment breaks them
[10:59:05] <Marcos> Dave C: Agree
[10:59:22] <Marcos> Barry L.: Documenting this fact is all you can do
[10:59:25] --- guenther has joined
[10:59:38] <Marcos> Barry: DKIM headers themselves do not need to be downgraded
[10:59:43] <Marcos> will not have utf8
[11:00:24] <Marcos> Eric A: The best thing you can do when you sign a mail is to have 7bit in it, or it could break the sig
[11:01:01] <Marcos> Klensin: Rather have DKIM information discarded that getting a false positive about a forgery
[11:01:24] <Marcos> Barry: There is already a concept of a failed signature in the DKIM spec
[11:02:09] <Marcos> Barry: Need to check DKIM spec for the fields that contain mail addresses and domain names, whether they can contain 8 bit
[11:02:56] <Marcos> Dave: What are we going to do with DKIM headers? This group shouldn't write any normative about it. Just a comment that downgrading breaks sig
[11:03:35] <Marcos> Chris N: Speaking as app AD, DKIM is RFC, the issue needs to be addressed in this EAI. He won't prescribe how this needs to be worded.
[11:04:18] <Marcos> Barry: Fujiwara's comment is good. A comment could be included that the downgrading server could resign the message, if he wants to
[11:04:29] <Marcos> sorrry, couldn't hear that
[11:05:16] <Marcos> Pete: A comment would suffice "downgrading changes headers, signatures that rely upon that might be broken"
[11:05:42] <Marcos> R. G.: Any server that is authorized to sign, could re-sign. Stating the obvious.
[11:06:13] <resnick> The chap before me said that it wasn't specific to DKIM. Other signing mechanisms might be equally messed up.
[11:06:21] <Marcos> Dave C: It's very clear from the comments what this wg should prescribe or not comment on.
[11:06:49] <Marcos> Barry: There are things that you want to experiment with and some than not.
[11:07:30] <Marcos> Chris N: If we put specific advice what to do with DKIM, then we'll need consensus from the DKIM wg for that
[11:08:13] <Marcos> Harald tries to sum up: What to do with DKIM header fields? Nothing. Comment that downgrading breaks sigs (of all technologies). Don't try to solve others' problems.
[11:08:54] <Marcos> Pete: Making suggestions it's not bad if some interesting advice comes out of it. Just don't make it normative.
[11:09:13] <randy> Pete suggests that we finesse the issue by noting "interesting" advice but not being normative
[11:10:06] <Marcos> Dave: We are discussing the interaction of 2 specs. This is messy and not well understood. He thinks that a sepparate document could deal with this.
[11:10:33] <Marcos> Harald: That's an editorial issue.
[11:11:32] <Marcos> Hansen: We don't break DKIM. Just crossing a boundary will do it.
[11:12:09] <Marcos> Pete: Examples in the downgrade doc would be Good (TM)
[11:12:28] <Marcos> Next agenda item: POP status
[11:13:08] <Marcos> Report by R. Gellens
[11:14:08] <Marcos> Randall reports about the open issues
[11:14:26] <Marcos> The decision on how to handle utf8 in received headers will impact the up-conversion requirements section.
[11:14:29] <fujiwara> (Sorry, my poor english)My comment was the originator server can generate two signatures, one is the signature of the original message and the other is the signature of downgraded message.
[11:15:00] <Marcos> Should we make POP up-convert requirements match the IMAP up-convert requirements? The current POP requirements encourage but do not require a MIME parser on the server or final delivery agent.
[11:15:29] <Marcos> The current IMAP up-conversion requirements do require a mIME parser (since IMAP already requires one).
[11:16:01] <Marcos> At Fujiwara: It was not a problem of English, but of acoustics. I was a bit far away from the mic.
[11:16:21] <Marcos> Anchor 9: Issue regarding human-readalbe text regarding different languages
[11:16:32] <Marcos> Anchor 15
[11:16:40] <Marcos> Anchor 16 and 17
[11:16:53] <Marcos> (the text moves to fast in the screen, can't capture that)
[11:17:57] <Marcos> Anchor 17: The POP· server must not perform up-conversion of headers and content of multipart/signed (rfc 1847), as well as original-recipient and Return-Path.
[11:18:34] <Marcos> Chris N: The reason for upconversion is that 2047 encoding has interoperability problems with POP
[11:18:54] <Marcos> If his experiment could increase interoperability, it has a real benefit
[11:19:20] <Marcos> Randall: It's nicer for the client, if he can deal with utf8, not to deal with 2047
[11:19:59] <Marcos> Randall: I think it's been to few discussion about this problem in particular and aobut the draft in general
[11:21:35] <Marcos> Philip: He thinks that adviceo from the SMIME wg will be that if you have 8-bit data, you should encode it
[11:22:38] <Marcos> Chris: Reasonable to assume that a client that can verify signatures will have 2047 implemantation right
[11:22:41] --- randy has left
[11:23:59] <Marcos> Philip: The current formulation of anchor 17 in the spec is the best choice
[11:24:38] <Marcos> ???: ???
[11:25:11] <lisa> Nathanial said this might be a transition problem, because vendors can safely sign things by making them ??? compliant.
[11:25:30] <lisa> I was looking in jabber to see what he thought they should be compliant to :)
[11:25:46] <bruce> s-mime perhaps?
[11:26:23] <Marcos> Yes, I think he said SMIME
[11:26:42] <Marcos> (couldn't capture Dave's comment, while reading my own text)
[11:27:36] <Marcos> Chris: The result of RETR command according to the current doc returns the same that a POP-server complienat returns today
[11:28:35] <Marcos> RAndall: The doc now: If the client uses the UTF8 version of the commands, it will get the 8-bit versions of the command. If he uses the traditional commands, will get the 7bit version of the messages
[11:29:34] <Marcos> Philip: HE doesn't know if this issues only exist accross boundaries or also inside domains
[11:30:01] <Marcos> What is MDAD?
[11:30:28] <Marcos> Dave: To the extent that there is a coherent environment outside my machine, the upconversion can take place anywhere there
[11:31:34] <Marcos> Harald:
[11:31:40] <resnick> ADMD = ADministrative Mail Domain
[11:32:16] <Marcos> Do POP clients do DKIMverification?
[11:32:21] <resnick> draft crocker email arch 09 txt
[11:32:40] <Marcos> Harald: There are a couple of issues in these anchors that have to be reviewed
[11:33:00] <Marcos> Randall & Chris discussing about 3066 vs 4646 in the references
[11:33:21] <Marcos> Randall didn't know which section in 3066 is equivalent in the new RFC number
[11:34:24] <Marcos> Randall: It might be simpler to remove the reference to upconversion
[11:35:29] <Marcos> Chirs: It is highly optimistic that clients that have 2047 broken will fix it in the process
[11:36:48] <Marcos> Do we want to say somethign about upconversion in the presence of DKIM headerS?
[11:36:56] <Marcos> Philip: WG still working on it
[11:37:19] <Marcos> Philip: There was some discussion about IMAP extension. Still nebulous
[11:38:06] <Marcos> Harald: three alternatives a) send always 7 bit
[11:38:23] <Marcos> b) returning sth that is awfully close to the bits I have stored
[11:38:37] --- herve.prigent has left
[11:38:50] <Marcos> c) what it's in the message store
[11:39:21] <Marcos> Chris: Very careful with the latter, it will break the signatures in some circumstances
[11:40:13] <Marcos> Randall: Client and servers implementors are always mutually suspiciuos
[11:40:21] --- dcrocker has joined
[11:40:44] <Marcos> Harald: I think I will take this one to the list
[11:40:57] <Marcos> Randall: We definitely need more discussion
[11:41:18] <Marcos> Next agenda issue: Mailing list status
[11:41:36] <Marcos> Two places asking if the text bracketed by the editors note has any value
[11:42:01] <dcrocker> Let me try to suggest that the problem currently being discussed is really that the group is trying to over-specify how to handle a transition event. At base, specifying that the upconversion takes place after delivery over-constrains the behavior. Some environments are more homogeneous and some are less. For the ones that are more, the current constraint -- to post-delivery -- removes some significantly more convenient implementation choiceds.
[11:43:00] <Marcos> Randall: Please read the draft and comment whether that text has any value
[11:43:36] <Marcos> Harald: It could have some possible value
[11:43:53] <Marcos> 1 ppl in the room has read the mailing list draft
[11:44:24] <Marcos> Another issue: "Does rfc 2369 need to be updated to permit the use of IRIs?"
[11:45:33] <Marcos> (this is regarding the use of List-* headers)
[11:46:55] <Marcos> If we want to update rfc 2369, then the do has to be rewritten a bit to make a ware that there's a bit more work that just putting an IRI in there
[11:47:52] <Marcos> Randall: There is current text "given the need potentially to deal with non-utf8smtp-awara MTAs in the path of delivery for differnet members, it is advisable that mailing list operators obtain an alt-address from each member before adding the member"
[11:48:09] <Marcos> He suggests to delete it, because it's contradictory with text in some other parts
[11:48:16] <Marcos> Pete: Why it's an IRI a problem?
[11:48:57] <Marcos> Pete: Why should we update 2369?
[11:49:10] <Marcos> Randall: This is sth that the group should agree on it, before doing it.
[11:49:50] <Marcos> ???: The reason for asking for an alt-address in mailing lists is that in a mailing list context, the chances are big that there will be a mixture of both kind of addresss.
[11:51:04] <Marcos> Randall: Should ther ebe sth special with a list with an EAI subscriber? Why?
[11:51:57] <Marcos> ???: Mailing list is a special case because it is a mixture of ppl that have prior contact with each other and pppl who don't
[11:52:39] <Marcos> ???: At least a note for the list admin that he could consider the policy of requiring an alt-address
[11:53:12] <Marcos> Harald: We'll take this to the list
[11:53:56] <Marcos> Harald: And we'll take to the list as well the issue with the List-* header with IRI and ASCII mail
[11:55:14] <Marcos> Philip: Concern about an "unsubscribe URL" that should work in the case of an EAI
[11:55:36] <Marcos> Phiilip: If there were an alt-address it could be used for that
[11:57:31] <Marcos> Randall: A List-* Header containing EAI AND an alt-address would be handled by the downgrade procedure and dropped
[11:58:04] <Marcos> Harald: Take this to te list
[11:58:14] <Marcos> Next Agenda Item: Timeline
[11:58:26] --- abelyang has joined
[11:58:57] <Marcos> WGLC 2-week on SMTP and UTF8: August? Do we include DSN?
[11:59:08] <Marcos> SMTP, UTF8, DSN(?) to IESG: September?
[11:59:18] <Marcos> WGLC (2-week) on Downgrade: September?
[11:59:25] <Marcos> Downgrade to IESG: October?
[11:59:39] <Marcos> Rooom agrees that DSN should go to IEST in September
[11:59:51] <Marcos> December IETF: Discuss auxiliary drafts only
[12:00:45] <Marcos> How/when do we collect results of experiment? How do we document the results?
[12:02:27] <Marcos> Harald: Is this realistic?
[12:02:46] --- frank has joined
[12:03:16] <Marcos> Alexey: I know IETF doesn't do Interops. But we need some kind of that for a success to be declared.
[12:03:37] --- randy has joined
[12:03:56] <Marcos> Harald: Can the authors of the respective docs have them ready by early august?
[12:04:05] <Marcos> Some noddings
[12:04:14] <Marcos> Harald: That's a plan.
[12:04:26] <Marcos> Next agenda item: Summary of action items
[12:04:46] <Marcos> A) Voting on MIME type to be started ASAP
[12:04:57] <Marcos> b) New drafts of SMTP, UTF8HDR and DSN ASAP after that
[12:05:08] <Marcos> (August)
[12:05:16] <Marcos> C) WGLC on core docs in August
[12:05:32] <Marcos> AOB?
[12:05:41] --- dcrocker has left
[12:05:43] <Marcos> We are done
[12:05:57] --- eric has left
[12:05:58] <Marcos> See you in December
[12:06:01] --- Jim Galvin has left
[12:06:03] <Marcos> We adjourn
[12:06:12] --- bruce has left
[12:06:12] --- abelyang has left
[12:06:31] --- frank has left
[12:08:31] --- lisa has left
[12:09:09] --- yone has left
[12:10:38] --- kimk has left
[12:14:32] --- randy has left
[12:16:41] --- Marcos has left
[12:17:52] --- resnick has left
[12:18:02] --- levigner has left
[12:19:31] --- guenther has left
[12:20:05] --- Jaeyoun Kim (KRNIC) has left: Computer went to sleep
[12:20:55] --- tonyhansen has left
[12:21:10] --- healthyao has left
[12:21:55] --- secastro_scl has left
[12:27:25] --- Dave Cridland has left
[12:31:17] --- levigner has joined
[12:34:12] --- levigner has left
[13:08:47] --- healthyao has joined
[13:26:50] --- fujiwara has left
[13:53:18] --- healthyao has left
[14:20:42] --- anabolism@jabber.org has joined
[14:26:41] --- anabolism@jabber.org has left