[Standards] XMPP Council Minutes 2018-05-16

Tedd Sterr teddsterr at outlook.com
Sat May 19 02:03:05 UTC 2018


http://logs.xmpp.org/council/2018-05-16/#15:04:51

1) Roll Call - https://en.wikipedia.org/wiki/Roll_Call_(IQ_album)
Present: Dave, Daniel, Sam, Georg, Kev

2) Isn't it nice that Tedd Sterr does the minutes?
Dave's reprises his role as the inveterate fangirl, complete with squealing in frequencies only audible to nearby dogs.

3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX) - https://xmpp.org/extensions/inbox/hacx.html
Dave believes this has now been updated - Kev confirms "Version 0.0.2 (2018-05-16)" - Dave adds that the requirements also appear to have been updated.
In reference to the XEP suggesting that XEP-0156 (Discovering Alternative XMPP Connection Methods) is not flexible enough, Georg feels use of http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property could be appropriate.
Dave feels that Tor is the more appropriate tool for circumventing firewalls, censorship, etc.
Kev is perplexed how one would find the right server to send the HTTPS request to, when there's supposedly no need to trust third-party DNS.

It soon becomes clear that everyone has different interpretations of the intent of this XEP.

Kev believes it's trying to be XEP-0156 with additional payloads; Dave suggest it should be framed as extensions to 0156, if that's the case.
Daniel is unsure how it's supposed to circumvent censorship, but as long as the XEP is formally correct and not 'complete garbage', it's unnecessary at this stage to decide whether it's useful or duplicates an existing XEP. Kev thinks duplicating an existing XEP is a good reason to reject a protoXEP.
The author states he listed why it doesn't duplicate other XEPs in the requirements section, and why extending other XEPs wasn't appropriate.
If 0156 doesn't contain the information needed, as this XEP states, Kev doesn't see why that information couldn't be added. Sam agrees.
Georg demands a damn good rationale for reinventing the wheel, if it is to replace 0156.
Dave wants to vote.

Daniel: +1
Kev: -1 (for now, to investigate not reinventing 0156, but leave the door open)
Georg: -1 (don't see why this can't be an extension to 0156)
Sam: -1 (for now; thought the title implied a HTTP transport, and should decide if this is new or should be merged into 0156)
Dave: -1 (avoiding censorship is best done by Tor, etc.)

Debate with the author continues over domain-fronting support, the appropriateness of extending 0156, and incompatible business rules.
Dave would like to move on; the author agrees to resume this discussion after the meeting.

4) MIX Split
(Steve Kille and Kev have proposed to split up the mega-tome that is "XEP-0369: Mediated Information eXchange", and queried whether it would be necessary for Council to re-vote on each 'new' XEP since they have essentially already been accepted in aggregated form.)
Dave asks if anyone feels strongly on this. Sam doesn't. Georg would like to see lots of little baby-MIXes and doesn't see the need to vote on each.
Kev feels that it will be annoying to arrange voting for each part, so Council should do The Right Thing™.
Dave would prefer MIX to be split, but technical changes at the same time should be avoided, as is good practice. Georg agrees that editorial and technical changes should be kept separate.
Dave presumes unanimous assent.

Sam would prefer that the unnecessary parts of MIX be split off and then thrown away, rather than going into new documents that will be more confusing and hard to find. Georg suggests that 'unnecessary' could be removed from that statement.
Daniel already gave his OK to this on-list, but is happy to vote if necessary; Dave doesn't want to get into voting on whether to vote.

5) AOB
Dave asks whether anyone has Any Other Bollocks [sounds like a personal problem?]
Georg would like to vote on the possibility of meta-votes; Dave isn't really sure that Council should vote on whether to vote on meta-votes.
The nearby dogs are still barking.

6) Next Meeting
2018-05-23 1500 UTC mostly works, though may prove problematic for Georg; Dave lets Georg know the time can be moved to something more convenient if necessary.

7) Close
Kev thanks all.


Discussion of HACX versus extending XEP-0156 resumes...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180519/c62d883d/attachment.html>


More information about the Standards mailing list