jonas’heads up, work and public transport hate my scheduling today. I might run a few minutes late. Feel free to start without me, I'll join. Ideally, I'll at least be on my phone when 1600Z strikes
jonas’will be on time
ZashJust got home and sat down
jonas’kind of did the same
jonas’1) Roll Call
jonas’assuming that dwd will appear, moving on
jonas’(we have quorum either way)
jonas’2) Agenda Bashing
jonas’anything to add?
Ge0rGWe need shorter agendas in the future
jonas’3) Editor’s Update
- ProtoXEP: Extended Channel Search
- Expired calls: CFE on XEP-0198, CFE on XEP-0368, LC on XEP-0398
- Calls in progress:
- LC: XEP-0402 (PEP Native Bookmarks), ends: 2020-03-03
- CFE: XEP-0066 (Out of Band Data), ends: 2020-03-10
- LC: XEP-0429 (Special Interests Group End to End Encryption), ends: 2020-03-10
jonas’(note the LC which came in after I sent the email yesterday)
jonas’4) Items for a Vote
jonas’4a) Decide on advancement of XEP-0398
Title: User Avatar to vCard-Based Avatars Conversion
This specification describes a method for using PEP based avatars and vCard
based avatars in parallel by having the user’s server do a conversion between
jonas’4a) Decide on advancement of XEP-0398
Title: User Avatar to vCard-Based Avatars Conversion
This specification describes a method for using PEP based avatars and vCard based avatars in parallel by having the user’s server do a conversion between the two.
jonas’I would like to see changes on the Security Considerations section before this moves on. Since we need to touch normative language, I guess it’s better to handle this in Experimental
jonas’so -1 from my side
Ge0rGSome PEP access questions came up, it would make sense to consider those first
jonas’so -1 from my side, with the intent of having someone™ fix this
jonas’so -1 from my side, with the intent of having someone™ fix this; so no rejection, just back to Experimental for fixes
Ge0rG-1 as well due to that
danielYes I'm fine with updating the pep stuff on relative short notice
danielWe can restart next week or so
jonas’sounds like a plan
Zash-1 (I agree with jonas’ )
dwdHiya folks, sorry for being late.
jonas’that’s massively Veto’d then
dwdI can add another veto if you want. :-)
jonas’dwd, would be great for formal reasons :)
jonas’4b) Decide on advancement of XEP-0198
Title: Stream Management
This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption.
(The CFE ends today, so be sure to send in your feedback if you haven’t already.)
dwd-1, for the reasons stated by others.
Ge0rGdwd: can you also add more veto reasons?
jonas’I am on-list, because I haven’t been able to catch up on the thread yet
Ge0rGI'm not sure regarding 0198. It's doing its job great, except for the unclear resume host connection mechanism
dwdFor XEP-0198, I noted a comment from - I think - MattJ on S2S I've yet to consider. But it's fair to say that 198 on S2S is under specified at best.
jonas’we have zero s2s implementations, do we?
Ge0rGSo we want actual experience with s2s 0198?
jonas’question is whether that even allows us to move it forward
daniel-1. I think I (and others) brought up vaild but fixable concerns
Zashon-list, haven't read that thread yet
dwdjonas’, I honestly don't know. None were explicitly mentioned.
dwdjonas’, Which itself is a procedural reason for not advancing.
dwdSo as such, given the lack of clarity there, I'll be -1 on this.
Zashmod_smacks for Prosody does support 198 on s2s, but it's disabled by default and I don't think anyone ever enabled it
Zashno resumption tho
dwdZash, Right, unclear what resumption would do for S2S.
jonas’resending stanzas which weren’t acked?
dwdjonas’, Depends if they weren't already bounced.
jonas’okay, that’s a rabbit hole we shouldn’t go down in this context
Ge0rGso -1 then
jonas’4c) Deviced on advancement of XEP-0368
Title: SRV records for XMPP over TLS
This specification defines a procedure to look up xmpps-client/xmpps-server SRV records (for direct TLS connections) in addition to xmpp-client/xmpp-server and mix weights/priorities.
moparisthebest(I promised to make some changes to XEP-0368, mostly clerical, but one SHOULD to a MAY)
jonas’I am -1 on 4c, since there need to be some changes made
Ge0rG-1 on 4c as well, I liked the proposed wording
jonas’goes to dig up the proposed wording
danielOn list. I'm not caught up on that
dwdI'll take "I promised to make some changes" as a "update coming", so -1 for now.
Ge0rGI think that leaving this to clients is good, because right now, priorizing DirectTLS over STARTSSL will add an RTT on servers without DirectTLS SRV records
dwdI'm also unclear on ALPN implementation.
dwdOh, and this reminds me - I have AOB, jonas’
jonas’alright, changes will happen here, so moving on
jonas’4d) Proposed XMPP Extension: Extended Channel Search
This specification provides a standardised protocol to search for public group chats. In contrast to XEP-0030 (Service Discovery), it works across multiple domains and in contrast to XEP-0055 (Jabber Search) it more clearly handles extensibility.
jonas’Unsurprisingly, I’m +1 on that one.
Ge0rGI have issues with that, mainly regarding the discoverability of whether the service is a local search for the given host domain or a proxy
jonas’Ge0rG, me too, I intend to fix those in Experimental
jonas’4e) Authorship of XEP-0044
Title: Full Namespace Support for XML Streams
A description of the use of namespaces within Jabber.
Zashjonas’, was this the one mentioning something about 0004? I didn't see it
jonas’Zash, yes, in the Design Considerations section
jonas’I would like to take authorship of XEP-0044, polish it, add namespaced attributes and a stream feature to it and bring it back on TRack
jonas’I would like to take authorship of XEP-0044, polish it, add namespaced attributes and a stream feature to it and bring it back on Track
jonas’I tried to contact the author already, but neither did I get a reply nor can I find the sent mail, so maybe I didn’t
jonas’ah, it’s stuck in my clients outbox
Ge0rGI motion that jonas’ re-sends that email, and if no response happens within of 14d, he may take over authorship
jonas’resent it now, so we should probably move that
jonas’resent it now, so we should probably move that agendum
jonas’5) Outstanding Votes
jonas’I think Zash still has one pending on Trust Messages
jonas’(noting that we are on two +1 and two ±0 at the moment)
jonas’(expires in +1w)
jonas’6) Date of Next
jonas’+1w wfm, though I might both be late and have to leave on time. Meeting at work before, burgers afterwards.
Ge0rGI'm going to miss +1W
jonas’so if someone volunteered to chair (I’ll send an agenda, of course) that’d be great
jonas’looks at dwd
Ge0rGjonas’: maybe you should announce AOB first
jonas’can do that
jonas’let’s hope someone will be there next week to chair then ;)
jonas’dwd had some, so mic to you
dwdSo XEP-0001 says that to move to Final, a spec needs two implementations, etc.
dwdBut we're not clear if that means that every optional part needs implementing, and we're not clear on whether this might be one client and one server.
dwdI've always just assumed that we demand the same levels as the IETF, which would be 2xClient and 2xServer covering all optional parts.
danielThat sounds sensible
pep.So Pubsub and MUC will never be Final?
dwdDoes anyone think this is important enough to specify properly in XEP-0001, and does anyone have any views on this?
pep.(who implements everything?)
jonas’dwd, that indeed sounds sensible
Ge0rGpep.: zinid does?
dwdpep., The idea would be that a spec moving to Final either gets the weird bits nobody actually does removed, or at least moved to a different XEP.
jonas’and ..... highly unlikely to ever apply to MUC and PubSub, indeed.
Ge0rGdwd: it's a good idea. Somebody™ should make it happen!
pep.yay 1 server implementation, 3 to go
danielIn practice the number of implementations never seems to be an issue
moparisthebestthen there are odd xeps like 368, where there are 3 parts, 1 client, and 2 server, all servers implemented 1 of them before 368, but I'm not sure we have 2 impls of the 2nd part
jonas’daniel, in practice, we haven’t tried to Final '45 yet ;)
dwddaniel, Normally, no - specs are either widely implemented or not at all.
jonas’dwd, if you prepare a patch for '1, can you remind me to update the CFE template to specifically instruct to mention pieces which were left out in the implementation?
dwdmoparisthebest, ALPN support in XEP-0368 would be an interesting case in point, actually.
dwdjonas’, Yes, happy to do that.
jonas’either way, in this non-vote, I’m +1 to making this clear in '1 and to adhere to IETF standards
dwdSo consensus is that I'll take this on, pen some text, get agreement on lists and prepare a patch for this and CFE template?
jonas’needs to be sanctioned by board either way
dwdOK, will do.
ZashClarification is good.
moparisthebestdwd, that's true also, I was more meaning all servers supported listening for TLS on c2s, but how many 1) listen on TLS for s2s 2) connect TLS for s2s
moparisthebestI think maybe just your Metre ?
dwdmoparisthebest, And Openfire - I think Guus did it there anyway.
ZashProsody can if you enable port multiplexing
ZashListen, not connect tho.
dwdAnyway, that's me done, jonas’
jonas’anyone else any AOB?
Ge0rGMy usual meta-oob comes and goes.
jonas’we’re running out of time either way
jonas’Ge0rG, I’m not sure which one that would be, does it fit in 30s?
Ge0rGjonas’: of course not. It's about persistence of message errors.
jonas’As a closing note, I’d like to encourage all Council members to read up and potentially advance on this thread: https://mail.jabber.org/pipermail/standards/2020-January/036870.html
Ge0rGOr rather, that is one of three or so meta-OOBs that I have around
jonas’And with that:
jonas’8) Ite Meeting Est
jonas’thank you all
jonas’thank you, Tedd
Ge0rGthank you, jonas’
dwdGe0rG, Didn't I handle persisting message errors somewhere in XEP-0427?
jonas’(at some point, when Tedd finally disappears into the magic cloud of dust they must’ve come from, council chairs will still say that in the hopes to summon minutes.)
jonas’(at some point, when Tedd eventually disappears into the magic cloud of dust they must’ve come from, council chairs will still say that in the hopes to summon minutes.)
Ge0rG> The second form, "full", presents every message stanza in the results, including all fastenings, errors, and so on.
Ge0rGdwd: I don't think that's normative.
Ge0rGjonas’: it will be one of those arcane procedures nobody knows the reasons for
dwdGe0rG, That is normative. It's a statement of fact. I can put MUST somewhere to clarify though.
Ge0rGdwd: my point is: I want that to be explicit and well-visible to all developers
Ge0rGand not part of a very new XEP that is still being rewritten
dwdGe0rG, Sure. I need to do a fairly extensive pass over that spec; I'll make it clear that an implication of supporting the spec for servers is that they need to store everything inclusing errors.
Ge0rGdwd: still, I'd like to keep that separate
dwdGe0rG, Split out "simplified" and "full" from XEP-0427?
Ge0rGdwd: split out "you MUST store message errors in MAM"
Ge0rGdwd: split out "you MUST store message errors in MAM and Carbon-copy them everywhere"
Guus> moparisthebest, And Openfire - I think Guus did it there anyway.
Yes, but has a bug.
moparisthebestbuggy implementations probably still count as implementations? :) good to know though
moparisthebestGuus, does openfire do ALPN at all?
moparisthebestALPN support seems far more widespread today than just a few years ago when XEP-0368 was written, thanks http/2 I guess!
Guusmoparisthebest: don't think so. Seem to recall it was not supported in java 8
moparisthebestjava unsupported-for-over-a-year-now ? yea probably not :)
moparisthebestlooks like it's been supported since Java 9 though, and 13 is the only supported version of java, until next month when 14 will be
GuusI think it is in newer versions, but Openfire retains compatibility with older Kava
GuusI think it is in newer versions, but Openfire retains compatibility with older Java
moparisthebestConversations was the first impl and it always supported ALPN, Gajim I think supports ALPN, I don't think Dino does but not sure anymore
moparisthebestjonas’, does aioxmpp ?
jonas’moparisthebest, I don’t think so
jonas’oh it does
moparisthebest*can* it? (does python let you?)
jonas’if the PyOpenSSL version is recent enough
moparisthebestanything that supports http2 supports ALPN so that should be fairly widespread at this point
jonas’and it’ll log a warning if DirectTLS is attempted and PyOpenSSL doesn’t support ALPN