XMPP Council - 2019-05-08

Kev, IIRC, you wanted amendments to https://github.com/xsf/xeps/pull/784, can you please confirm that the changes Ge0rG made are okay with you?

<nevermind> ✏

Afternoon all.

afternoon, dwd

So:

1) Roll Call.

Here

Link Mauve ?

Hi, I’m here.

I see Georg's partial presence.

Excellent.

2) Agenda Bashing

board wants us to talk about https://github.com/xsf/xeps/pull/780

Was there an agenda?

There was not. So, Kev, you remember that nice little Yaris I used to have before it got hit by an HGV yesterday? Well, something happened to it, see if you can guess why I got distracted. :-/

You driving? Ok?

My son driving - actually not so much driving, sicne the handbrake was on. No injuries, walking pace collision, but the car has received substantial unexpected remodelling.

oh dear, thank $deity

Quite.

Ow.

But anyway, that's my exciting news. Given the cheapness of my cars, it's probably an insurance write-off.

So - #780 - anything else?

not that I knew

(that's the same son that is a pilot?)

That AOB discussion from two weeks ago? I tried to remind the List, but it failed similarly to what Kev attempted

Guus, Yes. Better a minor car crash than a minor aircraft crash. :-)

Ge0rG, what was the AOB again?

3) Items Not For A Vote:

a) https://github.com/xsf/xeps/pull/780 (Editorial changes and XEP state)

I am +1 on that one for obvious reasons

Why are you +1 if it's not for a vote?

I’m not sure if it’s for a vote or not, and this expresses my intent unambigiuously either way :)

My comment still stands that we have a definition based on versioning here already, and making that clearer would be good. Instead of the suggested wording.

Seve's point is interesting. Are you intending to mean that if a XEP has a substantial edit in (say) April, and a series of edits considered Editorial subsequently, it would still be moved to Deferred in October?

Kev, I’m still not sure we do, technically

dwd, yes

jonas’: XEP-0001 is only concerned with substantive edits (x.y), not the x.y.z versions we use for editorial stuff.

I'd rather we codified the use of x.y.z in XEP-0001 for Editorial changes.

dwd: Believe it or not, based on the versioning requirements, that's what XEP-0001 already says.

that’s what I meant by "So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff." ✏

if you folks think that needs more explanation and should be made clearer, I can put it on my todo to write that down

Kev, I believe you. But Seve's point is that the way that reads is that you can make a substantial edit to a document which causes it to be deferred.

an edit can never cause a document to be deferred

time does

Yeah, removing the “or to” part would seem sensible.

jonas’, I think I lean toward defining versions properly and unequivocally, and then I think this particular change/clarification falls out of that automatically.

okay

so I’ll go ahead and do that

Link Mauve, Except an editorial change is intended to leave the move *to* Deferred unaffected, so ...

jonas’, Sorry for making more work for you.

it’s alright

I have been thinking about that one anyways

That phrasing is not perfect, I agree with Seve

and yeah, that phrase is a weak spot in the diff

will fix both

dwd, “[…] for the purpose of considering moving a XEP back from Deferred state, or keep it there.” maybe?

Link Mauve, As I say, once you define versioning clearly, I don't think it matters anymore.

I think it’s more effective when I draft up an alternative wording and we discuss it

So:

jonas’, agreed.

b) That AOB That Georg Raised A Few Weeks Back.

Ge0rG, what was it even about?

> Purely editorial changes (e.g. version updates from 0.1.1 to 0.1.2) count as <em>activity</em> (or <em>updates</em>) do not effect the Deferred state or deferral time of an XEP.

it was about fixing 0184 properly

ah that

wasn’t that last week?

apparently not, and also it doesn’t matter

the other AOB was asking Link Mauve to explain how to do MUC-0313 without exposing a DoS vector

Ge0rG, Which first?

dwd: in that order please

Ge0rG, OK. 5 minutes on each then.

b) Fixing XEP-0184 properly.

Ge0rG, I have never implemented 0313 in a server, I’m sure there are many better people than me for that.

https://mail.jabber.org/pipermail/standards/2019-April/036083.html

(Link Mauve: sorry, I meant 0308)

ah, about that

That message-type info box in 0184 is a fig-leaf, and Kev asked to do it right in one of the last Council Meetings. Do we want to fix it properly?

I’m all in for fixing things properly

but we need to do it without a namespace bump, because there are other things we should include when we bump 184

