XMPP Council - 2021-04-28

jonas’, agenda?

chaos yesterday, dropped off my todo somehow

I initially thought I had a time window for that and then the pandemic cancelled that time window and my head did not schedule a replacement and here we are

but I think we don’t have anything anyway

something something CVE, something something must update 0280

sent a pro forma one

yep, we’ll have lots of time for AOB

Yay!

1) Roll Call

hi

Ehlo ✏

anticipating a Ge0rG and a possible dwd

Hello.

Oh, it's that late already?

it is :)

2) Agenda Bashing

Good morning, everyone!

bad agenda! late agenda!

also, empty agenda

3) Editor’s Update

Nothing, but editor didn’t do anything. Bad editor!

4) Items for Voting

none

Yay

5) Pending Votes

all clear

Yay!

6) Date of Next

+3W WFM

+1w wfm

Ge0rG, have a nice vacation!

+1w wfm

+1w wfm

jonas’: I'll try my best

The same time next week works for me.

excellent

7) AOB

Ge0rG had some I think

Oh, I'm kinda unprepared.

I think you mentioned something about bringing up the CVE thing on standards. Which I didn't do yet. ✏

And I have a hard time remembering last week's conclusion of what to do with <private/> and no-copy.

My AOB is that I'm getting a COVID vaccine shortly, which seems a bit pointless as I don't even have a 5G phone.

dwd, congrats!

Something about not removing <private> IIRC

Ge0rG, the summary was, I think, that if you want to remove that strange <private/> behaviour, add a feature to indicate that the server in fact executes the new behaviour

otherwise it will do nothing good except chaos

Why didn't we add a feature the last time we changed <private/> stripping rules?

oversight?

past wrongs don’t give permission for new wrongs

I had a slight hope that the past wrong would be cancelled out by the upcoming wrong

I’m not even convinced that the last change wasn’t a mistake.

no, because there are a few years of practical deployment inbetween

But I don’t think that means fixing it can skip the needful.

jonas’: given the amount of server developer feedback, I'm not sure this is true at all ;)

Ge0rG, yes, the lack of feedback does not allow us to come to any conclusion.

hence, we have to play it safe

“Lack of feedback” doesn’t actually mean lack of feedback, does it?

even if the only diff on the server side would be adding a thing to disco#info

There’s been lots of feedback, IIRC, in response to some of the previous 2039871032730987 last calls.

Kev, I think Ge0rG meant to reference lack of feedback on that specific issue

Okay, so I'll move forward by removing the stripping and adding a no-stripping feature.

Kev, Maybe we should keeping having more and more last calls until eventually we get no feedback at all and we can reject it on that basis instead.

Now what about no-copy hints?

dwd: That's an excellent idea

LC of Zeno?

ok

silence

Ge0rG, I have no opinion on no-copy hints

Well, my (serious) question still stands.

nor do I have a clear picture about the implications

Ge0rG, could you summarize your thoughts on no-copy?

i.e. what is the current situation, what is bad about it and what would you like to change?

jonas’: no-copy was added as an AND requirement for clients after <private/> was there

the requirements for servers are vague, at best

IMO, removing no-copy will not do any harm to specification-abiding implementations

The only corner case I see is when a receiving client would rely on no-copy being there while <private/> being stripped by a stripping server.

Sorry, somebody decided that *now* would be a good time to send thousands of vaccination notifications.

(I just checked the only time I use no-copy in Conversations is when I send a direct-invite to my own connected resources to inform them that I've just joined a new muc. Which has arguably been made obsolete now that we have bookmarks in PEP)

daniel, lovely hack though :)

love the attention to detail in there

daniel: why not sending one invite to your bare JID?

to avoid receiving it on my own client i guess

Ge0rG, OK, I don’t have strong opinions on that

as I assume that many implementations would handle <private/> even if <no-copy/> was absent if the XEP is worded vaguely

jonas’: that's my conclusion as well

