XMPP Council - 2019-08-28

Migraine, so very likely not about this afternoon.

Looks like I'll be in a train station at meeting time today, only equipped with my phone.

.

Afternoon. This doesn't look promising, then.

I'd still like a meeting to happen, even if only for the sake of having a real meeting after two misses

Link Mauve has been serverless for a few days. He might show up under a jabberfr jid, or not.

Also my AOBs are still largely unresolved. I'm thinking of making message errors a first class citizen, and of The Right Way to reference messages.

pep.: maybe we need to send a push notification?

OK, we'll give it a shot.

1) Roll Call

Ge0rG: he doesn't run android nor iOS

I’m here

pep.: send a direct message to his jabberfr JID please.

(Nor any other OS that provides this kind of things, I assume. I'm gone now)

OK, we have three, so that counts for Quorum purposes.

I poked him.

So we can hold a meeting if we want. Do we want?

dwd: are there any new things to vote on?

Well, let's:

2) AGenda Bashing

The agenda is great!

I didn't get to an agenda this week, sorry. I'm also unaware of anything in particular, though I believe there was soething in Last Call which has - presumably - become due for a vote.

yeah

no feedback though

Didn't we have something regarding jingle?

XEP-0300 and XEP-0353

In LC, that is

yes, Jnigle Message Initiation (XEP-0353)

Was that the one where we requested feedback from the informal Jingle SIG?

jonas’: I had feedback on Table 1 in 0300

I'm not sure if that went to standards, though

other than that, I’m not aware of anything to vote on

OK, so yes, indeed, both those Last Calls are long-since expired. We can do a vote on both.

3) Current Activity

I don't think we've anything currently in Last Call or anything? I did notice a bunch of updated XEPs though.

link mauve is coming, fyi, I pinged him by sms

jonas’, Anything of note here?

the official release of that new XEP

XEP-0421: Anonymous unique occupant identifiers for MUCs ✏

Sorry I'm late!

and obsoletion of the '18 compliance suites

Right, thanks.

4) Items for a vote.

a) XEP-0300 to DRAFT

On list

I think I’m +1

I think I'm +1 here.

unless Ge0rG tells me a good reason not to be with his Table 1 feedback ;)

jonas’: I think that table doesn't belong into 0300, but into an informational XEP or a registry

Ge0rG, I think the ideal solution would be to go register the names with IANA, actually.

Ge0rG, one could infer that table to refer to the registry which belongs to that xep

dwd: wasn't the reason for that table that IANA isn't there yet?

I'm not sure whether that table is subject to change, ever

Ge0rG, No, I think it was pure expediency.

If it's guaranteed to remain as is, I'm +1 on the XEP.

linkmauve, Got a vote for us?

IANA has this: https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml getting something in there seems.... tricky

requires an RFC updating 3279

I haven't reviewed the latest version of 0300, I'll be on list.

That'll be why we went for expediency.

Moving on:

b) XEP-0353 to DRAFT

On list

on-list with default to -0

I'm +1 for this. Seems widely deployed and sensible.

jonas’: is there a specific reason for that default?

Ge0rG, there was no feedback on-list and I have no idea about jingle.

Sorry, I'm not used to phone keyboards.

I need to review it for MAM and Carbons side effects

I don’t think that me reviewing it will give me anything which helps me decide

dwd, widely deployed? I would’ve expected feedback in the month this has been in LC then.

jonas’, Well, that's a matter of low energy and engagement.

Even a short message about it being widely deployed

XMPP Low Energy.

linkmauve, Any vote/opinion?

0353 I'm on list too with a default of +1.

I’ll send a mail about that to the list.

OK.

5) Outstanding votes

I think the previous ones have all now expired.

Yes

6) Next Meeting

+1W?

wfm

+1W looks good on my calendar

Wait I have an aob.

linkmauve, Hang on.

It's not AOB yet.

7) AOB

About message retraction.

linkmauve, Uh-oh. Do tell.

Multiple people noticed that the previous council forgot about it.

It has the same issues as reactions though.

