[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
requirements.

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

Regards,
Matthew


More information about the Standards mailing list