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!

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