XMPP Council - 2019-07-31

Finally getting to Agenda. Sorry for the lateness.

Doesn't appear that we have anything new to vote on, though - anyone else know of anything?

we do

we missed that last week, too

give me a sec

https://github.com/xsf/xeps/pull/801

also this: https://github.com/xsf/xeps/pull/803

dwd: I'm not sure how much sense it makes to continue last week's discussion.

Regarding message references, that is. I've written a response to the Reactions thread which actually summarizes my opinions on that specific topic

just in time for the Council meeting, my power and internet access has been restored.

Congratulations.

You have the power!

.

I'm currently considering blocking Message Reactions.

Does that make me a bad person?

why?

(I seriously considered blocking, too)

and I may still be swayed

Kev: the important question is: does not-blocking it make you a good person?

Kev: Depends on the rationale for blocking?

It's time!

(Well, actually, it's late!)

"This is definitely not the Right Way to do this, as we need a general way of referencing a previous message for assorted things, of which reactions are only one, and to use that everywhere, while the reactions syntax is not reusable. This mechanism could be references, or could be attaching, but a reactions-only syntax is definitely unhelpful when we need to be collating all the different types of meta-data responses and exposing them in archives. As-is at the moment, without that half of the puzzle solved (such as the collation stuff from the Summit), reactions are limited. I’m very concerned that not doing it Right at first when it goes Experimental is going to lead to an situation where it gets deployed and is almost impossible to fix the holes later due to inertia-once-implemented. "

1) Roll Call

I'm here.

(Above is the text in my votes email that I've not sent because I can't decide if I'm -0 or -1)

I’m here too.

I've got the power.

I’m here

can we jump straight into that discussion? because I have some opinion on that

yes please.

jonas’, Not ideally, no. But AOB certainly.

dwd, this *is* about outstanding votes...

but ok

2) Agenda Bashing

I'd like to add an item (3) about reactions please.

Kev, my rationale for +1ing it was to get that sorted out once we are decided on an attaching mechanism.

:)

dwd, https://github.com/xsf/xeps/pull/801 https://github.com/xsf/xeps/pull/803

Which would change 0308 and some other ones too.

I don't mind when we talk abbout reactions, happy to do so in (5) or (7) though.

Ack.

jonas’, Acks.

3) Activity Summary

Noting:

* New XEP-0420 (Stanza Content Encryption) published. * Last Calls open for XEP-0353 and XEP-0300, both due to close on 13th August.

as long as it's not in (6)

(Link Mauve: I can see an argument for allowing it through. It's the usual argument that if it's not obviously broken (or duplicating) it should be let through - I subscribe to that argument. Just in this case my suspicion is that we'll see quick adoption of this as-written, and it'll be an interop nightmare later.)

So please join in the Last Calls.

4) Items for a vote:

I’d like to formally apologize for the delay in publishing those changes (editor hat); my mail client was... messed up to the point that I didn’t get new mail unless I restarted it twice, sacrificed a goat and then pressed F5 right when the last drop of... you know the deal. It should be fixed now and I can continue to work properly.

jonas’, Am I write in thinking we have to discuss both of those together?

dwd, no you’re not

jonas’, Also, it's an MUA. All MUAs are terrible.

one is about obsoleting the CS '18, one is about a patch for XEP-0368

Oh, they weren't the ones I was expecting.

Isn't 801 already approved, or did I miss this?

Kev, don’t confuse it with https://github.com/xsf/xeps/pull/796

How could I?

a) https://github.com/xsf/xeps/pull/801

which was indeed approved, but which I (editor) deferred intentionally so that council gets a chance to discuss 801

I find 801 and 796 somewhat contradictory.

