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