XSF Discussion - 2019-01-11

1. Is this document needed to fill gaps in the XMPP Standards Foundation's policies and procedures, or to clarify an existing XSF policy or procedure? 2. Does the document address the problem stated in the introduction and requirements? 3. Should the XSF adopt this document as part of its policies and procedures? 4. Do you have any concerns about the effects of this policy? 5. Is the document accurate and clearly written?

Speaking of XEP-0345, I should look at that and see where I left it... I know I had comments from Zash, and can't recall if I addressed them.

Thanks dwd

I did what

jonas’ what he said ^

Zash, You complained about the "legal name" thing, I think.

Zash, It was a while ago though.

Maybe I did

I neither confirm nor deny this

I wonder if there's a more accurate/applicable term than 'legal name'

I myself am not using my legal name

Guus, It varies between jurisidctions, which doesn't help.

I'm using "Guus der Kinderen", while legally, I shall be referred to as "Gustaaf Johannes Stephanes der Kinderen"

(which basically is used only when I renew my passport or book a flight - I was once scolded by a police officer for failing to spell my own legal name 😉 )

Guus, So I believe that most European countries are very particular about names, whereas places like the UK are very relaxed (hence I can be Dave Cridland on legal forms as well as David Alan Cridland).

I don't mind using the term 'legal name' though - but if there's something more applicable, we could use that instead.

Guus, Also I'm calling you "Gustaaf" from now on.

I would be disappointed if you did not.

Hmmm. So XEP-0345 still has warts from when it was trying to handle the corporate applicants that our bylaws allowed at the time.

And, yes, still have the legal name bit - bit also I'm sure we discussed adding something about "names by which an applicant is likely to be known".

Legal Name / Personal Name / Name by which the person is commonly known

something like that?

(I did a wiki search)

X.500 commonName