:-(

Yeah, Ge0rG jokingly commented on that in xsf@

(Or maybe it was serious? :p)

As in, message attachment is blocking it.

I agree it's all an interesting mesh of issues. I'm not sure it's something for Council to do much with beyond evaluating a proposal.

dwd: what's the alternative for Council, then? Just reject everything with references, until someone comes up with The Right Way?

Oh, my connection will drop in a few minutes, I'm in the U-Bahn.

Ge0rG, Well, individuals on Council can propose something of course.

If I may, from the floor, I would very much like to get these accepted before we figure out the answer to the ultimate question [..]

dwd: I think this is something where multiple council members might combine efforts to move things forward

Ge0rG, Well, sure, but it really doesn't have to be council members, is what I'm saying.

Somebody over in xsf@ even questioned the authority of Council members to reject a proto XEP on those grounds.

it is duplicating existing protocol

(in theory that would be an applicable reason)

I tend to agree with the general sentiment

dwd: yes, but currently there are some proposals (and their authors) blocked on this issue

can we reach out to the client devs who are invested in this and work closely with them to figure out a solution?

I mean they need to be on board anyways

jonas’, Definitely. It'd be nice to get a bunch of them to agree on a solution. Maybe if they discussed it on a mailing list or a chatroom and proposed a XEP.

that’d be ideal

jonas’, Do we have a mailing list or a chatroom people could use?

and also get some of them to apply for council next term

dwd, I’m not sure if you’re being rhetorical here

Standards@? jdev@?

I can only imagine that somebody who just got their first XEP rejected on formal grounds might not be very inclined to do the work required to resolve those formal issues

xsf@ even

Or that

jonas’, Either rhetorical or sarcastic. It's hard for even me to tell these days.

The <s> tag stands for "serious".

Can I summarize this debate as "we have agreed to keep everything as is"?

I’ll reach out to them

Ge0rG, For what it's worth, I wanted to accept the Reactions one.

It's not that much of a formal issue, but a factoring issue.

Anyway.

We're over time - anyone got anything to add before I close?

not me

8) Ite, Meeting Est

please on-list your opinion regarding message errors.

Ge0rG, You'll need to remind me on the details - was it broadcast in Carbons, etc?

Ge0rG, Only, I've got a use-case for sending them through MUC, now.

dwd: it was about that, yes. Also about putting errors into MAM and offline storage

I'm worried about the side effects of carbonated message errors on protocols I'm not aware of.

Ge0rG, Right. So my problem is to do with sending messages with out of band media, and wanting to clearly indicate to the sender if downloading the media failed.

For MUC errors, Carbon-copying is certainly problematic

Ge0rG, No, not MUC errors, errors from messages passing through MUC. The current implementations would simply boot the user who sent the error.

dwd: yes, that's a different issue

Ge0rG, Yes, but I think it's related.

dwd: I'm not very sure about that.

Ge0rG, In as much as most entities are bad about generating and handling errors, and that's in part because of our stipulated handling.

dwd: yes, but we are speaking of two orthogonal problems with the stipulated handling.

maybe occupants should send errors and receipts via PM anyway?

Ge0rG, Absolutely. Same area, distinct issues.

Ge0rG, That's an interesting suggestion.

dwd: obviously not good for read markers, because somebody thought it's fancy to keep track of who read how much of what, individually.

Ge0rG, Yes... It's quite a way to amplify traffic though.

I wonder if you can trigger read-markers with empty messages.

But then again, DoS on XMPP clients is as challenging as taking away candy from children.

Ge0rG, True. It's not about DoS, just efficiency.

dwd: sending a MUC-PM error is perfectly fine, unless PMs are forbidden by the MUC

Ge0rG, Do those go through?

I _think_ so

Ge0rG, I think they'd appear to be normal bounces (similar to a delivery failure) and thus kick the offending client.

Let's test.

dwd: I just sent you a message error PM. I hope

[16:56:51] ‎Ge0rG‎: Let's test. ‎[17:00:52] ‎message ―――――――――――――――――――― ‎[17:01:03] ‎Ge0rG‎: dwd: I just sent you a message error PM. I hope

That's... Interesting.

<message to="council@muc.xmpp.org/dwd" type="error"><error type="cancel"><not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>This is a severe error.</text></error></message>

I wasn't kicked by either MUC or server.

dwd: what client was that, btw?

Error> council@muc.xmpp.org/Ge0rG: cancel: This is a severe error. ...is what I get on self-PM

Gajim.

Somebody with a faster uplink should add PMs to https://wiki.xmpp.org/web/index.php?title=Client_Test_Cases