(I also asked the author of #796 and they were ok with that)

they are

So, according to the thread on XEP-0368 which I re-read just earlier, I’m strongly in favour of 796.

(There's also a typo in 801 - s/it's/its/)

Observation: The community seems to have at least three differing opinions on how XEP-0368 should work

I'm not sure I understand #801.

dwd, I think #801 is a fallback chain of xmpps-server -> xmpp-server -> A/AAAA, while #796 was (xmpps-server + xmpp-server) -> A/AAAA

It seems to imply you'd look up _xmpps and only if that returns a '.' look up _xmpp.

796: if there is an SRV record, do not try to connect via A/AAAA 801: if there is an SRV record, *do* try to connect via A/AAAA

yeah, that, right

The issue with 801 is that it assumes DNS can’t be trusted, in which case we can plain stop doing XMPP things because SRV and DNS are kind of required for that to work.

I don't entirely understand the rationale behind not trusting the DNS results, so using other DNS results in 801.

Kev, exactly

that doesn’t make sense to me either

Kev, Only trust the DNS results you like?

I tried to argue that with the author in xsf@, to no avaail

Also, defining the port fallback as “yolo” is not a good way to go at it.

dwd: It feels rather like principles...

There is an argument that one might inject a '.' record to _xmpps-* as a downgrade attack I suppose.

yeah, the unspecified port choice is enough for me to -1 this

Yes, but if you control DNS to that extent, can't you do the same elsewhere? ✏

And where has 443 appeared from as a valid fallback port when using A/AAAA?

Kev: That might be my fault :(

I am -1 on #801, because: - the port choice is, as Link Mauve put it, "yolo", which isn’t really appropriate - It doesn’t clarify like the title suggests, but instead changes behaviour from the previous business rules - Contradicts how SRV works normally - Isn’t logically coherent (don’t trust DNS, but trust DNS)

I don't like 801 at all.

Kev, I think the assumption is that you will then poke at random ports on a (cached?) AAAA record, until you get something which looks like a TLS endpoint.

Kev, Well, if you control DNS to that extent, #801 is insufficient protection anyway (and arguably makes things worse).

I agree with jonas’ here, -1 because of the random ports dropped in.

Kev, Zash was sarcastic in the mail thread and suggested 443 and someone took it seriously.

In comparison, 796 seems to be logical to me. Annoying that I'd have to change some of my logic in some places, but sensible.

I don't like possibly anything about #801, I think. -1.

-1 too, for the same reasons as jonas’.

-1 to 801 for the reasons previously stated.

And +1 to 796, although my period has expired on it.

OK. Moving on.

b) https://github.com/xsf/xeps/pull/803

I’m +1 on 796 too, if we’re back to it.

Obsolete Compliance Suites 2018

+1 on 3b

+1 too.

+1 on obsoleting '18

I am +1 on the implied vote to Deprecated.

dwd: you wanted to arrange something re CS2020.

I'm +1 on the vote from Deprecated to Obsolete.

Kev, Very good.

Ge0rG, Yes, you're quite right, I did - mea culpa.

I think I'm +1 on this too.

I follow Kev here.

jonas’, Well, quite.

5) Outstanding Votes

did we just have two votes which were immediately decided?

Happy to discuss Reactions here, since it's an outstanding one for Kev?

jonas’, Yes. Our dysfunctionality isn't working today.

jonas’, indeed!

this is outstanding.

So, I don't want to be a bastard here and prevent progress.

okay, re Reactions: - I think that References isn’t a good choice for I think it needs to change drastically to be useful, especially for quick aggregation use-cases - Message attaching would work-for-me - I strictly think that we should *not* burden or hurt the original authors of the Reactions ProtoXEP by asking them to wait for/write a XEP for referencing. It’s not their fault we don’t have a coherent way to do that.

At the same time, my spidey-sense is telling me this is going to end badly if published.

Kev, regarding that, I am still *very* tempted to -1 it based on the "body fallback" argument.

for similar base reasons as you, actually

I would -1 it if it had a body fallback.

As that would be obviously broken.

oh dear

I’d like to have a high-bandwidth meeting on that topic

Kev, as for your spidey-sense, there are already three implementations in the wild, one of which has been released this week.

Kev: it's going to be stalled forever.

https://nl.movim.eu/?node/pubsub.movim.eu/Movim/fd1921c6-219f-477b-a4be-ebb25e4cccc5 being the one.

FTR, Reactions is https://xmpp.org/extensions/inbox/reactions.html

