[Standards] Proposed XMPP Extension: XMPP Connections across HTTPS (HACX)

Matthew Wild mwild1 at gmail.com
Fri May 4 13:08:38 UTC 2018

On 4 May 2018 at 13:55, Travis Burtrum <travis at burtrum.org> wrote:
> On 05/03/2018 11:06 AM, Sam Whited wrote:
>> On Thu, May 3, 2018, at 07:26, Jonas Wielicki wrote:
>>> URL: https://xmpp.org/extensions/inbox/hacx.html
>> This appears to have significant overlap with the HTTP mechanism from XEP-0156: Discovering Alternative XMPP Connection Methods, but I don't see any mention of it. A brief discussion about what it provides on top of that or why it's necessary to have another discovery mechanism might be useful.
> I do mention it in Security Considerations, but in a different context:
> https://xmpp.org/extensions/inbox/hacx.html#security
> I agree it should mention what you said, briefly the reason is that can
> only provide websocket/bosh, is not extendable as I read it (uses that
> oasis namespace) and so cannot support priority/weight/sni/alpn.
> Additionally, the business rules are in direct conflict with what HACX
> is trying to do.
> As a point of XEP authoring procedure, where would something like that
> fit? Use Cases?

In Requirements. I think you misinterpreted the meaning of that
section - it's typically an introduction-type section, which lays out
what the high level requirements for the protocol are, what it aims to
achieve, and why existing solutions (if any) don't meet those

I suggest changing your Requirements section to be that, and bringing
all the low-level technical requirements further down in the document.


More information about the Standards mailing list