XMPP Council - 2021-02-17

1) Roll Call

Hi

Hi

Hello

dwd?

let’s start

2) Agenda Bashing

assuming no complaints

3) Editor’s Update

nothing to report

4) Items for voting

none that I know of, did I miss anything?

Oh, sorry, didn't notice.

Are we up to date with the data forms PR?

That's expiring .. now, right?

yes it is

what do you mean by "up to date"?

Have any of us voted?

I did

nobody else AFAIK

(I voted -0 yesterday on-list)

There seems to be ongoing on-list discussions.

In that case, I'll vote +1. As far as I can tell, doing otherwise will break several implementations including anythign based on Smack.

dwd, as-is or with s/MUST/SHOULD/?

jonas’, Personally I'll go with as-is. I think this is the original intent, and early implementations appear to follow it.

OK

FTR, what Drew describes on-list is exactly the behaviour of aioxmpp on the client side.

jonas’, I do appreciate others may disagree.

we need at least two more +1s anyway

jonas’, FTR, if you're consuming that way it doesn't matter. Producing, it matters more. Forwarding, though and this seems flat-out wrong.

there was a really long thread that I didn't catch up yet :(

dwd, aioxmpp may very well produce forms, and that’s what I’m talking about here

dwd, agreed though that forwarding shouldn’t touch such things and that the implementation of them has serious issues.

I don’t think breaking Smack is a motivation to do things, but I think creating the headers after the content is probably broken.

I see why it is desirable to have it come first. I don't see how the existing text has always intended to do this

The thread looks to me as if it has rough consensus in the +1 direction, so I'll vote +1.

And a forwarding entity that changes order is certainly somewhere between ‘broken’ and ‘I hope it’s a closed deployment where they understand what they’re doing’.

daniel, agreed, too

daniel: Indeed, it seems like the Right Thing, it doesn’t look like the original text necessarily mandated it, but it’s fairly clear it was the intention.

Doesn’t it say something like “the data following the headers” or somesuch?

so we decide that it's okay to break implementations that don't follow that?

Kev, Yeah. I think it's not very clear, but the intent is there.

Ge0rG, Or else we decide its OK to break implementations that rely on it.

dwd: right. but those implementations didn't have a written right to rely on it.

so I’m really reluctant about the MUST because this is Final

only a vague implication

if it was Draft or Experimental, I’d say go with it

still, I'm okay with making the vague implication a formal requirement

and yeah, I did not read the text as "the order on the wire must be that" either, so it’s at least ambiguous

> if it was Draft or Experimental, I’d say go with it Yes. (obviously)

what about adding a note about earlier versions of the XEP not strictly mandating order?

but as this is Final… I think it needs more than just adding a MUST. I think this should have a good rationale and explanation of the change *inside the text*.

Ge0rG, yes, that

I'd also be OK with a SHOULD. That would still mean aioxmpp and ejabberd needed a bugfix though, so it's somewhat moot.

Ge0rG, Or at least, "Many implementations have in the past not strictly enforced this ordering. Implementations are therefore encouraged to be flexible about the rodering"

so -1 for the MUST as-is, +1 for either MUST with an explanatory textbox, or +1 for SHOULD

Ge0rG, would you be so kind to provide that text box?

"rodering" is a nice word.

the editor normally would but they’re short(er than usual) on time currently

Ge0rG, My language, I can do what i want with it.

I think I can get on board with a should

sgtm

I mean after all it's not probably not that big of a deal either way in practice. (somebody jusz needs to fix their code)

SHOULD + textbox?

daniel, Noting that SHOULD is not the same as MUST (BUT NOT REALLY), why is SHOULD OK here?

I have the file open now… I’ll just make a patch

But should feels less bad when changing a final xep

“Many implementations”? :D

> Older revisions of this XEP (before 2.11.1) did not contain an explicit requirement for the ordering between <reported> and <item>. Implementations are therefore encouraged to be flexible when processing incoming data.