Two main reasons: 1) It'll completely break MAM etc. 2) People tend to use reactions when they don't have enough to say to justify a message, because 500 messages of +1 just distracts from conversation, where [👍500] is fine.

I'd suggest we rename XEP-0367 into something more generic, which we can use for all message-relationship causes.

Link Mauve: I think that's even more argument not to publish it, then.

then we use 0367 for Reactions and everything else.

Kev, how would it break MAM?

jonas’: Because you'd end up with e.g. 500 messages in the archive because they've got body content.

regarding (2): still there is communication happening, and non-supporting clients silently not seeing the communication is an extremely bad thing in my opinion.

Kev, reactions need to be in the archive anyways.

note that the XEP specifically puts a <store/> hint in the reactions.

Kev: looks like there are two fundamental positions here, which differ on whether reactions are an important part of conversation or not.

if reactions are not important, we should -1 the XEP altogether.

jonas’: Yes. So you need clients to support it. Just as if you don't support PEP et al you don't get to see user tune, or if you don't support MUC you can't enter MUCs.

if reactions are important indeed, we need a legacy fallback body.

Ge0rG, Well. Maybe.

Kev, user tune is more passive communication. you know you can’t join MUCs when you can’t join MUCs.

you don’t know you lost messages when your client doesn’t support reactions.

I don't think we should have legacy fallback bodies baked into the protocol.

Kev: re MAM: reactions are supposed to go into MAM as well, via an explicit hint (which is a rejected XEP itself)

I don't see a way to get "there" from that point, and we'll be stuck with legacy forever.

dwd, I think, we should, at least for the Experimental phase

we can easily reevaluate during Experimental

jonas’, Nope. We'd never get rid of them.

I'm very much -1 on fallback bodies.

why?

dwd: MUC invitations are a place where we do have legacy bodies, but we did it wrong there.

so essentially as a client author, you don't know whether the body provides additional information and you need to somehow make sense of it for the user.

OTOH, I'm absolutely fine with legacy fallback bodies being added by servers on the C2S link.

I'm not convinced even that is a good idea.