Okay, thanks everybody for the fruitful discussion. I think I'm out of AOBs for now.

I sense sarcasm

anyway

dwd, do you want to elaborate on your AOB? :)

I'd never dare to

what are we achieving by stripping or not stripping that element?

daniel: we get rid of legacy

by stripping it?

yes

so you want to reintroduce legacy by telling servers to not strip it?

I seem to have lost track of what exactly the question was

yes. me too

that's why i'm asking

daniel: I don't follow

daniel: did you ask about no-copy or about private?

"that element" appears ambiguous in retrospect

no-copy → strip from the XEP private → don't strip from stanzas ?

what Zash said!

It seems to me that we've spent nearly half an hour doing protocol design in a Council meeting. Can we not write a proposal to the list, see if there's concensus to do anything (or nothing), and go from there?

dwd: sure

dwd is a smart person

let’s do what dwd s ays

+1

any other AOB?

none here

None from me.

none here either

then I wish you all a pleasant rest of the day

8) Ite Meeting Est

thanks all

Thanks jonas’

Thanks tedd

and thanks all

Thanks!

Message Carbons is weird legacy anyway. I don’t thing we gain anything from messing with no-copy and private

yes it was a mistake to introduce no-copy

but those extra bytes don’t matter

No need to cement that mistake into eternity

considering the overhead that carbons has anyway

i really hope that Carbons don’t hang around for an eternity

I'd be curious as to whether it matters if it *is* baked into eternity.

I mean, if it's there already in implementations, does it matter?

plus looking at the history of the XEP it seems that stripping <private/> was a requirement before no-copy was even introduced

so the stripping of private is not to remove redundant information after the introducting of no-copy

it was there before

i don’t know why

so even if you were to remove no-copy you don’t need to mess with the stripping or not stripping of private

I think it was a mistake.

everything?

Looking at the changelog, the changelog seems to suggest it was trying to do the opposite of what it does.

No, adding the stripping of private.

Everything! Climbing down from the trees especially

considering that there are very few use cases for private/no-copy I suggest that we accept the fact that Carbons is not pretty but de facto draft and just leave everything as is and declare it as such

mmm

weren’t we there already last week?

and try for a reasonable upgrade path to IM-NG?

however, the stripping of private might be considered actively harmful

I consider it is, yes.

so fixing that before moving to draft may be worthwhile

so remove no-copy don’t strip private?

remove stripping of private, remove no-copy from XEP

yes

👍

Can anyone think of a scenario of a receiving client that relies on the stripping?

No.

Because that's the breaking change here, right?

Anyone remember why it's even stripped?

Depending on one’s definition of breaking, yes.

ISTR some privacy issue or something

Zash: As I say above, I think it was a mistake. The changelog says that it was removed, but instead it was added.

I think there was a version of Carbons that required the *sending* server to strip, but then somebody realized that the receiving server needs that info as well

Makes sense, I think Prosody still follows that 😕

Zash: prosody will strip on the sending server?

y

Fun

Unless I'm mistaken

OK. I've changed my mind. You have my blessing to remove the no-copy hint from the xep and remove the requirement to strip private

(not that you need that since you are the author and the xep is experimental)

Forever...

if that's true, the fact that nobody noticed it yet speaks tomes.

Hm, nm, seems to strip it on the receiving end only

Wrong room?

Ooops, that was the wrong place. ✏

is it me or are we missing Council minutes for April? I tried to find the "mention CVE PR on-list" statement in either my local logs or the Minutes and failed :(

hmm

possible

I hope Tedd is alright

Yeah, that was also my first thought.

And my second thought was, that this kind of thought is very frightening, if the only regular interaction with somebody is them writing a summary email to a list.

ah, found it. 20210421T15:42:30Z

jonas’: https://mail.jabber.org/pipermail/standards/2021-April/038301.html

jonas’, Tedd is alright ;)

just been otherwise distracted

minutes will magically appear, probably