dwd: feelings

jonas’: ^

but given that the PR explicitly speaks about the "XML document", and we have an XML stream, and it's not clear whether those are meant to be the same, I would expect that once I receive an <item> on the stream, NO MORE <reported> ARE EVER ALLOWED AGAIN!1!1!

Kev, It's not clear to me how many implementations are actually affected on either side. But it's non-zero for both.

proposed diff: https://paste.debian.net/hidden/7826dc53/

oh, what Ge0rG said seems more reasonable

updated patch: https://paste.debian.net/hidden/1749f7e9/

Either way, if we adding this, we should bounce it back to the list.

should we?

I consider the addition of the box editorial.

jonas’: +1 for your diff

jonas’, Well, Editorial means we don't get to vote on it, not that the community shouldn't have an opportunity for feedback.

updated: https://paste.debian.net/hidden/a8de2ed3/ (s#data#&lt;x/&gt;# to make it unambiguous)

> updated patch: https://paste.debian.net/hidden/1749f7e9/ +1

Do you mean the styling of a box around some text? That seems editorial. Adding some text about implementations and encouraging behaviour definitely isn’t :)

dwd, ok, if you strongly feel so, we shall do that. I don’t see the necessity, given that the list wouldn’t have discussed this diff in the first place if we hadn’t brought it up anyway

jonas’, Well, that's a problem in itself, really, isn't it? :-)

dwd, ok, let’s not open this can of worms. I’ll push my diff into flows branch (if I am allowed to, we’ll see) and bounce it back to the list then.

jonas’, (And I was going to open that can of worms in AOB actually).

I don't think I can handle any cans of worms today.

I pushed a patch onto https://github.com/xsf/xeps/pull/1032, will write the mail asynchronously.

we’ll thus "cancel" the vote and re-vote on the updated diff next week after list feedback?

+1

(we don’t technically have to cancel, I’ll just -1 and we vote on the new diff)

+1

-1 because the new diff looks better considering the current state of the world

alright

IWE is pretty much vetoed, so we can move on to the other formalities and AOB

5) Pending Votes

we did that already pretty umch

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1wwfm

and Ge0rG?

excellent

that’s a quorum :)

(mail sent)

7) AOB

I hear dwd has some ✏

Just noting that the Data Forms discussion on list was very useful, but really only started once voting had begun, which feels pretty awkward - it'd be better to get these things discussed on the list first, and put on our agenda once they're "pre-discussed" so we can just vote.

mmmhm

I agree

I mean, especially when tweaking a Final spec, we seem to start list discussions a lot, and it feels like we're kind of starting the process at the wrong end.

(And ending up starting the clock a lot earlier than seems useful)

it would be good if a few people who are interested in messing with CI infrastructures, webhooks and the likes would get on a sprint and improve the editor pipelines around such things.

Can or should we make standards subscribe to github PRs

Or something

daniel, no.

not without pre-filtering by the Editor

(my opinion on that matter as a standards@ reader and editor)

it would be nice if things which are tagged Needs List Discussion / Needs Council got annoucned automatically though

I currently don’t have the capacities to work on that

Well, we could. Or we could simply tell Standards that things don't get onto the Council agenda unless someone asks for it on-list and therefore starts that discussion.

dwd, that’s an interesting way to put it

Subverting the Github flow? I approve

I can’t see any significant issue with that

it would be nicer to automate things further so that people don’t have to do it and to e.g. auto-include links to the diff and maybe a rendered version (if/when we can have such things), but as a first iteration, I like dwds proposal.

It pushes workload onto the submitter of changes a bit, but encourages them to add a bit of rationale and bring people on side, too, so I feel it's mostly win.

I'm also somewhat fine with the current flow. Council gets to decide on easier, non controversial things and refers back to list as soon as we encounter something that demands more discussion