(Except for 1:1, where it's fine)

dwd: how is that different from the sending client adding them?

dwd, doesn’t work with XEP-0420

Would you need to rewrite MAM results on the go then?

Zash: depending on the client's disco#info

Zash, I'm not suggesting mandating it.

I also disagree with fallback bodies being sent, as Ge0rG said reactions are generally not “important”, more like a weak +1 or -1 on random messages, unsupporting clients would render that very annoyingly.

But in a MUC sending these things out with bodies is going to be more or less excluding legacy clients from the conversation because of the spam they can't possibly deal with other than by supporting the XEP (in which case ...).

Link Mauve, Ge0rG specifically said they *are* important.

I think we have very different experiences with Reactions

in other chat systems

if they are unimportant, they are not adding to the conversation, so let's just skip them altogether.

My experience is I'm in a number of chats where the ratio of messages to reactions is almost an order of magnitude.

and based on those different experiences, we have different opinions on the importance of fallback bodies

Kev: it will increase pressure on legacy client developers to fix their codebases.

Ge0rG, unimportant doesn’t mean unneeded, it just means they generally add little signal to the discussion.

that’s not the case anywhere where I am, but oftentimes reactions are indeed important and used instead of typing a "yes"

anyway, I thought this is about Attaching References?

Well, MUC and reactions is interesting - if you have a typical MUC setup with a scrollback history of 20 items or so, then reactions will typically blast away the entire scrollback if there's legacy bodies.

dwd, even if there’s not, note that the XEP demands a <store/> hint

Unless the MUC is aware of reactions, at least.

Ge0rG, pressuring Pidgin to implement something isn’t really going to work.

jonas’: Yes, that is a case too. I suggest that in such cases the sensible thing to do is ensure everyone supports reactions.

Link Mauve: let natural selection sort _that one_ out.

Kev, well, that’s not how the world works

Ge0rG, that one, or us. :p

Link Mauve, Designing the network and protocol around the shortcomings of Pidgin isn't really my idea of sensible.

jonas’: Within subgroups, it kinda is.

Kev: if everyone supports reactions, you don't have any reason to object to legacy bodies.

Kev, so those subgroups can support Reactions and not be bothered by legacy bodies? perfect. The general public should see any message by default.

We can't get the public network as a whole upgraded, but if there are groups where reactions are critical, supporting reactions seems sensible.

In 1:1, the client know if the other party supports reactions or not. So we don't need legacy support.

dwd, neither is it mine, but it was an extreme example, there are many other only-slightly-maintained clients which won’t get support for it until a long time, if ever.

dwd: that's not quite correct.

There is no need to harm their users if we can avoid it.

dwd, incorrect

In MUC, legacy support would screw up history (and probably archiving), so we don't want it.

Indeed, multi-clients breaks everything caps-related.

dwd: from the "burn resource locking with fire" thread, there is MAM and Carbons

Link Mauve, exactly, that’s why we need a fallback.

silently omitting communication *is* harming users.

jonas’, that’s why we don’t need it. ^^'

jonas’, but overwhelming users with very small signal-to-noise is harming them too.

So Council is now officially in a Mexican standoff.

I feel we've veered wildly off target here, which was me trying to justify vetoing it on the basis of harm to the network once it's ratified and inertia sets in.

Link Mauve, I think that’s easier to sort out by social contract than noticing that communication is happening when there isn’t and *then* sorting *that* out.

Link Mauve: less so than dropping messages that contain signal.

At least saying "This needs to be a different way" puts a line in the sand so no-one's confused about it.

Kev: let's come back to that other controversy, then.

But we drop lots of things that contain signal. Message receipts, for example.

> I'd suggest we rename XEP-0367 into something more generic, which we can use for all > I'd suggest we rename XEP-0367 into something more generic, which we can use for all message-relationship causes.

dwd, they are (typically) only sent when requested, and then not dropped either?

I could be persuaded by adding text to the top explaining how this needs to change and that the authors intend to do so as soon as Other Problem is resolved in the community, I think. Which might be a reasonable compromise?

dwd: did you know that there are clients which will send receipt requests into a MUC? And other clients, that will send receipts to those requests, also into the MUC?

That being said, there is really no harm done by legacy reaction bodies.

Ge0rG, See also typing notifications.

jonas’, ask pep. how he felt with reactions and threads in an environment which was enforcing their usage. :p

(And his software couldn’t.)

Link Mauve, I know that pep. has strong opinions about things, and they’re often very opposed to mine and we can’t seem to convince each other.

ANyway, we're out of time... Maybe argue about this on the list?

dwd: that won't work.

the vote expires today

Kev, your vote?

Kev, +1 to that.

I don’t believe in XEP authors claiming intention to change anything after acceptance

we had that with OMEMO

Kev: what about replacing the reference mechanism in Reactions by 0367, and Council doing its due duty to make 0367 a sensible long-term vehicle?

Ge0rG, I’d be on-board with that one

Kev, I'm fine with that. I think I even said I thought it'd radically change, myself.

Ge0rG: I don't think it's Council's duty to do anything with 367.

But FWIW, despite References, I think 367 could be a reasonable basis for all this stuff.

Kev: that's not the right attitude.

Kev, Or, BTW, totally fine with you rejecting it outright until we've disentangled this mess. ✏

dwd: this is a bit like prosecuting the XEP author for shortcomings of the ecosystem. I would very much like to NOT pull this card on Experimental

Kev, But absent a vote from you before EOD, it'll go through as-is, so... ✏

Ge0rG, Personally I agree. But Kev can veto it for having the letter 'e' in it too many times if he chooses.

"This is definitely not the Right Way to do this, as we need a general way of referencing a previous message for assorted things, of which reactions are only one, and to use that everywhere, while the reactions syntax is not reusable. This mechanism could be references, or could be attaching, or could be something else, but a reactions-only syntax is definitely unhelpful when we need to be collating all the different types of meta-data responses and exposing them in archives. As-is at the moment, without that half of the puzzle solved (such as the collation stuff from the Summit), reactions are limited. I’m very concerned that not doing it Right at first when it goes Experimental is going to lead to a situation where it gets deployed and is almost impossible to fix the holes later due to inertia-once-implemented. Council had a long and heated discussion about this today, and I think the best thing I can do is -1. My suggested remediation is to a) Get general agreement that either references or attaching can be our Future Mechanism For All The Things (I think we’re pretty much there) b) use Attaching (367) in reactions."

Also I remember some people saying that it's much better to have an Experimental XEP than an XML file on some personal server.

Ge0rG, I also agree with that.

I'm about to send that, unless someone persuades me otherwise.

Kev, go ahead. the change is trivial.

Ge0rG: I agree with that in almost all cases. :)

