DaveYes, sorry, just on a call. There in one minute.
Ge0rGIt is this time of the week indeed
SamWhitedoh wow, it's later than I thought
SamWhitedquickly makes coffee but is here
DaveSorry about that.
Dave1) Roll Call [https://en.wikipedia.org/wiki/Roll_Call_(IQ_album)]
Ge0rGSamWhited: it always is.
Ge0rGLooks like I have some significant lag.
DaveLooks like we have everyone. My apologies for being late, there - a call at precisely the wrong moment.
SamWhitedGe0rG: It's too early in the morning to be making big existential statements…
Dave2) Isn't it nice that Tedd Sterr does the minutes?
Dave(Which it is, very nice).
Dave3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX)
Title: XMPP Connections across HTTPS (HACX)
This specification defines a procedure to look up various connection
methods for an XMPP server over HTTPS, with a focus on censorship
DaveI believe this has been updated now, but I don't know if the new version has been published.
DaveIndeed, the requirements look updated to me, too.
Ge0rGIt references 0156 as something inappropriate because inflexible, but I'm not convinced we can't use http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property for the desired use case
DaveMy own feeling is that if you want to circumvent firewalls, censorship, etc, then you should probably be using Tor, etc.
KevI'm perplexed how you're supposed to find the right server to make the HTTPS request to, given that it claims that, unlike DoH, you don't need to trust any third-party DNS.
DaveAnd if Tor doesn't masquerade or steganographise itself, than fix that instead.
KevOh, is that what it's for? I don't think that's actually listed in the Requirements (or I'm being dense, which is always possible).
Dave"Needs to look like HTTPS".
DaveWhich it won't of course, beyond a matter of "It's TLS to the same port".
KevBut it *is* HTTPS isn't it?
KevJust to a .well-known.
DaveHACX is, but I think the intent is that the XMPP session can also look like HTTPS.
SamWhitedI didn't read that that ways
KevI'm not getting that from reading the XEP at all.
SamWhitedThe title was the part that read that way to me and felt misleading.
KevAs far as I can get from reading it, it's just trying to be 156 with some extra payloads.
DaveIf it's intended to be '156 with a bit more, then it can be done as extensions to '156, right?
Ge0rGI had the same feeling as Kev, see above re Link/Property.
KevIt seems that way to me, but we seem to have people with vastly different readings of what it's trying to do.
danieli’m not really sure how that XEP is supposed to circumvent censorship (it think it is meant to be used in conjunction with domain fronting). in any case as long as the XEP is formally correct and not 'complete garbage' i don't think we need to make the call about 'usefullnes' or 'duplicates other xep' right now
DaveKev, See, for example, the PR title: https://github.com/xsf/xeps/pull/627
jonaswthe author stated somewhere that the intent is to circumvent censorship
jonaswin some MUCs
danielthats - if i'm not mistaken - only a requirment when going from experimental to draft
KevI think 'duplicates existing XEP' is one of the sensible reasons for rejecting a protoXEP, actually.
jonaswyeah, that was my understanding, too, Kev
Zashunless intended to replace it?
KevDave: Interesting. I completely didn't get that from the XEP contents.
KevZash: It says that 156 doesn't contain the information needed, but I'm not sure at this point that the information can't be added to 156.
moparisthebestI listed why I didn't think it duplicated other XEPs in requirements
SamWhitedYah, I agree with Kev. One of the frustrating things about developing for XMPP is searching the big xeps list and finding 3 things that all seem like they do the same thing and not knowing which one to use.
Ge0rGIf it wants to replace 0156, it better have a damn good rationale for reinventing the wheel.
moparisthebestand why I thought we couldn't use/extend other XEPs
SamWhitedWhether this does or not is up for debate; but we should figure that out and if we want to eat that cost before going to experimental.
moparisthebestif I was wrong about those, happy to just do that
jonaswyeah, from http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property (linked by Ge0rG earlier) it seems that XRD can easily extended
DaveOK, I think we should vote.
moparisthebestand yes it's to circumvent censorship in the same way that signal/telegram are pulling off in russia for example now
DaveKev, Ge0rG, daniel, SamWhited : Votes please.
Ge0rGBTW, domain fronting has been disabled by Google and Amazon now.
SamWhitedmoparisthebest: does anyone actually allow domain fronting anymore
KevI'm -1 for now because I'd like to investigate not reinventing 156, but leave the door open to using this instead of it transpires 156 isn't suitable.
moparisthebestamazon still allowed it at last check, technically
Ge0rG-1, because I don't see a reason this can't be made an extension to 0156.
moparisthebestthey told signal 'don't do this please' but it still works
SamWhitedI am -1 for now. I think the title is misleading (makes me think it's a transport over HTTP) and we need to decide if we want a new thing or to merge it into the old thing, which seems like a longer discussion than we want to have here.
moparisthebestGe0rG, I specifically addressed that: Discovering Alternative XMPP Connection Methods (XEP-0156)  has a similar HTTP .well-known URL document, but since the XSF doesn't control the namespace we can't extend it with the extra required attributes to support weight/priority/alpn/sni and pinned keys, along with future methods. The business rules also state that it must only be used as a fallback which is in direct opposition of what HACX requires.
Ge0rGthey told signal "don't do this or else"
DaveI'm -1; I think avoiding censorship is best done by Tor etc.
Ge0rGmoparisthebest: I've read that.
Ge0rGmoparisthebest: please explain to me that you can't add a different-namespace element to <Link> or have an encoding for <Property> values to express what you need expressed.
moparisthebestI didn't think you could, if that's possible it's worth considering for sure, but then what about all the incompatible business rules?
DaveOK, discussion over, we'll move on now.
Ge0rGmoparisthebest: you can change the business rules of 156 if desired.
Dave4) MIX Split
Sayeth Kev: "Steve and I are looking at splitting up MIX at some point in the future. In the past it’s happened that when an already-accepted spec has been split into multiple that the Editor’s just published the ‘new’ XEPs without Council voting, as Council’s already accepted the content. Does anyone have any objections if we follow that principle here, or would Council like to go through voting processes for each split?"
moparisthebestI'll wait until meeting end and bring this back up Ge0rG thanks
DaveI think most of us have responded to this - anyone feel strongly either way?
Ge0rGI'd like to see MIX split up into many baby-MIXes, and I don't see a need to vote each of those.
jonaswas I was CC’d to the request, I’m happy to do whatever council decides on this matter. A split would be great.
KevI feel fairly strongly that, given the split is a thing that I think Council either want or don't care about, and it's going into multiple documents, it's going to be fiddly and annoying to vote on everything in the right order, and we should just Do The Right Thing.
DaveI would prefer MIX to be split, and would prefer not to make technical changes at the same time just out of good practise. Otherwise, split away.
Ge0rGAgree with Dave. Separate editorial changes from technical ones and I'm fine.
DaveSo I'll take that as assent from everyone.
SamWhitedI would prefer that all the unnecessary stuff from MIX be split, but then just thrown away and not put into new documents which will just be even more confusing and hard to find.
danieli already gave my ok at the list; but i'm happy to vote +1 if it comes to a vote
Davedaniel, Tempting as it is to vote on whether or not to vote, I'm not going there. :-)
DaveAnyone got Any Other Bollocks?
Ge0rGI propose to have a vote on whether we should perform meta-votes or not.
DaveGe0rG, We can vote on whether to do that or not.
Ge0rGDave: sure we can?
DaveGe0rG, Not entirely.
DaveAny *serious* Other Business?
Dave6) Next Meeting
Kev(No AOB here)
Dave23rd May 2018 1500Z?
KevSBTSBC should work for me.
danielworks for me
Ge0rGI'm not 100% settled in my new project yet, so 1500Z might prove problematic in the next month or so.
Ge0rGBut no reason to change the time for everybody.
DaveGe0rG, If it's a problem, shout and we can move the time to one convenient for everyone.
Dave7) Ite, Meeting Est.
moparisthebestso as far as extending 156, it looks like using http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property it could represent all needed extra info, that's not a problem
moparisthebestnot quite sure how you'd represent the same in the host-meta.json format, but maybe we just add extra tags in there
moparisthebestthe real problem is the business rules, can we change them in a Draft standard? https://xmpp.org/extensions/xep-0156.html#httpbizrules of the 3, 1 and 2 would just need removed entirely
moparisthebest1. HTTP queries for host-meta information MUST be used only as a fallback after the methods specified in RFC 6120 have been exhausted.
moparisthebest2. A domain SHOULD NOT present information in host-meta link records that is available via the DNS SRV records defined in RFC 6120.
Ge0rGDave: thanks, I'll keep that in mind
moparisthebestwould have to remove those
moparisthebestwell, *technically* not #2 because I'd be representing XEP-0368 SRV records and not RFC 6120 SRV records, but still might be best to remove it
Ge0rGmoparisthebest: I think that #2 is harmful independent of your ideas.
Ge0rGBecause SRV is unreliable in practice (Surprise!)
moparisthebestyea, and can't actually be done over Tor fyi
moparisthebestI mean, not without doing dns over https over tor or something
moparisthebestactually hang on, representing the current hacx attributes as <Property/> would be straightforward, but what about the public-key-pin elements ?
moparisthebestyou'd either need to do something insane like <Property type="public-key-pin-1"> <Property type="public-key-pin-2">
moparisthebestor something like seperating them with semi-colons inside the value?
moparisthebestnot *excellent*, not a deal breaker either
daniel> One of the frustrating things about developing for XMPP is searching the big xeps list and finding 3 things that all seem like they do the same thing and not knowing which one to use.
people should be looking for draft or stable xeps only. in general i don't see a problem with competing experimental xeps. it's just that our process is broken in a way that for a lot of vital functionality people are forced to use (and trained to use) experimental xeps. which is the real problem
danielalso the unfiltered list of xeps is probably not the best starting ground for new comers
SamWhitedIf it worked that way I'd agree, except that MAM still isn't draft and Message Archiving would still have looked like something worth using until very recently. I've been trying to trim that down, but I still think we don't have a good process for making sure the draft XEPs keep up with what the community is actually doing (or are what we think the community should be doing, either way)
danieland doesn't have to be. that's what the compliance suite (or other more suitable means) are for
SamWhitedSame with the compliance suites; I agree they're a bette rway to get started, but we're not quite there yet. They're still hard to discover.
Ge0rGthe problem here is that once it's Draft, you can't touch it any more
moparisthebestso any thoughts about 1. Whether most business rules for 156 can be nuked and others added?
Ge0rGmoparisthebest: I don't know XRD well enough, but what about having multiple Properties with the same name?
moparisthebestand then 2. if <Property> is suitable for public-key-pins
danieli mean i totally get where you are coming from; but fixing our broken process of xeps not moving fast enough through the pipeline by essentially not accepting experimental xeps anymore or putting them to unreasonable high expectations doesn't seem like the right fix
moparisthebesthmm not sure if that's allowed Ge0rG , I'll see if I can figure it out
Ge0rGmoparisthebest: that might still be problematic if you need the pins ordered.
Ge0rGmoparisthebest: the process for the bizrules would be to make a PR and let council vote.
moparisthebestno the pins don't need ordered
moparisthebestare changes to draft business rules allowed at all though?
moparisthebestI don't want to waste mine or anyone else's time if not
SamWhiteddaniel: maybe. But if this can be merged into the existing thing I think it should be; and if not we should have this discussion first.
KevThere's also 'can it be an extension to the existing, rather than a replacement?'.
moparisthebestso again are changes to draft business rules allowed at all?
Ge0rGmoparisthebest: draft XEPs can be changed by Council vote.
Ge0rGThere might be conditions on that change though, like "version bump". But I don't think that's useful for business rules
moparisthebestwhat about editorial changes? like 156 references draft-ietf-xmpp-websocket instead of RFC 7395 ? can an editor merge those themselves?