So we had a discussion about people putting in a real name, but not the nickname they generally use - when that nickname itself couldn't be connected to their real name. This has meant in one case that someone didn't get voted on (they didn't mention the nickname by which everyone knew them), for instance.

Yeah, the Bear case

I actually meant the Mike Taylor case, but yes.

Although I do think we shouldn't base or policies on that incident.

we discussed earlier that having legal/personal names could be required, as members can be elected in positions of legal meaning.

legal status?

you know what I mean.

Having a suggestion that it's sane to mention if you use a nickname is probably sensible

I'm not sure if the state of Delaware would allow for officers to serve when they're only identified by a nickname, or are anonymous.

I think we need not even have the suggestion, to be honest.

everyone keeps bringing up this one incident

this shall not happen again (and to be honest, if it does, that's pretty silly)

I mean like an implementation note, not a formal requirement.

i won't object, but seems over the top to me. *shrug*

I'm not using my full legal name either fwiw :x

:O

Zash: you got me I'm a fraud ✏

Ok, how does a XEP author request an LC?

MattJ: ask Council typically

MattJ, I think the Approving Body needs to request an LC

at least for protocol XEPs

I don't think this is really well documented

I think it is in XEP-0001

s/well //

It is, and it isn't

(maybe because it’s not the authors job to request an LC)

(formally)

So the council just decides one day?

Why haven't they decided about my XEP-nnnn?

I think the process is a bit poor here

The council, especially these days, is pretty much reactive in my experience

Needs moar vision

MattJ: the Council always was reactive

Ge0rG, in the early days the council was more active I think

Except for individual Council members who have or had an agenda, which they are perfectly able to pursuit with their non-Council hat on.

Meetings used to be twice as long as they are today, for a start :)

They can't pursue it with a non-Council hat on, since as jonas’ said, Council is the one that decides on the LC

MattJ: yes, but the author can ask the council to vote on an LC, and the council will

I'm not currently on Council, and as an "outsider" it's not clear anywhere how to get my XEP to LC

I'm not even sure whether Council would issue an LC without the author asking for it.

so it looks like we need a PR for XEP-0001, and a Board vote.

In my experience they rarely do (and many deferred-but-widely-implemented XEPs to prove it)

MattJ: how is Council supposed to know when an Experimental XEP is ready to advance?

XEP-0313 is one of the deferred-if-not-for-a-typo XEPs btw

Yes, and this is a process violation.

At least according to how we perceive the process.

If XEP-0313 is not on the council's radar for an LC, I don't think there's much hope for any other XEPs :)

I'm happy if the answer is "the author should typically request an LC", but as I said, this is not documented anywhere

`select * from xeps where status == deferred order by date`

I think in the past it wasn't necessary, as there was more overlap between Council and Authors, and Council were more proactive in driving the process

I'm not saying it's necessarily bad that that has changed, it wasn't an approach that necessarily scales well

But I think we do need to make it clearer to authors (or anyone) that they should ping Council for LCs

MattJ: what you are saying is that due to the overlap, it wasn't possible to see whether the LC was demanded with the author-hat or with the council-hat on.

Yes, I guess I am

MattJ: and I agree with the latter statement, which is why I was calling for a PR against 0001

With due process, this is a Board topic.

Not that it really mattered, but I think XEP-0001 assumes the Council hat, which doesn't apply for a reactive Council

Sure, I can add it to Trello

MattJ: being a Council member, I'm not sure what would enable me to ask for an LC on somebody else's XEP, except maybe when 12 months have passed and it would become Deferred otherwise

Pretty sure you're free to suggest an LC at any time, on anything

MattJ: so the only alternative I see to "author must ping Council" is "Council must cast an LC vote on deferral"

MattJ, Ge0rG, I take it as: council should make a point out of looking at one deferred XEP a week to decide what to do about it ✏

MattJ: but there is no item on a Council member TODO list of "review all experimental XEPs for a potential LC", and that would be O(fucking much work)

That would be a nice move to clear up the backlog, and deferred XEPs should be reviewed as they are deferred also

xeps->collectgarbage()

Ge0rG, then I think author (or implementer) initiating is fine

Didn't this happen recently? Some XEP got deferred and someone had a minor panic on standards@

I’ll set up a script which randomly picks a deferred XEP a week and submits it to council agenda

and the reply was "Don't worry, this XEP won't slip through"

jonas’: NOOO!

jonas’: 👍

MattJ: if the author can't keep the XEP from being Deferred, why is Council supposed to keep track of that?

$ curl https://xmpp.org/extensions/xeplist.xml | xml2 | 2csv xep-infos/xep type status |stats | head -n5 155 Standards Track,Deferred 77 Standards Track,ProtoXEP 63 Standards Track,Draft 31 Standards Track,Retracted 29 Standards Track,Experimental

Speaking with my overworked-council-member hat on, authors have an effort of O(1), we have an effort of O(N). I disapprove of any process that increases my load because authors don't care enough about their piece.

https://trello.com/c/BXijmEEc/329-clarify-how-to-initiate-a-last-call-for-experimental-xeps

What's the question?

Ge0rG, I think Council looking at a Deferred XEP each week would not only benefit advancement, but also the proficiency of Council in the protocols which exist

Ge0rG, I'm 100% fine with that approach, I don't want to burden Council (though perhaps some one-off initiative to skim and clean up a backlog of deferred XEPs may be warranted)

which is kind of a must-have to judge ProtoXEPs

and it’s not *that* much workload, is it?

Ge0rG, I lean towards LC requiring an explicit action from someone (author or implementer, or any member perhaps)

jonas’: so let's assume we have a look at a random deferred XEP a week. What's the expected outcome?

MattJ: +1

O(n+1) == O(n) right? :)

MattJ: I'm not absolutely opposed to "any member", but I also don't see the point

Ge0rG, one of "it needs work by author, blacklist for random looking at until it was Un-deferred", "it should be LC’d, issue an LC"

I'm missing the context here (and no time to scroll back). This isn't what the procedure is for going to LC (which is well defined, I think), but how to make Council consider something for LC?

Kev: exactly

Kev, correct

Kev: the rules are that Council can issue an LC, but we probably won't do that on our own

And 'someone asks Council to consider it' isn't enough?

Kev: not documented

Kev, that part isn't documented

Does it need to be?

jonas’: "it needs work by author" is implicit, and "work by author" might well be "ask for LC"

Kev, given a large number of deferred implemented XEPs, I'd say yes

jonas’: also the author might have a large modification pending, so issuing an LC might well be counterproductive

MattJ: You believe XEP1 saying "Council will consider LCing when someone asks them to" would cause that not to happen?

which is also why I'm opposed to "any member might ask for an LC" and tend to restrict that to author/implementor

Kev: 🍿

Kev, no, but it's a start

