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 <travis(a)burtrum.org> wrote:

Hi Dave! On 12/27/23 04:12, Dave Cridland wrote: 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 :)) 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. 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? 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. 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. Thanks much for the review!