nice, now the work laptop is playing a snippet of metal in a very tight loop
jonas’
trying suspend-then-hibernate wasn’t a good plan
jonas’
ok, with that disturbance out of the way...
jonas’
3) Editor’s Update
jonas’
- XEP-0045 v1.33.0 which removes 307 status code from service-caused kicks (as opposed to moderation-caused kicks)
jonas’
4) Items for Voting
jonas’
4a) Discuss whether PR#971 was rejected on false premises
Sorry for this one. Flow brought up -- correctly -- that type="cancel" is special and we should discuss real quick if that changes anything for the folks who vetoed.
jonas’
since XEP-0004 states:
> a data form of type "cancel" SHOULD NOT contain any <field/> elements.
I think some of the arguments in my original email regarding this topic may be invalid
jonas’
since others based their vote on those arguments, please reconsider
jonas’
and let me know if we should re-vote on this one
Zash
I'm staring at a diff right now .
Ge0rG
I'm still unconvinced whether removing text adds clarity.
Zash
So.
jonas’
trivial example of where removing text adds clarity:
> The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types.
vs.
> "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W and X.✎
jonas’
trivial example of where removing text adds clarity:
> The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types.
vs.
> "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W only. ✏
jonas’
or something similar, you get the gist :)
daniel
I'll read this again
daniel
The diff format with extremely long lines also makes this super hard to read
Ge0rG
jonas’: so the answer to your question is probably: we should re-vote #971
jonas’
re-writing my email from back then, I arrive at:
Let me break this change down using the word diff (attached: ab.wdiff, pipe it
through colordiff(1) for best viewing).
Before:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit": @type MAY, absent assumes available context(*)
- type="result": @type MAY, absent undefined
- type="error": SHOULD NOT have any fields, @type MAY
After:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit", type="result": @type MAY, absent assumes available context(*)
- type="error": SHOULD NOT have any fields, @type MAY
(*): It is assumed that the recipient of the form has enough context to infer
the @type value. Bad design IMO, but we’re stuck with that.
So while the PR reduces the amount of text, it introduces undefined behaviour
for @type="error", which I don’t endorse.
✎
jonas’
re-writing my email from back then, I arrive at:
Let me break this change down using the word diff (attached: ab.wdiff, pipe it
through colordiff(1) for best viewing).
Before:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit": @type MAY, absent assumes available context(*)
- type="result": @type MAY, absent undefined
- type="error": SHOULD NOT have any fields, @type undefined
After:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit", type="result": @type MAY, absent assumes available context(*)
- type="error": SHOULD NOT have any fields, @type MAY
(*): It is assumed that the recipient of the form has enough context to infer
the @type value. Bad design IMO, but we’re stuck with that.
So while the PR reduces the amount of text, it introduces undefined behaviour
for @type="error", which I don’t endorse.
✏
jonas’
and I think I prefer that a lot and would also suggest to re-vote
jonas’
daniel, hence wdiff + colordiff
Zash
+ aha | htmlpaste
jonas’
:)
jonas’
I’m still in favour of my patch though, because that handles the case where an entity violates the SHOULD NOT for type="error" and clearly spells out what’s going on
jonas’
I guess I’ll propose my patch as separate PR and then we can vote on both?
daniel
Sounds good
Ge0rG
jonas’: great
Zash
Sure
Ge0rG
and maybe Zash can provide a rendered html-diff of it ;)
dwdhas joined
jonas’
https://github.com/xsf/xeps/pull/975
dwd
Gah. Afternoon, sorry for being late.
jonas’
oh great, dwd
jonas’
I suppose you’ll have strong opinions regarding how we should handle Process here
Ah. So there's nothing that prevents us doing so, but unless new things have come to light I feel a little concerned about doing that.
jonas’
(hoping that none of us has red-green-weakness)
Ge0rG
dwd: new things like the realization that the first voting Member was wrong, and the other ones just copy&pasted the rationale?
jonas’
dwd, I expected as much. Do you think that new things did indeed come to light based on what I wrote earlier (in the agenda announcement and above, I shall quote from above):
since XEP-0004 states:
> a data form of type "cancel" SHOULD NOT contain any <field/> elements.
I think some of the arguments in my original email regarding this topic may be invalid
since others based their vote on those arguments, please reconsider
jonas’
or as Ge0rG put it, indeed
Zash
jonas’: Main difference is extra noise and lack of line breaks in paragraphs.
Ge0rG
jonas’: I really like your wording as displayed by Zash's colored "html" version
jonas’
that’s not my wording tho?
jonas’
that’s flows wording
Zash
That wasn't jonas’
dwd
Ge0rG, Well, there's a good argument to avoid "me too" veto votes, of course. :-)
Ge0rG
dwd: yes, I'm guilty of that. But the rationale that was provided really sounded convincing back then!
jonas’
it’s easy to construct convincing-sounding rationales for '4, '45 and '60.
jonas’
(and probably '369 et al. too)
Ge0rG
whoops.
jonas’
though I’ll clearly state that this was not my intention and I simply wasn’t aware of the type="cancel" specialcasing
Ge0rG
So I really like flow's wording then. Can we also get a pr975.html, please? Zash?
dwd
I like the table. ISTR I was on-list because I was confused about what the wording used to say and what it now says, which at the very least suggests that the wording needs improvement.
we’re close to the end of the meeting and everyone is confused
dwd
But if I understand correctly, we're happy about the intent in flow's PR, just not so much about the wording?
jonas’
I am
jonas’
as I said in my original email
jonas’
I take that we should re-vote on PR#971 and/or PR#975 next week. Please read carefully everyone, I’ll update PR#975 with a more major reformatting after this meeting (taking the suggestion to pull my "table" from the email into the document)
+1. Having (a) moved my XMPP server to AWS off the machine that was failing, and (b) moved DNS to a machine with IPv4, I might even be able to join properly.