I’ll put my "yes, use XEP-0367 right now" under it

jonas’: don't say that lightly. Should the Reaction be a payload of the message or of the <attach-to> element?

OK, let's move on.

Ge0rG, message, obviously.

Really - we're 5 minutes over already.

jonas’: that's not semantically correct

I'm done, thank you.

thanks

6) Next Meeting

Ge0rG, on list

I am not here next week.

phew.

Ge0rG, "phew" to me not being here next week?

I am also not here next week. Probably.

+1w wfm

Down to three, so let's skip next week unless the remainder want to try?

+1w wfm. I might even try to chair it, if there is no agenda.

+1W wfm too.

OK, next week it is then.

7) AOB

None from me.

A bunch, but we are at -7m time budget already, so nvm.

Small note: I've added a new section to the agenda of "Activity Summary" just to note any Last Calls in progress, etc.

It feels like these are easy to lose track of otherwise.

Comments welcome.

dwd: that's great!

If there's nothing else?

dwd, yup, I noticed that, it’s useful. :)

dwd, I like it

8) Ite, Meeting Est.

thanks, dwd

Thanks very much all, soryr for the overrun.

> Kev> I could be persuaded by adding text to the top explaining how this needs to change and that the authors intend to do so as soon as Other Problem is resolved in the community, I think. Which might be a reasonable compromise? I just read about such promise in 0060 about rsm (replacing max_items) and I laughed, (note that rsm in pubsub is now a thing). I'm really torn on this kind of things. I would pray to the legacy lord everyday for software to magically update (and get rid of Debian, RHEL, etc.) if I knew it worked.

I would, BTW, really love to have the concept of a "critical extension" in XMPP.

ASN.1 yeeaaaah

I was about to say that ;)

dwd, yes

You mean <new-feature><critical/></>, where not being able to process it would be something the client needed to care about? ✏

xmlns:xmpp="urn:xmpp" xmpp:critical="true"

(not that format, but that intent)

`<{disco#info}feature var="so-shiny" critical="1"/>`

Kev, Something like that, yes. That way, a client receiving a reaction would know it was missing something.

Kev, I mean, obviously this requires support for critical extensions and so doesn't solve this problem this time. But it might mean that future problems weren't so bad.

I’m all for it

works the other way around, too

jonas’, The other way around?

A client receiving a stanza and not understanding any of the payloads would be a hint already tho?

dwd, clients to servers

thinking of RSM

A 'critical' property seems like a thing that should have been in from the start for it to work

Zash, Yes, but that might be fine - in the absence of critical content it can just ignore the stanza entirely.

jonas’, Yes, true.

Zash, yeah, but late is better than never, I guess

jonas’: "never" is what you get thanks to Pidgin :)

Zash, As I said earlier, I really don't want to predicate everything we do on whether Pidgin will work with it.

I think we have roughly two choices these days 1) Cater to the lowest possible common denominator, and not accept things that won't work for them 2) Be able to do things that can compete with a new system.

It's that simple. If we're only willing to (1), it means we have to start again if we want something better. e.g. Matrix. ✏

Kev, I think it’s not that black&white

Right, I agree. Obviously in practise we try to provide graceful degradation where there's no harm to the network.

I still don’t think that the legacy body would be harm to the network.

jonas’, MUC history?

dwd, <store/> hint?

isn’t that obeyed by MUC history?

Is it?

jonas’, I don't know, is it?

jonas’, It isn't on MUC implementations I've worked on.

dwd, I’d also argue that MUC history is not *that* important anymore nowadays and I can live with breaking it, given MAM.