Ge0rG: I don't see a reason to limit the number of people able to ask for an LC. You give reasons for an LC not to be issued, not for it to not be considered.

(3 negations in a sentence. Take that, English non-natives) ✏

we'll be impressed at 4+, Kev - this is not amateur hour.

(we shall also be simply guessing as to what you're trying to say at that point)

I couldn't possibly disagree with you less.

MattJ: FWIW, I don't think the issue of stuff being Deferred is that people are sitting there thinking "Well, I'd like to get this into a Last Call, but I don't think I'm able to ask for that", so I'm not sure that changing Xep1 here helps in any significant way, but I also can't see why adding "Council will consider LCs when asked" should be harmful.

Kev, I don't think they are actively thinking that, but I don't think it's either clear to anyone that this is what needs to happen

That's the subtle difference between what you're suggesting I believe and what I actually believe

I think putting something into xep1 is a fairly inefficient way of getting it into the collective consciousness. Xep1 is great as a 'how do I' but otherwise I don't think people usually memorise it.

Yes, I definitely agree with that - but as I said, it's a start

If we agree that this is what the process looks like, let's make sure it's documented in XEP-0001

I think a more effective start might just be mailing standards@ saying "Anything that should be LCd?".

and then we can move onto the collective consciousness

Yes, that is sensible too

It might be highly informative to ask Authors of Experimental or Deferred XEPs what they think is preventing advancement at the moment.

I wonder if many XEPs slide off to "deferred" as a consequence of us being 'done discussing' without an explicit "ok, let's advance it" comment.

I like Kev's idea of a poll of sorts.

Kev [14:07]: > It might be highly informative to ask Authors of Experimental or Deferred XEPs what they think is preventing advancement at the moment. Is that kind of a Last Call?

Heh

XEP-0379 is largely ready, except for the boilerplate, but it seems nobody cares enough.

Ge0rG: An anti-LC, yes.

would it be helpful to have an (automated) "so, what's next for this XEP?" question go out to an auther/memberlist X days after a state change?

Kev: anti as in anticipation?

Guus: yes. I propose after six months of no activity

Or maybe 3 months, because we want to accelerate

(not counting editorial activity? 😉 ) ✏

Guus: heh!

It might actually be useful to have something like the Tao Of The XSF. An explanatory guide to the workings of the XSF which is a companion to XEP-0001, rather than trying to formally codify everything.

+1

We have The Tao of XMPP, don't we?

Or does it not fit in there?

I made https://github.com/xsf/xeps/issues/733, but I now realise I can't set the "Needs Council" label on it.

Help me, jonas’ - you're my only hope.

Not strictly true.

Or, maybe true outside the context of this desire.

:-)

When is the summit dinner thing happening again? Is it Thursday or Friday or none of the above?

Thursday

Also dinner means evening right? I know quite a few English people using it to say lunch

The one time I attended Summit dinner, it was in the evening

:)

Yes, evening

During the day, we lunch at Cisco

dwd, hm, I’m not sure I’m fond of xsf/xeps being used as tracker for council

although one could argue that this issue is very close to a PR

I understand your concern, but think of it this way - once voted on, the issue is for the Editors to act upon.

true

dwd, wanna reclaim your throne at IRF? 🙂

(chat now)

or meet, rather

jonas’: I think it's requesting a change to the XEPs.

(Just one that Council must first approve)

So it doesn't seem desperately inappropriate, to me.

I agree

MattJ, from XEP-0335: > The <json> element MUST only contain character data, and the data MUST conform to RFC 4627 [3]. Specifically, the element MUST NOT be empty, as the empty string is not valid JSON. The data MUST be encoded as UTF-8 (though officially unspecified, this is the de facto encoding for JSON today).

this wording does not make sense

XML character data is a sequence of codepoints

you can’t put UTF-8 into a sequence of codepoints in a way which makes sense

Spoken like a true Python developer :)

don’t make me say unfriendly things ;-)

I think you have a slight technical argument, but I don't know if just dropping this text is the right thing to do

Given that there is no standard encoding for JSON, and XMPP is defined as always UTF-8

It seems like something that ought to be highlighted

no

the XML library will give you the character data in whatever encoding is convenient for your language

XMPP is defined as always UTF-8

You're both correct.

and this XEP concerns XMPP, not your language

