XSF Discussion - 2018-08-06

  1. SamWhited

    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)

  2. SamWhited

    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.

  3. SamWhited

    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?

  4. Zash

    Nonsense is what it means

  5. Zash

    And headaches

  6. SamWhited

    Yah, these rules drive me nuts.

  7. Dave Cridland

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

  8. Dave Cridland

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

  9. Dave Cridland

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

  10. SamWhited

    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.

  11. SamWhited

    What's the difference?

  12. Dave Cridland

    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.

  13. Dave Cridland

    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.

  14. SamWhited

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

  15. Dave Cridland

    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.

  16. SamWhited

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

  17. SamWhited

    I'll go look at those

  18. SamWhited

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

  19. Dave Cridland

    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".

  20. Dave Cridland

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

  21. Ge0rG

    What's "Implicit TLS"?

  22. jonasw

    Ge0rG, non-STARTTLS

  23. Ge0rG

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

  24. jonasw

    others call it Direct TLS

  25. Ge0rG

    And what's explicit?

  26. Ge0rG

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

  27. jonasw

    Explict is the use of STARTTLS

  28. jonasw

    are you genuinely interested or trolling?

  29. jonasw

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

  30. Ge0rG

    people are bad at names.

  31. jonasw


  32. jonasw

    we knew that

  33. Ge0rG

    No, I was genuinly confused what that means. Thanks

  34. jonasw

    you’re welcome :)

  35. Dave Cridland

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

  36. Dave Cridland

    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.

  37. Zash

    It's accurate

  38. Ge0rG

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

  39. Ge0rG

    I like Direct TLS vs STARTTLS as terms

  40. Dave Cridland

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

  41. Ge0rG

    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.

  42. Zash

    Let's call it wannabe-ipsec

  43. jonasw


  44. pep.

    Zash, nooo

  45. Dave Cridland

    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).

  46. Ge0rG

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

  47. jonasw

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

  48. Dave Cridland

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

  49. jonasw

    it’s terminology after all

  50. Dave Cridland

    jonasw, I think it's nomenclature, actually.

  51. Dave Cridland tries to look innocent.

  52. jonasw

    well played

  53. Zash

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

  54. Ge0rG

    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.

  55. Zash

    Ge0rG: Terminology by committee!

  56. jonasw

    I don’t find it extremely bad

  57. Ge0rG

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

  58. jonasw

    screen name is good in en

  59. Ge0rG

    jonasw: I do.

  60. jonasw

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

  61. Ge0rG

    "Anzeigename" is moderately cumbersome

  62. jonasw

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

  63. jonasw

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

  64. jonasw

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

  65. Zash

    What do other things call it?

  66. Ge0rG

    Yeah, maybe "screen name" is bad as well

  67. jonasw

    probably just "Name"

  68. Ge0rG

    Still better than Implicit TLS

  69. Ge0rG

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

  70. jonasw

    but it’s implicit regarding the lower layers

  71. jonasw

    which isn’t the case with STARTTLS

  72. jonasw

    but yeah, Direct TLS is less ambiguous in that regard

  73. Zash

    START THY TLS! is pretty explicit

  74. jonasw

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

  75. Zash

    jonasw: hm?

  76. Zash

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

  77. jonasw

    more than one room with >200 at least

  78. jonasw

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

  79. Zash

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

  80. jonasw

    ah, neat

  81. Zash

    jonasw: for all new(?) registrants

  82. jonasw

    (why tho)

  83. jonasw


  84. jonasw

    for new ones it might make sense

  85. jonasw


  86. jonasw

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

  87. Zash

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

  88. jonasw


  89. Zash

    It was only on Twitter or somesuch

  90. jonasw

    isn’t there mod_announce for that?

  91. Zash


  92. jonasw

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

  93. jonasw

    anyways, heading to bed now, see ya folks

  94. Ge0rG

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

  95. Zash

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

  96. MattJ

    Works for offline users without MAM

  97. MattJ

    (while the server is up, of course)

  98. Ge0rG

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

  99. Zash

    Ge0rG: I understood this as notice about future planned downtime

  100. Zash

    *before* the actual downtime