In that case, I'll vote +1. As far as I can tell, doing otherwise will break several implementations including anythign based on Smack.
jonas’
dwd, as-is or with s/MUST/SHOULD/?
dwd
jonas’, Personally I'll go with as-is. I think this is the original intent, and early implementations appear to follow it.
jonas’
OK
jonas’
FTR, what Drew describes on-list is exactly the behaviour of aioxmpp on the client side.
dwd
jonas’, I do appreciate others may disagree.
jonas’
we need at least two more +1s anyway
dwd
jonas’, FTR, if you're consuming that way it doesn't matter. Producing, it matters more. Forwarding, though and this seems flat-out wrong.
Ge0rG
there was a really long thread that I didn't catch up yet :(
jonas’
dwd, aioxmpp may very well produce forms, and that’s what I’m talking about here
jonas’
dwd, agreed though that forwarding shouldn’t touch such things and that the implementation of them has serious issues.
Kev
I don’t think breaking Smack is a motivation to do things, but I think creating the headers after the content is probably broken.
daniel
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
Zash
The thread looks to me as if it has rough consensus in the +1 direction, so I'll vote +1.
Kev
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’.
jonas’
daniel, agreed, too
Kev
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.
Kev
Doesn’t it say something like “the data following the headers” or somesuch?
aosanhas joined
Wojtekhas left
Ge0rG
so we decide that it's okay to break implementations that don't follow that?
dwd
Kev, Yeah. I think it's not very clear, but the intent is there.
Wojtekhas joined
dwd
Ge0rG, Or else we decide its OK to break implementations that rely on it.
Ge0rG
dwd: right. but those implementations didn't have a written right to rely on it.
jonas’
so I’m really reluctant about the MUST because this is Final
Ge0rG
only a vague implication
jonas’
if it was Draft or Experimental, I’d say go with it
Ge0rG
still, I'm okay with making the vague implication a formal requirement
jonas’
and yeah, I did not read the text as "the order on the wire must be that" either, so it’s at least ambiguous
daniel
> if it was Draft or Experimental, I’d say go with it
Yes. (obviously)
Ge0rG
what about adding a note about earlier versions of the XEP not strictly mandating order?
jonas’
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*.
Wojtekhas left
jonas’
Ge0rG, yes, that
dwd
I'd also be OK with a SHOULD. That would still mean aioxmpp and ejabberd needed a bugfix though, so it's somewhat moot.
Wojtekhas joined
dwd
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"
Ge0rG
so -1 for the MUST as-is, +1 for either MUST with an explanatory textbox, or +1 for SHOULD
jonas’
Ge0rG, would you be so kind to provide that text box?
larmahas joined
Ge0rG
"rodering" is a nice word.
jonas’
the editor normally would but they’re short(er than usual) on time currently
dwd
Ge0rG, My language, I can do what i want with it.
daniel
I think I can get on board with a should
Zash
sgtm
daniel
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)
jonas’
SHOULD + textbox?
dwd
daniel, Noting that SHOULD is not the same as MUST (BUT NOT REALLY), why is SHOULD OK here?
jonas’
I have the file open now… I’ll just make a patch
daniel
But should feels less bad when changing a final xep
Kev
“Many implementations”? :D
Ge0rG
> 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.
daniel
dwd: feelings
Ge0rG
jonas’: ^
aosanhas left
Ge0rG
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!
dwd
Kev, It's not clear to me how many implementations are actually affected on either side. But it's non-zero for both.
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 :)
jonas’
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
dwd
jonas’, Well, that's a problem in itself, really, isn't it? :-)
jonas’
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.
dwd
jonas’, (And I was going to open that can of worms in AOB actually).
Zash
I don't think I can handle any cans of worms today.
jonas’
I pushed a patch onto https://github.com/xsf/xeps/pull/1032, will write the mail asynchronously.
jonas’
we’ll thus "cancel" the vote and re-vote on the updated diff next week after list feedback?
dwd
+1
jonas’
(we don’t technically have to cancel, I’ll just -1 and we vote on the new diff)
Zash
+1
jonas’
-1 because the new diff looks better considering the current state of the world
jonas’
alright
jonas’
IWE is pretty much vetoed, so we can move on to the other formalities and AOB
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.
aosanhas joined
jonas’
mmmhm
jonas’
I agree
dwd
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.
dwd
(And ending up starting the clock a lot earlier than seems useful)
jonas’
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.
daniel
Can or should we make standards subscribe to github PRs
daniel
Or something
jonas’
daniel, no.
jonas’
not without pre-filtering by the Editor
jonas’
(my opinion on that matter as a standards@ reader and editor)
jonas’
it would be nice if things which are tagged Needs List Discussion / Needs Council got annoucned automatically though
jonas’
I currently don’t have the capacities to work on that
dwd
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.
jonas’
dwd, that’s an interesting way to put it
Zash
Subverting the Github flow? I approve
jonas’
I can’t see any significant issue with that
jonas’
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.
dwd
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.
daniel
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
daniel
> 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
dwd
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.
aosanhas left
Kev
If I say it, it’s not controversial. Anyone who disagrees is themselves trying to be controversial.
dwd
daniel, Gets fairly messy if it's one of us that makes a PR and convinces the rest of it's uncontroversial.
jonas’
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)
jonas’
I don’t like the arbitration we have to do about whether something is controversial either, so I’d like to pilot this ASAP.
dwd
I'm not sure I like that choice of assignment operator, but otherwise it's all good. :-)
jonas’
:>
Zash
Sounds good
jonas’
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)
jonas’
dwd, is that better?
Zash
UNCLOSED TAG!!!!!
jonas’
Zash, not true!
Zash
oh
Sam
No root node, not a valid document.
jonas’
Sam, shush!
dwd
Heh. I read that as "<rat hole=...>" and thought it was very fitting. :-)
Sam
Maybe it's HTML.
jonas’
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.
dwd
I'm not sure if it's Council Chair or Editor you want, mind, but seeing as you're both...
Sam
(jokes aside, I forget why I popped in today, but this is an interesting discussion and seems like a good idea, thanks all)
jonas’
dwd, yeah, I’m confused about that, too
dwd
(I mean, which role places things on the agenda officially?)
jonas’
dwd, the chair compiles the agenda
jonas’
I think
jonas’
but I don’t know
dwd
Nor will anyone else, so we're fine.
jonas’
I think so, too
jonas’
any other AOB?
daniel
None here
Kev
The Chair assembles the agendums. Definitely ;)
jonas’
alright
jonas’
8) Ite Meeting Est
Zash
Thanks jonas’, Tedd, all.
dwd
jonas’, Thanks, and sorry for my contributions to the overrun!
jonas’
thanks everyone, thanks dwd for that neat idea, thanks Tedd for the excellent minutes of the last session
jonas’
dwd, no worries!
jonas’
(from my side anyway)
Kev
Uhm.
Kev
I don’t think “Dear list,” is a valid XML preamble.
jonas’
Kev, Sam brought that up already, you’re late to the party
jonas’
:P
Kev
He can’t have.
Sam
Needs a mime type or something. Must be HTML, but autodetection is likely to lead to errors.
Kev
Because the mail only just arrived, and it’s the mail to standards that starts the discussion.
Kev
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.