Unicode codepoints need to be encoded somehow. I can write [U+13DA] [U+13A2] [U+13B5] [U+13CB] [U+13A2] [U+13CB] [U+13D2] on a piece of paper and those are Unicode codepoints, but that's not helpful to a computer.

MattJ, what happens on the byte level is irrelevant to the XEP

Hi peter! I have a task for you!

Ge0rG, unfair!

You'll get it in some arbitrary encoding depending how unhelpful your language/libs are. But what is written on the wire is UTF-8 encoded.

> what happens on the byte level, stays on the byte level

Kev, exactly

and that’s why it doesn’t make sense to specify what encoding the JSON data inside the <json/> is in.

And the XEP is saying (as I read it) that when you serialise these data, you must serialise them as UTF-8. I don't see a problem with that.

it is not at all encdoed, on a logical level, between the JSON output and the input to the XML library

it's UTF-8 *below* XMPP, and _implementation defined_ *above* XMPP.

It's just being consistent with XMPP.

Kev, then it should simply omitted

Also, Hi Peter.

to avoid confusion

jonas’, what confusion could arise?

and to avoid people in laguages which make that type of mistake easy double-UTF-8-encoding the data.

jonas’: If we omitted all the bits from specs that people /should/ realise, we'll end up in a terrible terrible place :) ✏

info which would be *useful* to implementors would be: > The <json> element MUST only contain character data, and the data MUST conform to RFC 4627 [3]. Specifically, the element MUST NOT be empty, as the empty string is not valid JSON. Implementations must ensure that the JSON encoder and the XML library use the same character encoding on the interface between them. ✏

(intentional lower-case "must" since it doesn’t happen on the wire)

That text seems less helpful to me.

I could be using an XML library which uses arrays of 4-byte integers to represent the character data. putting UTF-8 encoded JSON in there will not work.

(or I could be in JavaScript, where all strings are UTF-16, the worst of all worlds)

Nor does the XEP suggest it should.

Just that what's written on the wire is UTF-8.

no, I don’t read it that way

it is talking about character and JSON data all the time

that’s definitely above the XML layer

(read: after the UTF-8 from the wire has been decoded into a representation of unicode codepoints chosen by the library)

That XEP is missing the most obvious example of `{"evil":"</json>"}`

I agree with jonas’' reading here. The XEP requires that you put the JSON library output UTF-8 bytestring into the character stream of the XMPP library input.

which is either resulting in a TypeError (Python3, maybe others), or double-encoded garbage. which will only be noticed once you leave the ASCII range.

AFAICs, this text stops you doing something stupid like encoding UTF-16 JSON into UTF-8 XML character entities, and then the receiver trying to decode the JSON as UTF-8.

Ge0rG, I don't think it's saying that at all

Kev, what are UTF-8 XML character entities?

the XEP should not be telling me how to use my XML library.

I mean byte encodings :p

and I disagree that it's doing any such thing

MattJ: > The <json> element MUST only contain character data [...]. The data MUST be encoded as UTF-8

Ge0rG, where does it say "that you pass to your XML library"?

MattJ: in the first part I quoted.

MattJ, if this is not about what is passed to the XML library, the sentence is at the wrong place, and confusing (as you can tell by our two readings)

Well, since I was co-responsible for the creation of the XEP, it should be like this in Python 3: the `str` serialization of JSON should be used as the XML text node contents.

peter: awwww....

(the right place is RFC 6120, where it’s already written down)

ralphm, that’s "obvious", but I don’t think that’s the only valid (and likely) interpretation of the text.

So yes, it is about unicode code points vs. UTF-8, and only a handfull of people really understand the difference

we should really link https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ from all the XEPs.

ralphm: right. And making incorrect claims in the XEP won't improve that.

I await the PR

I suggest adding an implementation note box saying that JSON libraries typically work with UTF-8, which also happens to be the encoding _underlying_ XMPP

jonas’: Weren't you arguing that stuff people should realise shouldn't be included in XEPs?

Kev, no, that’s not what I was trying to say

what I was trying to say is that XEPs operate on top of RFC 6120 XMPP (unless they modify core behaviour, like XEP-0138, or something like that). Thus, we’re dealing with the application side of XML. Thus, the encoding of the data *on the wire* is 100% irrelevant to what the XEPs are doing.