jonas’, So you're OK with breaking legacy clients as long as we don't break legacy clients?

MUC history is a tricky one I admit

but still, at least you can, with a legacy client, see that something was happening (and is happening)

Yes. I can see that 200 messages of "I am reacting to this message with a heart. Yes, a heart!" is going to be useful to the legacy client.

we have MUCs with 200 participants?

Can't be worse than message correction

flow, in fact, yes ;)

400 even

oh, not anymore

Matrix bridge died?

no, disroot@ lost 200 users

I took a peek, everyone was duplicated with [m] suffixes. So, assuming Matrix bridge.

ah, I see

I feel like the fallback body discussion is a prime example of what could be improved in xmpp land: We do not take the time to get implementation experience and some people appear to really believe that implementations will not put a fallback body, even if it turns out to be beneficial

Kev, this critical feature sounds like a broadened version of what I had in mind for XEP-0380.

"will not put a fallback body in even the XEP requires so" that is

flow, how will you figure out that it’s beneficial when the folks who suffer from it’s absence don’t even notice for quite a while?

I approve.

Link Mauve, neat

now we just need to agree on using prefixed attributes for that ;)

because you can stick those literally anywhere

Prefixes make everything better!

jonas’, I haven't even a clear picture how muc-attaching-reactions-mam actually are going play together. It is way to early to tell anythingn

I think what we discussed at the Summit would be a good start.

sometimes it is tremendous helpful to write down a few stanza exchanges to see what it could look like

then some things get clearer

We should run a Matrix bridge on xmpp.org.

dwd: just for the protocol: I've sent a 👎 emoji reaction to your last standards@ mail, but it was dropped by everybody because it doesn't contain a legacy body.

That's alright, I don't think it had any value :D

Sooooo, multipart/alternative

I was actually thinking that I spent literally years dealing with MIME Preamble because we were stuck with the legacy - unavoidably in that case.

So far, the only non-debunked argument against legacy body is "it will annoy legacy client users", and I think this is an argument pro and not contra legacy body.

"I sent you a reaction but your client doesn't support it. Switch to modern client to get in on that sweet sweet reaction action!"

Well, it'll also annoy non-legacy users, because their MUC join context will be destroyed.

And now as a dev I have to implement reactions if I don't want them. Or for the fun of it, the poezio implementation was written as a plugin during the sprint, and it wouldn't make sense with a fallback body anymore :)

"So if you don't want reactions, load the plugin to ignore them, otherwise load the plugin to read them"

Can you do non-annoying graceful fallback?

Kev: what's a MUC join context? Oh, you mean the limited MUC history, that mostly consists of CSNs?

Yes, that.

I see how legacy reactions will be a game changer there.

Zash: feel free to provide one.

maybe use threads for that!

just put the emoji(s) into a body with the right thread-id

ha, threads

For the record, yaxim has legacy reactions for a while now, and nobody complained so far. And the Emoji are HUGE!

Zash [18:49]: > ha, threads 😬

https://upload.yax.im/upload/fCLNTXQr0YhbBor3/Screenshot_20190731-185205_yaxim.jpg

missed the discussion about https://github.com/xsf/xeps/pull/801 earlier, but I also proposed just not adding text about fallback too (in reply to council minutes), I guess I can put in a PR about that

but as to the questions everyone had about "why could A/AAAA be trusted if SRV cannot" it's because there are a few systems that don't support SRV, so you might be getting your SRV from some place that's compromised and your A/AAAA from another that is not

Tor is the highest profile one I suppose, but also plenty of broken routers etc

I see no harm in falling back, I see harm in MUST NOT fall back, also adding MUST NOT to a draft spec

So another "there are broken clients, therefore we must write wrong specs" argument? ✏

sure, a user sees their XMPP client won't connect, but Whatsapp will, and that means XMPP sucks

they don't know or care why

I'm not sure this line of reasoning is productive or good for my sanity.

Zash, for another example how about a file sharing spec that just assumes everyone has a fully routable ipv6 ?

sure, it'd be a simple, great spec

just totally unuseable in the real world

routable and not firewalled.

so there is always an element of this