I'm in favour of fixing things properly as a general rule. What do real implementations actually do?

how far can I go with "fixing" it without you requiring a version bump?

dwd: it varies wildly

some reflect message type, others send normal. Some send to full JID, others to bare JID

Ge0rG, You bump a namespace when to implementations using the same namespace would fail to interoperate (or, indeed, already do).

Ge0rG, I’d say we specify that clients SHOULD send the same type, but MUST accept different types, too.

dwd: the XEP does not mention message types.

mention why it makes sense to have that (archive stuff)

(except when treating MUCs)

Ge0rG, I have noticed that some (COnverse, perhaps?) only handle receipts in type='chat'. I'd thought receipts were meant to be in type='normal' myself.

dwd: "were meant to" is your reading of the XEP or some background knowledge?

type=normal + no body leads to them being ephemeral for MAM and Carbons.

Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.

Link Mauve: please wait for AOB c.

Ack.

Ge0rG, I read the XEP and implemented my end, and it failed. But Example 4, for example, shows a normal message.

dwd: no, it shows a message with default message type.

which is type normal

I claim that this is an oversight of the XEP author and not a deliberate design decision.

And it's not normative in any case.

Ge0rG, So what does "fixed" look like? Same type? I personally think that 1:1 receipts ought to be in type='normal', and not type='chat' (since they're not chat messages). But I'm not wed to that idea.

dwd: the pseudo-quote block in https://mail.jabber.org/pipermail/standards/2019-April/036090.html

The receiving client should consider the following when generating a Receipt, depending on the message type of the message that contained the Receipt Request: - "chat", "normal": the Receipt message SHOULD have the same @type as the Request message. - "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A client choosing to respond despite of this SHOULD send the Receipt with type="groupchat" to the bare JID of the room and not to the full JID of the sender. It MAY be useful to limit this feature to private MUCs with a small number of participants, or to instead send the Receipt as a MUC-PM. - "headline": the Receipt message SHOULD have type="normal". - "error": this should not actually be possible, so the client SHOULD NOT (MUST NOT) respond. A client MUST be able to Process a Receipt message with a different type than the original Receipt Request message.

(quoting from Ge0rGs mail)

jonas’, Thanks.

This is strawman wording, not carved in stone.

OK, so it's not clear to me that this is a bad set of words. I'd be happy to see that as a PR and we can vote on it.

I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule due to lack of data ✏

I wanted to initiate a discussion, specifically about _how_ to treat each of those, and whether this would be a ns-bumping change

Ge0rG, I think it's compatible with the existing XEP, and can only improve interop, so seems OK to me without a bump.

Maybe what dwd said is the more sensible strategy: have all receipts be type=normal and rather fix MAM and Carbons

I think we can all agree that a type=headline receipt doesn't make sense.

We're running over on the 5-minute slot here, though - I'll dig out that email and reply to it with some comments.

for some reason that mail was marked as read so I totally forgot about it

dwd: awesome. I can't promise any activity in the next three weeks though.

replied, too

c) XEP-0308 (Last Message Correction) in MUC

Link Mauve, your slot

I guess this is in context of https://github.com/xsf/xeps/pull/736

Link Mauve: the PR was rejected because everybody was wondering how you are going to combine limited back-history with strong guarantees

Yes

quoting Link Mauve from above: 15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question. ✏

i guess we can defer the discussion based on that?

Indeed, that’d be my preferred course of action.

I wanted to clarify the issue, but it's in the Council logs as well, obviously.

Alright, let's defer

OK, so nothing on this yet. That's fine.

4) Voting

Is there anything?

(Please do so, I think some expire today).

Ah, right.

Link Mauve is owing me a vote or two

5) Next Meeting

Link Mauve, you’re pending votes on: - https://github.com/xsf/xeps/pull/778 - https://github.com/xsf/xeps/pull/787 - https://github.com/xsf/xeps/pull/779 - https://github.com/xsf/xeps/pull/758 ✏

I think we're moving into the Time Of No Georg?

+1w wfm ✏

dwd: right. I can't promise presence in the next two meetings.

+1wwfm2.

The interregnum!

Yeah, WFM.

it might work on short notice though.

Wfm too.

OK, great.

6) AOB

I'll assume that we've covered everything.

7) Ite, Meeting Est

And I numbered it right this time, Tedd.

Thanks all

Thanks

\o/ thx

Thanks. :)

And now, to cast my votes!