> It pushes workload onto the submitter of changes a bit, but encourages them to add a bit of rationale and bring people on side, too, so I feel it's mostly win. But yes that's also fine with me

daniel, Yes but it also forces us to arbitrate what is actually controversial in the first place, which seems suboptimal, espeically when we don't have an appeals process as such.

If I say it, it’s not controversial. Anyone who disagrees is themselves trying to be controversial.

daniel, Gets fairly messy if it's one of us that makes a PR and convinces the rest of it's uncontroversial.

Email proposal: Dear list, hat := council; The recent discussion about a change proposal on a Final spec has brought something to our attention which we think is a problem in our process. Specifically, the discussion about the change happened in the broader community only after the Council has started its voting process. If Council had been unanimous about the change, the change would’ve been applied immediately. In order to avoid lack of community participation in the future, the following change in our process is hereby established: Change proposals to XEPs which are under the control of Council do not get put on the Council agenda before there has been a thread on the standards mailing list. The thread is not required to have reactions or replies, but must be at least 48 hours old at the time the council session starts in order to be considered for voting. I hope you can see how this may improve the discussion culture and the process in general. If you have any questions or concerns, please raise them in reply to this email. We are happy to adapt this change if there are issues with it. kind regards, Jonas Schäfer (Council Chair)

I don’t like the arbitration we have to do about whether something is controversial either, so I’d like to pilot this ASAP.

I'm not sure I like that choice of assignment operator, but otherwise it's all good. :-)

:>

Sounds good

Dear list, <hat role="council"> The recent discussion about a change proposal on a Final spec has brought something to our attention which we think is a problem in our process. Specifically, the discussion about the change happened in the broader community only after the Council had started its voting process. If Council had been unanimous about the change, the change would’ve been applied immediately. In order to avoid lack of community participation in the future, the following change in our process is hereby established: Change proposals to XEPs which are under the control of Council do not get put on the Council agenda before there has been a thread on the standards mailing list. The thread is not required to have reactions or replies, but must be at least 48 hours old at the time the council session starts in order to be considered for voting. I hope you can see how this may improve the discussion culture and the process in general. If you have any questions or concerns, please raise them in reply to this email. We are happy to adapt this change if there are issues with it. </hat> kind regards, Jonas Schäfer (Council Chair)

dwd, is that better?

UNCLOSED TAG!!!!!

Zash, not true!

oh

No root node, not a valid document.

Sam, shush!

Heh. I read that as "<rat hole=...>" and thought it was very fitting. :-)

Maybe it's HTML.

I’ll take a quick peek at the cake in the oven and hope that any other negative feedback is raised until I return, otherwise I’ll send that as-is after the session.

I'm not sure if it's Council Chair or Editor you want, mind, but seeing as you're both...

(jokes aside, I forget why I popped in today, but this is an interesting discussion and seems like a good idea, thanks all)

dwd, yeah, I’m confused about that, too

(I mean, which role places things on the agenda officially?)

dwd, the chair compiles the agenda

I think

but I don’t know

Nor will anyone else, so we're fine.

I think so, too

any other AOB?

None here

The Chair assembles the agendums. Definitely ;)

alright

8) Ite Meeting Est

Thanks jonas’, Tedd, all.

jonas’, Thanks, and sorry for my contributions to the overrun!

thanks everyone, thanks dwd for that neat idea, thanks Tedd for the excellent minutes of the last session

dwd, no worries!

(from my side anyway)

Uhm.

I don’t think “Dear list,” is a valid XML preamble.

Kev, Sam brought that up already, you’re late to the party

:P

He can’t have.

Needs a mime type or something. Must be HTML, but autodetection is likely to lead to errors.

Because the mail only just arrived, and it’s the mail to standards that starts the discussion.

For Sam to have already raised it he’d have had to do so in the Council meeting, and that would mean the discussion in Council was before the mailing list thread, which isn’t how we do things.

I’ll just step out of this for a while now

*facepalm* I was too fast.