we could change RFC 6120 to mandate UTF-16 with surrogates and it should not change the wording of a XEP which operates on a high level such as XEP-0335

If you want to be really pedantic, you should also say that we're talking about the XML line protocol with TCP binding for XMPP.

because the XML library has already taken care of converting the encoding from the wire to whatever is useful in the language

Kev, just like you wouldn’t be saying that you have to escape < to &lt;. It’s implied in "you’re using XML, and you’re putting something into XML character data".

jonas’: > That XEP is missing the most obvious example of `{"evil":"</json>"}`

Oh, but I might say something like that (although not that specific example, obviously), if we were talking about delivering XML payloads inside XMPP.

if you don't bring that example, people will string-concatenate the JSON to the XML.

Which is a thing that happens and catches people out

So let's go with making sure that once serialized into UTF-8, the application programmer should make sure it is correctly decoded into the in-memory text format that should be the import of its XML library's text nodes.

Kev, you could do that by saying "encode the XML payload to text and put that text into a XML text node"

ralphm: which is a convoluted way to say what jonas’ suggested as the alternative wording ;)

Ge0rG: you can't prevent people from doing string-concatenation anyway.

the library will do all the escaping needed to transport text.

ralphm, no but that example can raise some awareness

pep.: 👍

"the library" - I think you're assuming particular implementations.

ralphm, I suggested to modify the paragraph to: > The <json> element MUST only contain character data, and the data MUST conform to RFC 4627 [3]. Specifically, the element MUST NOT be empty, as the empty string is not valid JSON. Implementations must ensure that the JSON encoder and the XML library use the same character encoding on the interface between them.

also ]]>

Kev: aren't you assuming particular implementations if you imply that the XMPP parser will emit UTF-8 for the element content?

Kev, no, that ("XML character data is an array of codepoints") XML Standard behaviour.

And also, there's nothing wrong with string concatenation.

jonas’: Yes. You're assuming that XMPP data is coming out of an XML library. No reason it needs to be (and it often isn't).

Kev: string concatenation of structured data is what gets my dinner paid.

Kev, no, I am assuming XMPP operates on top of XML

and I sure hope that assumption is not wrong.

jonas’: luckily, you only need to convince one Council member ;)

What does 'on top of XML' mean?

that XMPP is a higher-level abstraction, and its underlying abstraction is a stream of XML

You said about 'the library' doing things for you, I'm just pointing out that there need be no 'XML libraries' involved in serialising XMPP.

Kev, I grant you that

aioxmpp itself isn’t using any XML library to serialise it

so let me reword things

> The <json> element MUST only contain character data, and the data MUST conform to RFC 4627 [3]. Specifically, the element MUST NOT be empty, as the empty string is not valid JSON. Implementations must ensure that the JSON data is encoded in a format suitable for transporting character data with the underlying XML implementation.

> Specifically, the element MUST NOT be empty What about a string containing only whitespace?

Ge0rG, in json? that would be " "?

Ge0rG, one thing at a time, maybe?

jonas’: I liked your first suggestion better.

I could also use the first suggestion and s/library/implementation/

Personally I think I'd rather just drop it

MattJ, I’d be fine with that, too

pep.: no, I don't mean a JSON string containing only whitespace, I mean something like `<json> </json>`

jonas’: +1 for "implementation"

I find that last sentence about implementations and encodings more confusing than it's worth.

I might also suggest reading https://tools.ietf.org/html/rfc6365 on these topics

Ah yes

Why not: The <json/> element MUST only contain character data, and the data MUST conform to JSON text as defined by RFC 4627.

(JSON text is defined in terms of codepoints via ABNF, and is thus prior to the encoding defined in §3 of RFC 4627)

dwd, that sounds very useful

https://tools.ietf.org/html/rfc8259 is the most up-to-date JSON RFC

is anyone using that json stuff?

within xmpp i mean

I've been hearing a lot about JSON recently. ;-)

The J in JSON is for Jabber!

Or was it the other way around?

Like the X in Matrix is for XMPP

Ge0rG: What was the topic you wanted to discuss earlier?

Monolithic Awfully Trendy Re-Implementation of XMPP

ah

peter: I've asked for a trademark permit some time ago

I haven't followed that project and don't know much about it.

Ge0rG: I sent you an email reply about that perhaps an hour ago. :-)

i've got a notification from yxim, because the is an oli in monolithic