moparisthebest: you are going down a slippery slope, very fast.

what if there are xmpp clients not supporting MAM?

you can't cover them all.

moparisthebest, I'm confused. In the case where no SRV records resolve, we fall back to A/AAAA. In the case where at least one SRV resolves to '.', we do not. What's the problem?

dwd, if one SRV resolves to . you can either try to fallback to A/AAAA or give up, I see no harm in trying

moparisthebest, What's the point in '.' then?

nothing probably, at least not with TLS

Isn't the question whether _xmpps IN SRV . means "there's no XMPP here" or "there's no xmpp-over-tls here"

Do, or do not. There is no try.

when nothing is authenticated I guess it's just as good to trust that vs trying to connect

Zash, Nope. That's not the question. The question is "If you get a '.' back from one SRV but nothing from the other, do you use a A/AAAA fallback or not?" ✏

Can we have a flow chart please?

I think with TLS you should always do a fallback, if it succeeds and authenticates, great, if not, oh well, at least you did everything you could

dwd, why would you fall back in that case without trying to use the one that was not a '."?

or what does fallback here exactly mean? fallback using implicit TLS? fallback using implicit TLS first and then STARTTLS?

but I think an answer to Zash's question would be helpful in the discussion, and I think the right answer probably is "there is no XMPP with implict TLS here"

flow, You'd do both lookups for SRV, sure. But if you get a dot-response from one and nothing from the other, what then?

_xmpps doesn't have any default port defined, so you stop that thread? _xmpp has, so you go for 5222

Or if you wanna go and try random IP and port numbers, glhf

I can see an argument that it's reasonable to ignore xmpps stuff completely unless it gives you something connectable, and just go 6120 rules, but ... yeah.

yea I think you try 5222, and if that doesn't work

maybe implicit on 5223 and/or 443, whatever

poke all the ports on the internet until one responds with a proper TLS cert? :D

ALL THE PORTS

> ZMap can comprehensively scan for a single TCP port across the entire public IPv4 address space in 4.5 minutes given adequate upstream bandwidth.

XEP-0368 implementations MUST use this ZMap to scan all 443s as a fallback

> given adequate upstream bandwidth. Can't wait for 5G then

dwd, ahh "nothing from the other" I ready "not from the other"

*read

yeah, then I'd probably do a A/AAAA fallback

flow, Even though you know the domain supports SRV?

I'm actually wondering whether, if you have any _xmpps-* record, including a dot-record, you MUST have a _xmpp-* record, and behaviour is undefined otherwise.

*you know something sent you a SRV response, unless we are talking about DNSSEC here

I've started leaning towards that.

Because I can't image what the administrator intended.

moparisthebest, Yes, yes, blah blah.

Idd.

dwd, yes, cause _xmpps → "." should probably mean that there is no XMPP with implicit TLS, not that there is no XMPP at all

dwd: You could also argue that xmpps_ . with no xmpp_ is a clear misconfiguration, so trying to fallback in the normal way is the best you can do in the face of a daft admin.

But, really, the more I think about this, the more I think it's not daft.

6120 defines fallback if you don't have SRV. That means you don't have to do SRV, because you know the clients will just A/AAAA 5222, and if that's the right way to connect, that's fine.

But that would only hide the misconfiguration from people's eyes, leading to the creation of something that's as messy as the web.

So saying "Yep, do the normal 6120 A/AAAA thing, but I don't support xmpps" starts seeming a lot less daft.

I know I've deployed services and not bothered with SRV because it's just not needed when A works.

I see no requiremnt in RFC 2782 that once you add a SRV RR for one service, you have to add them for all provided services

Kev: also the 10% of clients that technically can't resolve SRV

Ge0rG: Well, they're not affected by this argument, I think, because they won't see the . on xmpps.

But even if there where I would write my clients so that they try to discover as many as possible connection mechanisms and use them

with an extra pranoid setting ignoring SRV "." results if it hasn't been authenticated via DNSSEC probably

But the benefit of xmpps is reduced number of RTTs, if you don't count the DNS RTTs

Kev: I was just saying that you essentially must provide A/AAAA anyway

