XMPP Council - 2022-08-03

o/

o/

Hi

It's time

1) roll call

hello

do we have Ge0rG?

and larma?

yes, next door

(Ge0rG anyway)

2) Agenda bashing

nothing to bash I assume

3) Editors update

no updates this week

4) Items for voting

a) Move XEP-0215: External Service Discovery to stable

I agree with Daniels/Zashes feedback

if no one has once implemented push then maybe that bit should be removed first?

I'd do a very long essay on why the format of the <service/> elements would be much better with a URI and how the registry is broken and there is no way for "service" vs "service-over-tls" etc, but generally +1

is my feedback only relevant for the next step though? meaning can it be removed later?

or do we need to remove it now before it becomes stable

daniel, technically, removing non-STUN/TURN cases in Draft would likely require a namespace bump

which we likely don't want

quoting myself from the future: > However, I don't believe strongly enough to argue for a namespace bump.

getting around the NS bump is a good argument

to fix it before stable

if no one has ever implemented it I wouldn't bother with the namespace bump, but that might be skirting rules

moparisthebest, that's ok for Experimental, not for Draft. In my book anyway.

> moparisthebest, that's ok for Experimental, not for Draft. In my book anyway. I agree

I'm sorry but what exactly do you want to remove?

and yes somewhat related; I’m a bit on the fance wrt removing push to

I propose that whoever shepherds this drops push and non-STUN/TURN cases, renames this to "external media relay discovery" or something and be done with it.

Ge0rG, the ability to do non turn services

I've implemented the push thing IIRC. Idea was to push STUN/TURN immediately on connect to Jitsi Meet, which needs that fast.

daniel: so you want to remove the `type` attribute?

Ge0rG, no, we need to keep that for stun vs turn

so you want to remove the non-normative examples then?

the 'Extended information' will probably go away

and the examples

and maybe some wording changes and a title change

Zash fair enough on the push. I can see how that can be useful

I suppose removing the 'Extended information' section would require a bump indeed.

(in Draft)

in Stable?

Ge0rG, yes, that.

ok, I don't have strong opinions on push, but I certainly can see the benefit of ripping out anything unrelated to STUN or TURN

ok. sounds good

but I think we should run that by the list and poke the social media folks

-1 then

I'm not sure if edhelas or so has used this to announce jingle components or such things

so if we have X implementations, and none of them implement that, we can remove it and do no bump and not one has to change *or* we can remove it and do a bump and then *all* of them have to change? one seems obviously better to me...

moparisthebest, your first line misses a "that we know of"

we're a standards org, not a secret cabal

if they don't monitor the mailing list and it isn't open source I literally don't care

and there are many deployments of standard xmpp in closed setups

daniel, I can write a mail to the list which summarizes the idea of dropping that and asking for anyone actively using anything except STUN/TURN

jonas’, sounds good. thank you

let's move on then

5) Pending votes

- Georg on Proposed XMPP Extension: Pubsub Attachments

I'm still pending, sorry.

ok. no worries

6) Date of Next

+1w wfm

+1W looks good so far

+1w wfm

7) AOB

none here

here

jonas’, go ahead

I have two weeks of vacation in the beginning of September and I intend to make this also a vacation from XMPP

I'll likely hard drop out of all explicitly XMPP-related rooms/communication channels.

(including my shell server)

just as a heads up

same for me, but end of september

jonas’: have a great time! I'm also going to be on vacation, but in the middle of september, and I'll probably still check my xmpps

(Sept 1 -- Sept 14, incl.)

mine is sept 16-27, sounds like sept is a wash :P

thanks, Ge0rG :-)

End of my AOB

I also have something

ok. noted. I guess that'll be a slow month then. I'll probably be gone for a week in september as well. haven’t really decided on when yet

larma, go ahead

I was wondering how we want to continue the alterntive content / partial fallback discussion.

I lack context, could you -v?

As you might remember, I proposed a XEP for fallback bodies a while ago which we decided was not fit because there was another XEP with the same name (although mostly different functionality)

oh, it's the time of the year again

But also we had a large discussion about whether we want to allow partial fallback bodies (which effectively means having alternative content depending on the XEPs supported by the recipient device) and there was not outcome of that discussion really

I get the impression that there are only terrible solutions available

I agree with jonas’

I created a PR to add the partial fallback body functionality of the proto xep into the existing XEP (https://github.com/xsf/xeps/pull/1188), but that obviously doesn't answer the question if that functionality is desired

I can't say I'm a fan of alternative contents either, but to me it seems to be the only sensible way forward IF we want to support a heterogenous client landscape.

larma, whether the functionality is desired is not somethign the council can answer, really

that's for implementations, their project owners and users to figure out ✏

I think that ugly fallback bodies are the best way to motivate client developers to add support for new XEPs

I don't disagree

I also think that fallback bodies are the only sensible way to add features which otherwise may lose subtleties in communication

Anyway, I don't want council to decide on this, I'd rather like to get an idea of how to proceed here. Because the decision if the aforementioned PR should be merged needs to be done somehow.

sorry i had to look up the voting history of 'Compatibility fallbacks' and 428 ✏

larma, that's under dwds control, really

did you shoot him an email?

Ge0rG, voted compat fallbacks because he wanted that in 428.

i personally don’t care if it goes into 428 or a new xep; I’m also fine with the PR you created

but that's not really a council decision if it is merged. we could only do this by taking it away from dwd

jonas’, I pinged him on GitHub, but I can also write another mail.

larma, yeah, I suggest to try an email. I don't read many github notifications either, just too much noise.

I also must say it's a bit weird for council to say "we're not going to accept the protoxep, because it needs to go into 428. And it's on dwd to decide if that happens" - because this puts a major ecosystem decision on dwd.

... yes

personally i'm a fan of new xep rather than 'taking it away'

I guess I'll just have to write a mail to dwd and we'll follow up on this in one of the next council meetings.

we are running up on the time limit here

larma, yes, that sounds like a good plan

ok. let's see if dwd actively blocks this or has become inactive first. and if either of those is the case we might want to ask Ge0rG to reconsider the decision to block the 'compat fallback' proto xep

no further AOB?

none from me

no

8) Close

thank you all

thanks daniel

Thanks daniel

thanks!

Re xep-0215 push, the use case I mentioned would probably be better served by having it integrated with bind2 somehow, if that wasn't far in the future yet.

Thanks for the email Zash. That's much better reasoning than I used

Thanks

Can't remember anyone caring about ftp either :) Only thing I can think of is the idea to provide a proxy to help anonymise requests to HTTP upload-ed files, which could be communicated via '215.