11 Dec
2023
11 Dec
'23
10:54 a.m.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Host Meta 2 - One Method To Rule Them All
Abstract:
This document defines an XMPP Extension Protocol for extending
XEP-0156 by modifying the JSON Web Host Metadata Link format to
support discovering all possible XMPP connection methods, for c2s and
s2s
URL: https://xmpp.org/extensions/inbox/host-meta-2.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
15 Dec
15 Dec
9 p.m.
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
27 Dec
27 Dec
2:12 a.m.
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 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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
13 Feb
13 Feb
10:50 p.m.
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!
9:32 p.m.
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.
14 Feb
14 Feb
8:18 a.m.
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:
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
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.
312
days inactive
377
days old
5 comments
4 participants
participants (4)
-
Dave Cridland -
kevin.smith＠isode.com -
Peter Saint-Andre -
Travis Burtrum