I think that's only true if you're running a public service and care about broken clients/networks connecting. ✏

flow, I don't *think* a spoofed '.' record is any worse than any other spoofed record.

Most services I care about are not public.

Or have experience with, I should probably say.

Kev: if you don't care about broken client networks, you surely don't need to care about daft admins

I'm starting to argue that it's /not/ daft.

And "Do normal A stuff for xmpp, and I don't support xmpps" is actually a reasonable thing to say.

good point

Kev: what's wrong with putting the normal A stuff into _xmpp SRV?

Why configure more records than you need?

Because a client will query them either way

Unless you define xmpps=. as "skip _xmpp lookup as well", which I really don't see happening

It doesn't really matter as long as clients don't do xmpps fallback, I guess, and that would be horrible anyway.

So yes, the right response to 'why configure more records than you need?' is 'yes, why bother with xmpps=.?'.

In a sensible world, I'd prefer _xmpps over _xmpp because it'll cut off multiple RTTs

Only one, isn't it?

there are more reasons for implicit TLS

> <starttls/> < <proceed/>

There's nothing implicit about TLS on an xmpps_ record is there?

for example it is harder for buggy implementations to leak sensible data in plaintext with implicit TLS compared to STARTTLS

Kev, depends on your definition on what the implicit part is

I think I am using the one of RFC 8314 § 3.

Can't we just agree on "direct TLS"?

Ge0rG, that is what I've been using before discovering that RFC and its definition

flow: an RFC containing an inadequate solution doesn't make it adequate

what would that inadequate solution be you are talkinga bout?

the term "Implicit TLS"?

Yes

With MTA-STS (which is a horrible abomination of a standard on its own), direct TLS also becomes explicit for email submission

If we follow their nomenclature, it's explicit implicit TLS

well I wasn't happy with "Direct TLS" either, so I decided to use the term that is at least established by an RFC

What's wrong with Direct TLS?

what's direct about it?

You start the connection directly with a TLS handshake

I can't imagine a better term.

hmm, kay, if you look at it from that way

for me its just that I like well defined (and ideally established) terms

IIRC I greped the RFCs for "Direct TLS" but could not find any occurance

but maybe my grep-fu wasn't strong at that day

so I probably concluded that it isn't a good term, and was pretty happy when I found rfc8314

In 8314 the term makes _some_ sense, because there is no explicit signaling for when to use Direct TLS.

So it's actually implicit, because you don't know you must use it... 😉

I always assumed that it is about starting TLS either explicitly via STARTTLS or implictly on the establishment of the underlying transport mechanism (e.g. TCP)

if you take signaling into consideration, then yes, _xmpps is not implicit

Yes, but STARTTLS is always indirect.

even if quickstart is used?

and now I go to bed

> flow> yes, cause _xmpps → "." should probably mean that there is no XMPP with implicit TLS, not that there is no XMPP at all Then I'd fallback on _xmpp- first, then A/AAAA if this one is not '.' as well

> Ge0rG> also the 10% of clients that technically can't resolve SRV Some clients also can't resolve A/AAAA :)

As in, directly, without SRV, from what I understand

pep.: you mean they are deliberately crippled and violate the rfc?

pep., You shouldn't actually be "falling back" to _xmpp-*, you should be doing both lookups in parallel and combining the results, I think.

dwd: k

Ge0rG: dunno, I think kaidan on android has some issues with that. I couldn't connect on my server

pep.: that sounds like a serious bug

I'm not the only one to have reported it

But then again, it's Kaidan... 🤷‍♂️

dwd: happy eyeballs style?

dwd: also do A/AAAA in parallel, and recursively follow CNAMEs

You'd probably do only one CNAME query anyway ✏

CNAME processing would be in scope for whatever DNS stuff you have, not the XMPP stuff.

Ge0rG, Well, I'm explicitly doing the 2 SRVs in parallel and then ... I can't recall if I do happy eyeballs with the resulting picked A/AAAA, I might do. I look them both up in parallel, don't remember if I try connecting to them all at once.

dwd: do you have a thing that does _xmpps-server?

Zash, Yes, though not in production right now.