XSF Discussion - 2018-08-06

Implementing direct TLS in a library and running into the mixing of SRV records again. We really need to change this, it makes no sense. I'm ignoring it because I don't want to manually try to mix the records (the DNS library handles ordering SRV records for you, but doesn't let you specify two different services because that's not how SRV works)

And if the server operator wants to prefer StartTLS they can always just not set SRV records, so I don't see that it actually provides any benefit.

Also if we mix them and one has a "." record (no such service), what does that even mean? No XMPP server at this address, or no direct TLS at this address? What if one has "." and one has a proper record?

Nonsense is what it means

And headaches

Yah, these rules drive me nuts.

SamWhited, Arnt Gulbrandsen disagrees with "that's not how SRV works". ✏

SamWhited, Also I really hope you meant "selecting" rather than "ordering".

The SRV spec agrees; as far as I can tell. At least, I can't find anything that tells you to treat two services as one service and how you handle things like a "no such service" record.

What's the difference?

SamWhited, The SRV spec says "This is a default, but the application protocol can say whatever it likes". And you can't "order" SRV records, as such. I mean, there's no fixed order of multiple SRV records at the same priority - you could order them but they'd be an unstable order.

SamWhited, So yeah, basically you can't use your DNS library's built in SRV selection. But then, you can't with - possibly - any protocol that's formally defined to use SRV now.

Seems like we added pointless complexity because other protocols *might* have pointless complexity then.

SamWhited, Well, no, we've been following along with other existing protocols. Doesn't mean we can't change it. I'm just looking at RFC 6168 versus RFC 8314 now.

and there's still no indication what '.' means.

I'll go look at those

when I'm back at my desk if I haven't already

SamWhited, RFC 6168 covers that, too (and uses mixed priority as we do for IMAPs/IMAP, for instance). RFC 8314 updates that to say clients should always prefer "Implicit TLS".

I'd be absolutely fine with updating to match that, by the way.

What's "Implicit TLS"?

Ge0rG, non-STARTTLS

Is it the opposite of "Direct TLS" or of "Explicit TLS"?

others call it Direct TLS

And what's explicit?

is it explicit to use a TLS port or to use a TLS command?

Explict is the use of STARTTLS

are you genuinely interested or trolling?

cause I’d like to not waste my evening with trolling :)

people are bad at names.

yes

we knew that

No, I was genuinly confused what that means. Thanks

you’re welcome :)

Ge0rG, "Implicit TLS" is what RFC 8134 uses: https://tools.ietf.org/html/rfc8314#section-3

Ge0rG, I don't *love* the term. But it's too late to change the RFC, and it's no worse than any other term really.

It's accurate

I'm not sure it is, but I'm a confused non native speaker

I like Direct TLS vs STARTTLS as terms

Ge0rG, Sure. But if the rest of the internet is using a different term, I'm fine with changing.

Dave Cridland: if by "the rest of the internet" you mean a bunch of nerds pretty much similar to us, I'm not sure I agree.

Let's call it wannabe-ipsec

:D

Zash, nooo

Ge0rG, Well, I mean the IETF, or at least the Internet Mail folks, who are as similar to us as is possible to be (indeed, half of them have been involved in XMPP stuff at the IETF).

Dave Cridland: maybe they just didn't spend any time on the term, and whatever wasn't absolutely idiotic did stick?

do you seriously believe that such a thing wasn’t bike-shedded?

Ge0rG, Sure. But that's basically what we did.

it’s terminology after all

jonasw, I think it's nomenclature, actually.

well played

Psst, http://www.smbc-comics.com/index.php?id=3907

jonasw [22:03]: > do you seriously believe that such a thing wasn’t bike-shedded? Yes. Otherwise they'd have come up with a better term.

Ge0rG: Terminology by committee!

I don’t find it extremely bad

Zash: that directly brings back my question of Nickname vs Name vs Screen name.

screen name is good in en

jonasw: I do.

but I don’t think it translates well in any language I know

"Anzeigename" is moderately cumbersome

also I’m not sure it would be clear to the typical user what this even is

(I find it not more cumbersome than "Screen name", although that’s probably hard to judge) ✏

What do other things call it?

Yeah, maybe "screen name" is bad as well

probably just "Name"

Still better than Implicit TLS

(it's not implicit because you do a TLS handshake)

but it’s implicit regarding the lower layers

which isn’t the case with STARTTLS

but yeah, Direct TLS is less ambiguous in that regard

START THY TLS! is pretty explicit

what just happened: https://sotecware.net/images/dont-puush-me/IrUXvlA_MXTM4ecUHM4ve-TDSXUcHRHBN8_rU85-P_k.png

jonasw: hm?

jonasw: Why there's a room with >300 participants out of a sudden?

more than one room with >200 at least

and kuketz-blog and conversations being kicked off the 1st/2nd position in the listing, which they’ve had for weeks now

jonasw: Auto-injected auto-join bookmarks, if my german comprehenion is sufficiently accurate

ah, neat

jonasw: for all new(?) registrants

(why tho)

ah

for new ones it might make sense

hmm

jeopardises the listing a bit, but let’s see how things play out

Someone said because users complained about lack of notice about some downtime

m(

It was only on Twitter or somesuch

isn’t there mod_announce for that?

Myeah

you can even send a type="headline" which will steal your focus if you’re using pidgin

anyways, heading to bed now, see ya folks

I'm not sure how it helps to announce downtime in a MUC

Ge0rG: If all your users are in it...

Works for offline users without MAM

(while the server is up, of course)

Zash: if your server is down. Also Schrödinger's Chat

Ge0rG: I understood this as notice about future planned downtime

*before* the actual downtime