[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All
On 2/13/24 9:32 PM, Travis Burtrum wrote: Apologies for the delay on this, but I finally have an update: On 12/15/23 23:00, Travis Burtrum wrote: Lastly I was asked to contact to XEP-0156 authors to see how they'd feel about this updating '156 instead of being it's own XEP I emailed stpeter directly and he responded promptly, thanks for that! He asked me to convey his message and he'd respond with a +1 so I'm doing so here: On 2/7/24 21:05, Peter Saint-Andre wrote: > On 2/7/24 6:56 PM, Peter Saint-Andre wrote: >> Hi Travis! >> >> On 2/7/24 5:37 PM, Travis Burtrum wrote: >>> The council is blocking this pending an answer from '156 authors >>> (which I think, of the people still around, is only you) as to >>> whether you think this fits best as a new XEP or whether you'd be ok >>> with this being an update to and mostly replacing '156? >> >> I thought I had replied in xsf@ at one point, but it might have been >> lost in the noise. >> >> I'm A-OK with hostmeta-2 but I think it should be in a new XEP that >> obsoletes 156, not an overwrite of the existing 156. So I have created a PR (https://github.com/xsf/xeps/pull/1323) with feedback and rationale, will respond shortly to the 2 responses to my previous message (again, thank you, and apologies for delay) and would like to ask council to re-consider this as a new XEP given the response from stpeter. To be clear, I think this is enough of a diff that a different spec is the best way to go. But I'm removed enough from what's happening here that I would not consider my opinion to be a blocker. Peter ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All
Hi Dave!
On 12/27/23 04:12, Dave Cridland wrote:
I dislike this XEP intensely.
But... I think it's probably the most pragmatic solution that fits the
existing standards space.
Honestly... Nice summary of my opinion too. :) We need things, sadly we
don't live in an ideal world, and this seems like the least bad way to
get everything we need in the world in which we live. (without
precluding improving it of course! And of course improving XMPP
connectivity will do this in it's own way :))
Questions:
- Should we require this to always be hosted at the exact domain? Pretty
much everywhere I've worked for has the primary website (AKA "the
marketing site") distinct from any production services, whether internal
("IT") or external ("Engineering") facing. Is it worth having a dummy
website on a different domain that we can check, and stipulate that if
both exist, they MUST be both identical? (Or we can set a priority, but
my intent here is that both would be checked simultaneously).
No, that's what HTTP 301/302 redirects are for, I would have swore I
mentioned these in the XEP but indeed I did not... Roughly it should say
follow a sane number of redirects (10?), forbidding looping, and require
that each hop is https (never http) or abort.
- While I sympathize with the view that StartTLS for C2S and indeed S2S
should be moving towards deprecation, that flies in the face of the
pragmatism otherwise on display here - they need to be added in I think
as rel types.
My thought is roughly that anything that implements this will at minimum
implement DirectTLS. It can still advertise StartTLS ports via SRV for
things that don't implement this, so everything, legacy and host-meta-2,
still works seamlessly. I'm not absolutely opposed StartTLS rel types
mind you, but wanted to explain my reasoning, is there still a reason to
support them here?
- The TTL thing... I agree it's an error in RFC 6415 et al, but I'm
unconvinced it's one we should worry ourselves over too much within the
XSF. I'd save yourself the effort and assume developers are sensible.
I assume you mean the TTL instead of Expires? I think this should be an
absolute requirement, as the other would essentially require this file
be dynamically generated which I think should be avoided.
- In general, I'm not sure that the JRD/XRD model allows that "xmpp"
block; those might need to be distinct properties.
- In general, I understand the JRD/XRD concept to be tightly bound to
RDF, so I think you'd need to add in attributes as properties, and those
properties would need to be URIs.
Many of the above will make things uglier, but I think more in-line with
the JRD concepts.
Finally, I think it's worth putting some consideration into handling
this one in the IETF entirely - you may find support for extracting the
PKP bits into a generic approach, and all sorts.
As an alternative to all that, it might be sensible to explore *not*
using host-meta, and instead using a well-known JSON blob (I see Matrix
does this for example).
Re-using and extending host-meta.json is essentially a
trick(/optimization/hack) to avoid an additional https request when
grabbing details both the old way and the host-meta-2 way. It's *nice*,
but not *absolutely required*, so I think if we can without breaking
anything we should, but if there's a risk, we can eat the extra https
request and roll our own format.
That said, I seriously doubt anyone consuming the json is validating it
in any way, JRD pre-dates actual efforts to validate json like
json-schema by nearly a decade. I think JRD is defined only
https://datatracker.ietf.org/doc/html/rfc6415#appendix-A , and
explicitly says "The conversion of any other element is left
undefined.", which I interpret to mean adding the 'xmpp' block and
anything else is fine, clients that adhere to this will ignore it.
"ignoring unknown fields" is also how every JSON parser I've seen in the
wild works by default.
re: IETF, not opposed, but would prefer to prove it (one way or the
other) as a XEP first.
Dave.
Thanks much for the review!
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All
Hi Fannys! On 12/16/23 04:06, Fannys wrote: As I said in the @xsf room the problem with this XEP is that the author is convinced that this is the one answer to everything and assumes a *lot* of stuff to get there. And besides the title obviously that is obvious in a few other places. To try to quickly summarize, we need a lot of info to connect to XMPP servers, and need to get it in very specific (secure) ways. I've thought about this a lot over the years, and (very much thanks to your and other's feedback) tried to explain the reason for every decision. I am absolutely not married to one solution, but alternatives need to accomplish the same goals. "I don't like this" isn't helpful without an alternative proposal that can actually be considered. Specifically: - It calls SRV records as legacy which is a pretty big departure from the status quo. > For the foreseeable future you will need to maintain legacy SRV records in addition to this file Yes, because this document explicitly deprecates SRV records (while saying they need to be supported for the forseeable future). - It effectively makes HTTP a hard requirement for all clients and servers on the network raising complexity significantly. HTTPS already is a hard requirement, with POSH, with HTTP Upload which is currently the only way to share files in MUCs and with multiple clients / offline clients, and, for most servers, the way they get certificates from letsencrypt. HTTPS is also a well established, fully open protocol with many independent implementations exactly like XMPP, I see no reason to avoid it. XMPP relies on many other standards, just as good or bad (depending on your POV), like DNS, IP, TCP, TLS, XML etc etc. - Recommends that everything runs through port 443 which is in itself questionable for this. Because it's most likely to work through real-world firewalls in real-world networks, what's questionable about this? - Also it introduces a hard requirement for a JSON parser in all clients and servers which is another point that raises complexity. Again, a JSON parser is already a hard requirement due to POSH. I addressed further reasons I thought this was the best choice in the Rationale https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-hm-json , but, this is not an absolute hill for me to die on. If the consensus is that XML is better here, I'm not opposed, but then it should be the XMPP-subset of XML so that we can actually use the same parser, and don't introduce the real security risk of requiring an XML parser that can parse not-XMPP-XML (just one real world example of this vulnerability in the wild is https://prosody.im/security/advisory_20220113/ ). Please note this would introduce the following (imho, downsides): 1. we could not use host-meta.xml as that requires a not-XMPP-subset-XML parser supporting comments etc etc 2. that means an extra https request when trying to fetch host-meta-2 along with legacy methods 3. so it'd require a new document definition, for a quick reference, it would look very similar to HACX https://xmpp.org/extensions/inbox/hacx.html#example-1 And I think the discussion about these items individually should have happened before. Especially since from the discussion in @xsf it seems that some of the alternatives like DNS were rejected on subjective opinions of the author. I actually discussed this in xsf@ 21 months (damn I'm slow...) before submitting this ProtoXEP https://logs.xmpp.org/xsf/2022-03-17#2022-03-17-ead56d61d395a6b9 I hopefully explained my rationale re: DNS well https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-dns but please if you disagree and/or have alternatives do share. My opinion is that HTTP and JSON shouldn't be requirements and i don't plan to use this XEP anywhere even if it gets voted in. We already have problems with ports and everything assuming HTTP and I don't want the problem to be worse. Plus I don't want the complexity at all. So to summarize my current thoughts: * I think HTTPS is likely to be a hard requirement for this, at least I can't think of an alternative that can accomplish the same goals * JSON is *not* a hard requirement, and could be replaced, but has the downsides I layed out above and in the rationale Fannys I very much appreciate the detailed feedback, thank you! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All
Apologies for the delay on this, but I finally have an update: On 12/15/23 23:00, Travis Burtrum wrote: Lastly I was asked to contact to XEP-0156 authors to see how they'd feel about this updating '156 instead of being it's own XEP I emailed stpeter directly and he responded promptly, thanks for that! He asked me to convey his message and he'd respond with a +1 so I'm doing so here: On 2/7/24 21:05, Peter Saint-Andre wrote: > On 2/7/24 6:56 PM, Peter Saint-Andre wrote: >> Hi Travis! >> >> On 2/7/24 5:37 PM, Travis Burtrum wrote: >>> The council is blocking this pending an answer from '156 authors >>> (which I think, of the people still around, is only you) as to >>> whether you think this fits best as a new XEP or whether you'd be ok >>> with this being an update to and mostly replacing '156? >> >> I thought I had replied in xsf@ at one point, but it might have been >> lost in the noise. >> >> I'm A-OK with hostmeta-2 but I think it should be in a new XEP that >> obsoletes 156, not an overwrite of the existing 156. So I have created a PR (https://github.com/xsf/xeps/pull/1323) with feedback and rationale, will respond shortly to the 2 responses to my previous message (again, thank you, and apologies for delay) and would like to ask council to re-consider this as a new XEP given the response from stpeter. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All
Hi all,
(Updated Lance's email to the last-known-good public one).
I dislike this XEP intensely.
But... I think it's probably the most pragmatic solution that fits the
existing standards space.
Questions:
- Should we require this to always be hosted at the exact domain? Pretty
much everywhere I've worked for has the primary website (AKA "the marketing
site") distinct from any production services, whether internal ("IT") or
external ("Engineering") facing. Is it worth having a dummy website on a
different domain that we can check, and stipulate that if both exist, they
MUST be both identical? (Or we can set a priority, but my intent here is
that both would be checked simultaneously).
- While I sympathize with the view that StartTLS for C2S and indeed S2S
should be moving towards deprecation, that flies in the face of the
pragmatism otherwise on display here - they need to be added in I think as
rel types.
- The TTL thing... I agree it's an error in RFC 6415 et al, but I'm
unconvinced it's one we should worry ourselves over too much within the
XSF. I'd save yourself the effort and assume developers are sensible.
- In general, I'm not sure that the JRD/XRD model allows that "xmpp" block;
those might need to be distinct properties.
- In general, I understand the JRD/XRD concept to be tightly bound to RDF,
so I think you'd need to add in attributes as properties, and those
properties would need to be URIs.
Many of the above will make things uglier, but I think more in-line with
the JRD concepts.
Finally, I think it's worth putting some consideration into handling this
one in the IETF entirely - you may find support for extracting the PKP bits
into a generic approach, and all sorts.
As an alternative to all that, it might be sensible to explore *not* using
host-meta, and instead using a well-known JSON blob (I see Matrix does this
for example).
Dave.
On Sat, 16 Dec 2023 at 04:01, Travis Burtrum wrote:
> Hi all,
>
> Quick summary of this ProtoXEP: It's intended to be the single new
> de-facto way all servers and clients look up connection info to connect
> to servers.
>
> It was clear from the feedback that this ProtoXEP needed an extensive
> rationale section explaining why other alternatives aren't sufficient
> and why certain decisions were made, I have added this and rendered it
> here:
>
> https://www.moparisthebest.com/xeps/host-meta-2.html#rationale
>
> (source @
> https://github.com/moparisthebest/xeps/tree/task/host-meta-2-rationale )
>
> I'd appreciate any feedback, here or in xsf@ .
>
> Lastly I was asked to contact to XEP-0156 authors to see how they'd feel
> about this updating '156 instead of being it's own XEP, so I've CC'd the
> authors who's emails appear to still be valid here, if you could please
> have a look and let us know I'd really appreciate that too. :)
>
> Thanks much,
> Travis
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All
Hi all, Quick summary of this ProtoXEP: It's intended to be the single new de-facto way all servers and clients look up connection info to connect to servers. It was clear from the feedback that this ProtoXEP needed an extensive rationale section explaining why other alternatives aren't sufficient and why certain decisions were made, I have added this and rendered it here: https://www.moparisthebest.com/xeps/host-meta-2.html#rationale (source @ https://github.com/moparisthebest/xeps/tree/task/host-meta-2-rationale ) I'd appreciate any feedback, here or in xsf@ . Lastly I was asked to contact to XEP-0156 authors to see how they'd feel about this updating '156 instead of being it's own XEP, so I've CC'd the authors who's emails appear to still be valid here, if you could please have a look and let us know I'd really appreciate that too. :) Thanks much, Travis ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