peter: only to later realize that you need the 500$ license for an organization, regardless of the legal form.

peter: oh cool, haven't checked yet, will do

Ge0rG: OK good.

And yes, best to avoid the organization route if possible. I don't see that it's necessary in this case.

Ralph and Guus pinged me about on our video chat earlier.

Anyway, see email for details.

peter: SPAM is a backronym for Spam Prevention and Abuse Management, which is a rather ironic thing and I liked it very much for that reason

I haven’t read the 1644 lines of backlog yet (sorry!), but I’ve been wondering whether we should buy a Jabber license for JabberFR too; $500 is way too expensive for us, but we’ve been running the service since approximately 2003 (at least that’s as far the wayback machine takes us).

peter: it's a group of projects related to spam fighting, so an organization seemed most appropriate, but I'm not fixed to that

Ge0rG: Just trying to make it simpler for you. :-)

Link Mauve: not necessary - domains do not require a license, that's fair use.

https://xmpp.org/about/xsf/jabber-trademark/usage-guidelines

We’re not only using it for the domain, it’s the entire name of the association (French law 1901).

peter: sometimes I'm deliberately not going the most simple route. Unless by simpler you implied cheaper... 😉

I realize those pages are written in a somewhat confusing way. We "borrowed" all of that from the Linux Foundation many many years ago.

Link Mauve: ah, interesting, I didn't realize that.

peter: so in the end the decision about trademark use is up to Board?

yes

I just know a lot about the trademark. They make the decisions. :-)

Time for my next video conference, bbiab.

peter: good luck!

just don't use jabber, this trademark sucks

But the name is much better than "ex MP pee", and I can't afford to sponsor a re-branding for the whole thing.

may we ask the board to drop the trademark?

or the licensing fee?

oli: the Trademark belongs to Cisco, after they bought Jabber Inc, a very long time ago. The XSF merely has a right to sub-license it. Please read up the Trademark pages on xmpp.org

ah okay, i missed the cisco part

so jabber is owned by evil corp

too bad

oli: it's complicated™

What a bundle of joy here. 😀

Ge0rG: even though the decision lies with board, Peter has by far most experience here. Board is likely to pay close attention to his recommendations.

Guus: I wouldn't have expected anything less

But I don't know yet how to turn "don't make your org an org" into something actionable

Guus: do I need to do something or is Board in a position to move things forward now?

where does the information with the $500 come from?

Ge0rG: as an organisation? I'm unsure if it can be avoided to charge you then.

because I cannot find it on https://xmpp.org/about/xsf/jabber-trademark/usage-guidelines

jonas’: website. That lists the trademark licence process

https://xmpp.org/about/xsf/jabber-trademark/trademark-license-agreement.html

I believe that there's more, but I'm tired and on mobile

I am confused

Guus: if changing my application type from organization to ??? will allow me to subvert the license payment, this brings up some uncomfortable questions.

jonas’: checked the quote on trello already?

what is the difference between use in a software name under the GPL (§2.1 in https://xmpp.org/about/xsf/jabber-trademark/usage-guidelines ) and in an non-profit org name (§2.2 same document)?

no

jonas’: ah, you found it

I see, where is that quote from?

(this one: > There is no fee required for software and other products licensed under an OSI approved open source license. Otherwise, the fee is $250.00 for use of the mark in connection with Jabber accessories or any use other than software or computer hardware, and a $500.00 one-time fee for use in connection with software or computer hardware or any other type of computer or Internet use of the Jabber mark. ) ✏

ah, from "what’s required"

https://xmpp.org/about/xsf/jabber-trademark/whats-required.html

I'm tuning out for tonight guys. My mind is blank at the moment.

Guus: have a pleasant night!

jonas’: so I can circumvent the license *fee* by making JabberSPAM an OSI licensed project, but I don't know how to map that to a github org ✏

jabbercat also has an github org

first search result for jabberspam is: https://github.com/dorosch/jabber-spam-bot

so you can be an organisation with an open source product called jabberspam without paying any licensing fee? is that correct?

oli: I'm as baffled as you are. I hope the Board will clarify that next Thursday

So, how is the "gather experience with full-stanza-encryption for OMEMO using OX" going?

also, what sort of thing do expect to learn through experience?

Gajim is already implementing it right, I haven't had a look yet at what it puts inside

And how it deals with merges