daniel a) Move XEP-0215: External Service Discovery to stable
jonas’I agree with Daniels/Zashes feedback
moparisthebestif no one has once implemented push then maybe that bit should be removed first?
Ge0rGI'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
danielis my feedback only relevant for the next step though? meaning can it be removed later?
danielor do we need to remove it now before it becomes stable
jonas’daniel, technically, removing non-STUN/TURN cases in Draft would likely require a namespace bump
jonas’which we likely don't want
Zashquoting myself from the future:
> However, I don't believe strongly enough to argue for a namespace bump.
danielgetting around the NS bump is a good argument
danielto fix it before stable
moparisthebestif no one has ever implemented it I wouldn't bother with the namespace bump, but that might be skirting rules
jonas’moparisthebest, that's ok for Experimental, not for Draft. In my book anyway.
daniel> moparisthebest, that's ok for Experimental, not for Draft. In my book anyway.
Ge0rGI'm sorry but what exactly do you want to remove?
danieland yes somewhat related; I’m a bit on the fance wrt removing push to
jonas’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.
danielGe0rG, the ability to do non turn services
ZashI've implemented the push thing IIRC. Idea was to push STUN/TURN immediately on connect to Jitsi Meet, which needs that fast.
Ge0rGdaniel: so you want to remove the `type` attribute?
jonas’Ge0rG, no, we need to keep that for stun vs turn
Ge0rGso you want to remove the non-normative examples then?
danielthe 'Extended information' will probably go away
danieland the examples
danieland maybe some wording changes and a title change
danielZash fair enough on the push. I can see how that can be useful
Ge0rGI suppose removing the 'Extended information' section would require a bump indeed.
jonas’Ge0rG, yes, that.
jonas’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
danielok. sounds good
jonas’but I think we should run that by the list and poke the social media folks
jonas’I'm not sure if edhelas or so has used this to announce jingle components or such things
moparisthebestso 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...
jonas’moparisthebest, your first line misses a "that we know of"
jonas’we're a standards org, not a secret cabal
moparisthebestif they don't monitor the mailing list and it isn't open source I literally don't care
Ge0rGand there are many deployments of standard xmpp in closed setups
jonas’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
danieljonas’, sounds good. thank you
daniellet's move on then
daniel5) Pending votes
daniel - Georg on Proposed XMPP Extension: Pubsub Attachments
Ge0rGI'm still pending, sorry.
danielok. no worries
daniel6) Date of Next
Ge0rG+1W looks good so far
danieljonas’, go ahead
jonas’I have two weeks of vacation in the beginning of September and I intend to make this also a vacation from XMPP
jonas’I'll likely hard drop out of all explicitly XMPP-related rooms/communication channels.
jonas’(including my shell server)
jonas’just as a heads up
moparisthebestsame for me, but end of september
Ge0rGjonas’: 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
jonas’(Sept 1 -- Sept 14, incl.)
moparisthebestmine is sept 16-27, sounds like sept is a wash :P
jonas’thanks, Ge0rG :-)
jonas’End of my AOB
larmaI also have something
danielok. 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
daniellarma, go ahead
larmaI was wondering how we want to continue the alterntive content / partial fallback discussion.
jonas’I lack context, could you -v?
larmaAs 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)
jonas’oh, it's the time of the year again
larmaBut 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
jonas’I get the impression that there are only terrible solutions available
Ge0rGI agree with jonas’
larmaI 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
larmaI 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.
jonas’larma, whether the functionality is desired is not somethign the council can answer, really
jonas’that's for implementations, their project owners and users to figure out ✏
Ge0rGI think that ugly fallback bodies are the best way to motivate client developers to add support for new XEPs
jonas’I don't disagree
jonas’I also think that fallback bodies are the only sensible way to add features which otherwise may lose subtleties in communication
larmaAnyway, 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.
danielsorry i had to look up the voting history 'Compatibility fallbacks' and 428✎
danielsorry i had to look up the voting history of 'Compatibility fallbacks' and 428 ✏
jonas’larma, that's under dwds control, really
jonas’did you shoot him an email?
danielGe0rG, voted compat fallbacks because he wanted that in 428.
danieli personally don’t care if it goes into 428 or a new xep; I’m also fine with the PR you created
danielbut that's not really a council decision if it is merged. we could only do this by taking it away from dwd
larmajonas’, I pinged him on GitHub, but I can also write another mail.
jonas’larma, yeah, I suggest to try an email. I don't read many github notifications either, just too much noise.
larmaI 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.
danielpersonally i'm a fan of new xep rather than 'taking it away'
larmaI 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.
danielwe are running up on the time limit here
jonas’larma, yes, that sounds like a good plan
danielok. 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
danielno further AOB?
jonas’none from me
danielthank you all
ZashRe 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.
danielThanks for the email Zash. That's much better reasoning than I used
ZashCan'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.