dwdIn my view, you can't add a bunch of stuff about SRV fallback into XEP-0368.
jonaswdwd, not even if it defines new SRV records?
moparisthebestdwd, the thing is, the SRV fallback, uh, algorithm?, affects how a server admin MUST set up their records
moparisthebestas I found out the hard way, dino tries xep-368, doesn't do alpn, and does not fall back if the TCP connection succeeds
moparisthebestno one using dino can use my server then
jonaswmoparisthebest, I’m not sure why a server operator would give ALPN-requiring SRV records high priroity though
jonaswthat is, preference
dwdSure, but those records are defined in RFC 6120, and not in XEP-0368. Ideally, we'd merge '368 into an RFC update, mind, but the SRV fallback strategy applies to any SRV records, not just ;368 ones.
moparisthebestbecause I prefer them to connect that way first, it works in all my other clients :)
jonaswputting them with low preference in the list would work for the case where 5222 is filtered, wouldn’t it?
moparisthebestdwd, well sure but more to say 'if you implement 368, you MUST implement SRV fallback like so...'
moparisthebestthat wouldn't be appropriate?
moparisthebestand I agree re: RFC update, but until then, it should be specified *somewhere*
ZashIs there not precedent in writing down things in XEPs that are later rolled into RFC updates?
KevThere is, but in this case it's something that implementing just the RFC won't be able to connect to at all.
KevWe can't really have things in SRV records that connect ok at the TCP level but then fail for 6120.
jonaswKev, they don’t fail for rfc6120
jonaswbecause RFC 6120 doesn’t konw a thing about TLS over XMPP
Kev> as I found out the hard way, dino tries xep-368, doesn't do alpn, and does not fall back if the TCP connection succeeds
> no one using dino can use my server then
KevSo this isn't SRV fallback, it's 368 fallback.
jonaswKev, yeah, but that’s because dino fails to implement xep-0368 (by adding ALPN) but still tries XEP-0368 records first.
dwdWelcome to write a SRV fallback strategy in a new XEP. Just not in '368.
moparisthebestKev, no it's SRV fallback in general, the rules are not defined
jonaswmoparisthebest, but technically there would be no issue to let clients prefer the 5222 method, would there?
dwdKev: It's not specific to '368 direct TLS SRV records.
Holgerjonasw: ALPN is a SHOULD in 0368.
moparisthebestother than then they would try that first, might be a bit slower, I wouldn't prefer it
jonaswmoparisthebest, okay, so it’s actually a configuration issue at your side, IMO
moparisthebestall I'm saying is the way you set up records depends on SRV fallback behavior, 368 or not, it just happens to matter more with 368
moparisthebestor be more visible
jonaswpreferring a 443-multiplexing-hack over something which works with all clients seems broken to me.
moparisthebestso I'd probably want to put this in 368, or create a new SRV fallback XEP, and make 368 depend on it
moparisthebestwould the second be ok if you don't like the first?
HolgerWhy not make ALPN a MUST?
moparisthebestvarious reasons, still support isn't widespread, but also privacy reasons
Holger(I don't like ALPN at all, but that SRV fallback seems even uglier to me.)
moparisthebestALPN support is far better in 2018 than it was in 2015
moparisthebestwell again SRV fallback is an issue without 368/alpn too
dwdmoparisthebest: Not sure that 368 needs to depend on it at all, really.
jonaswmoparisthebest, how is it an issue without 368/alpn?
moparisthebestjust one example of many, you have multiple servers for redundancy
moparisthebestand your top priority one messes up, has wrong certificate, accepts the connection but the xmpp server is messed up, any number of ways
moparisthebestnow nothing falls back to the other ones, oops you actually have no redundancy
HolgerShould we fall back if everything succeeds up to the bind request?
moparisthebestI think I covered a few such scenarios in my email, I remember the BGP one :P
KevAs I mentioned on list, I think, things can go wrong post-bind too.
dwdFair warning: I'm going to shut you all up in fifteen for the Council meeting, BTW.
moparisthebestyea I don't know the exact point we define as 'no more fallback', it seems clearer on c2s to me than s2s
dwdBut if somebody wants to hang about and do the minutes...
dwd(Since you're all here).
moparisthebestbut right now it's totally ambiguous/wrong in the RFC
SamWhitedPlease hang around and do the minutes; live minutes are the best minutes!
dwdI can't do them this time; I'm on a train - and since this train gets into Paddington at 16:30, I'm on a hard stop for the meeting.
moparisthebestbut the general council consensus seems to be defining SRV fallback should be new xep?
moparisthebestif so, I'll try to find time to work on that
KevI think a new XEP seems most appropriate here.
moparisthebestthat's fair, will be easiest to work out the details there too
SamWhitedHaving it in 0368 seems fine to me, but we probably want to work out the details somewhere else first.
SamWhitedSince 0368 is in draft.
moparisthebestat a basic level, if you stop at TCP connection, or any place before at least validating the certificate, an attacker controlling a path to any higher priority server can prevent a successful connection, and that's wrong
dwdOooh, every device I have just told me Council's in ten minutes. How exciting.
dwdSamWhited: I'd actually like to get everything sorted in XEPs, and we'll gather them into an RFC to update RFC 6120. (As in, an RFC that updates, not an RFC that obsoletes, unless the mythic XMPP2 stuff actually happens)
SamWhitedThat makes sense too
SamWhitedWe could also combine with 0368 if/when the SRV fallback one goes to draft if it doesn't look like an RFC is going to happen.
dwdIt might *even* be worth doing this straight into an Internet Draft... We'd get review from the IETF folks on this. I was chatting to Chris Newman at the weekend about XEP-0368 anyway. (Chris did STARTTLS back in the day, and now leans toward direct TLS).
Ge0rGSTARTTLS always felt like a hack to me.
ZashDirect TLS is the hack! :(
MattJWhat would you have done at the time?
MattJHTTPS spent a long time with the IP-per-host situation
Ge0rGMattJ: what HTTPS did. One certificate per IP address.
dwdGe0rG: There were lots of reasons behind STARTTLS. None of them apply anymore (or the arguments are massively weakened)
SamWhitedDirect TLS just makes sense now that everything should be TLS… why use application level protocol negotiation to negotiate something at a lower level in the stack? Just do the lower level thing first, then do the application level thing.
Ge0rGdwd: I know
dwdSamWhited: Sure... But back in the day, there was also Kerberos etc. It's just that now, Kerberos runs over TLS, instead of doing its own crypto.
Ge0rGNow let me get started about how the CA industry and the NSA lobbied us security folks into believing that no security is better than opportunistic security.
Ge0rGOr maybe we skip that for the Council meeting.
dwdSo I should warn you all that I'm on a train, therefore on a number of G's hopefully more than 3.
ZashRelativistic G-forces? Ouch indeed
Ge0rGdwd: I can't imagine regular trains exceeding something like 1.5G
dwd1) Roll Call:
dwdI'm for bacon and cheese, myself.
Ge0rGbacon and cheese rolls? I'm in!
SamWhitedI thought I was supposed to be the one to ask for cheese? We put cheese on (or in) everything.
KevI'm here, obviously.
SamWhitedI guess I'll have to ask for kippers just to even things out.
dwdOK, I don't see daniel but maybe he'll join us later.
dwd2) Advance XEP-0066 to Final
Ge0rGIt looks like there was some major resistance to that.
KevIt's not clear to me that we have satisfied the implementation requirements, even ignoring all the other issues onlist :)
dwdI think I'm -1 on this, I don't think it meets the implementation criteria.
KevSo I don't think it even needs a Council vote, I don't think it meets requirements for us to vote.
KevBut if it did, I'd be -1.
Ge0rGI still think 66 is a good candidate for the "take the best parts and run" approach suggested some Meetings ago
dwdKev: I'm actually unclear who decides the implementation criteria, so I shall assume that's for us to veto if we believe it doesn't.
dwdSamWhited: Any vote?
SamWhitedIt seems "good enough" to me, I'm +1. Although with the note that there is a bit of awkwardness and I agree that "take the best parts and run" sounds good too.
dwd3) Advance XEP-0048 to Final
dwdNote there is a competing proposal in bookmarks2, we're voting on that later.
dwdI'm -1 to advance, I'd rather move this to historical again.
SamWhited+1 to freeze 0048 and new work can go into bookmarks2
KevAgain, this wasn't clear that there are two independent implementations of what's specced in this version. Plus assorted issues with it.
SamWhitedAlthough I also agree that this could be historical.
Ge0rGSamWhited: freeze as final or as historical?
SamWhitedFreeze as in final, but if we want to have a historical vote I'd +1 that either way.
dwd4) Adopt Proposal "Bookmarks 2 (This Time it's Serious)"
Ge0rGI'd like to see where Bookmarks2TTiS leads
KevAside: I'd be in favour of revert 48 to iq:private, and make it Historical, and advance bookmarks2 in PIP.
SamWhited+1 assuming "adopt" means "accept as experimental"
Ge0rG+1 to what Sam said
dwdFor the record, I'm happy if this changes title, but it'd be good if we changed '48's title at the same time...
KevSuggestion: Change 48 to Bookmarks in Private Storage, and change TTiF to Bookmarks in Pubsub or something.
KevIf we want to change titles.
SamWhitedI would be -1 to reverting it to private storage.
KevEven while also changing it to historical (documenting what's in place), when it's what's in place and PIP isn't?
KevEither change the text to be clear that there's a bad state, which is a clarification, or change the text to be sensible and avoid the bad state.
KevFlow's is the technically better change, I think, but is a breaking change to xep50.
KevMine is just clarifying that if you do something in particular, you're being stupid.
dwdKev: Breaking in theory or practise?
Kevdwd: This conversation came about because of people doing silly things. So I think in practice.
KevAlthough possibly not in an untenable way.
Ge0rGWouldn't it be better to fix things in practice then?
KevGe0rG: Well, that's why my text explains that doing this is broken. Which it always has been, people just don't realise.
KevI'm -1 on Flow's PR as-is, because I think it needs to explain the breaking change, but I could be persuaded either way on the basic approach. Noting that breaking changes to Draft XEPs we should be trying to avoid.
Ge0rGKev: if people didn't realize that, they probably never ran into the issue so fixing the XEP to have a better behavior won't make them run into even more things?
SamWhitedI'm +1 to flows change, but also agree that an explanation would be useful.
KevSamWhited: What's the justification here for a breaking change to a Draft XEP?
dwdHmmm. So I think I'm +1 on one of these, but I'm not sure I care which...
KevI think I can be persuaded about making the breaking change, but I don't think I am yet.
dwdKev: I'm not sure what this change is breaking. I mean, it means something works which previously did not.
Kevdwd: It means behaviour will change.
Ge0rGdwd: people following the "new" XEP could run into broken servers
dwdGe0rG: Ah, good point.
KevWhere previously an illegal state would prevent you doing anything other than cancel, now it'll silently succeed in doing something that it wouldn't before.
Ge0rGso I'm +1 if we add a note similar to what we did in 0045 last week
Ge0rGI'm not insisting on a feature though.
dwdKev: I think that's a stretch for a claim this is breaking, though.
KevI think if you change the required behaviour of entities, that's a breaking change.
dwdYeah, I think I'm +1 on both of these.
SamWhitedIt seems worth cleaning this up, and since it doesn't seem like it would be the end of the world we might as well do it right.
KevOh, wait wait.
KevI think both PRs might actually be wrong.
KevBecause execute is used for setting a default.
dwdYou're going to veto your own PR?
KevSo in Flow's case, I think this change means that where it was previously possible to set 'no default', now it forces a default to be set.
KevAnd in my case where I claim it's not a legal state, actually it is saying that there's no default action.
KevExcept that's also contradictory.
Ge0rGNow I'm completely lost.
dwdSo in this case I'll change my vote to no vote, and can you take this to the list.
dwdAnyone voting on this one?
Ge0rGKev: ELI5 on-list please.
KevWe -1 both of these PRs now, and we each commit to reading this bit of the XEP *in detail* until we understand it properly, and then discuss properly next week.
SamWhitedyah, I'll also go on list since this wasn't my understanding
SamWhitedI'll re-read and make sure I didn't interpret something wrong.
KevBecause I spent a good chunk of time on this and I think I got it slightly wrong last time.
Ge0rGKev: feel free to collaborate with flow so that you prepare a single PR :)
dwdGe0rG: SamWhited: You vetoing or what? I'm completely lost now.
KevThis is a badly defined bit of spec.
KevI am -1 to both for now.
dwdKev: Badly specified bit of definition.
SamWhiteddwd: I am on list.
Ge0rGdwd: on-list as well
dwdCool. For the next one too?
SamWhitedYes, sorry, for both of these PRs.
KevYes, on-list might work for me too, I guess, default to -1 if I don't reply :)
Ge0rGKev: is that a -0.5?
dwd7) XEP-0223: Add a warning about publish-options support
KevPeter always liked it when Isode folks disagreed on list. I wonder what he thinks of Isode folks disagreeing with their own PRs :)
dwdThis seems like a +1
Ge0rGthe PR comes with a notice about making discovery a MUST.
Ge0rGCan we vote on that too?
dwdKev: I've rejected my own protoXEP once. I think I beat you. (So has Peter, mind)
Kevdwd: Yes, but that was a protoXEP, I don't remember anyone doing it for a PR (but might have).
KevAs a note to Editor, PEP needs to change to Pubsub in this PR before merge, I think.
KevThis isn't storing anything in PEP.
SamWhitedoh good point; add a note on the PR?
jonaswKev: put that on the pr please
Kev(Meaning is clear, but terminology is wrong, commenting now)
dwdOK, I'm changing my mind and vetoing - yeah, I prefer MUST check discovery and I'm find with changing it to Pubsub.
KevI'm fine with just giving a provisional +1 to the PR after SHOULD/MUST and PEP/Pubsub, if that speeds things along.
Ge0rGdwd: couldn't you "+1 under the following conditions" instead?
dwdWell, probably. But I'll hold a veto on it to make sure it happens. :-)
SamWhitedI also prefer MUST, I figured we might as well go ahead and merge this, but if a pr changing the wording can happen quickly that's fine too.
dwdBut yeah, I'll change to a +1 the moment the MUST happens.
dwd8) Next Meeting
dwdI have a feeling that Europe changes timezone at the weekend, is that right?
KevYes, Sunday at 1AM
KevWhich is great news for those of us running a 10K Sunday morning.
dwdShall we shift it to 1500Z in that case for next week? (Sorry SamWhited).
Ge0rGSo it will "move" to 1700 CEST?
dwdEveryone else in agreement? (Just keeping it at the same time next week for Europeans, and messing Sam about)
dwdGe0rG: Erm. Yes?
SamWhitedI will most likely be getting off the bus at that time, so I'll be late probably
SamWhited15:15Z would probably be better, if we could do that.
KevThat'd work for me next week.
dwdOK, 1515Z then. I'm fine with that.
dwdHopefully not because we're coming into Paddington.
Ge0rG+1 for 1515Z
Ge0rGI wanted to vote on abolishing Pidgin.
jonaswceterum pidgin delendam esse
dwdAssuming none, or at least nothing serious...
dwd10) Ite, Meeting Est.
Ge0rGI feel cheated now. I was told we can vote on *anything*!
dwd(If nobody else is writing minutes, I'll get to them... eventually.)
dwdGe0rG: Yes, but not every vote will have any effect...
Ge0rGdwd: sometimes it is purely about the signals we send and not about actual actions.
Ge0rGThanks, though :)
SamWhitedMotion for all XSF business to be conducted in Latin from now on.
Ge0rGMotion to change "Latin" to "Latin-15"
Ge0rGMotion to change "Latin" to "Latin-9"
moparisthebestutf-16 with a BOM ?
ZashMotion to deprecate the letter U
ZashNo need for U when we have V
moparisthebestooh can you abolish BOMs
ZashDon't yov agree?
KevZash: But we don't have V.
Ge0rGObligatory reference to http://grammar.ccc.commnet.edu/grammar/twain.htm
Kev(Welsh doesn't have K, V, X or Z)
SamWhitedOr vowels, apparently.
Ge0rGNow someone needs to make a cheap pun on the pronunciation of I, U and V.
moparisthebestbut re: starttls discussion I missed pre-meeting, it was 100% the correct way to go at the time, in my opinion
SamWhitedI love that possibly-Twin thing, I wonder if that was the inspiration for Guy Steel's "Growing a Language" talk (which is fantastic and you should watch it): https://www.youtube.com/watch?v=_ahvzDzKdB0
moparisthebestin fact it seems to me IANA basically required it at the time for port assignments and such?
moparisthebestand today, it's worse than useless and everything should just be direct TLS, just something that changed meh
Ge0rGmoparisthebest: STARTTLS always was a dirty hack. It just happened to be the only viable dirty hack for some years
moparisthebestyes, the only viable and officially IANA/IETF sanctioned hack
DaveI'm actually sitting next to its author now.
DaveChris recently wrote an I-D saying its time was passed, I think.
ZashWait wasn't IETF last week? Or is it now?
DaveNow. I'm in the plenary.
ZashMy sense of time is weird.
DaveStarted last Saturday, mind.
moparisthebestI thought I read that but can't find it now, all I can find is a lone blog post https://www.agwa.name/blog/post/starttls_considered_harmful