Re: XMPP Spaces URIs

--===============2969413375109381914==
Content-Type: multipart/signed; boundary="nextPartLb2wAq3ARv6lWz2_rHCSag";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPartLb2wAq3ARv6lWz2_rHCSag
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Goffi <[email protected]>
To: XMPP Standards <[email protected]>
Subject: Re: [Standards] XMPP Spaces URIs
Date: Tue, 09 Jun 2026 16:10:39 +0200
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0

Hi Edhelas,

Le mardi 9 juin 2026, 14:15:30 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99Euro=
pe centrale Timoth=C3=A9e Jaussoin=20
a =C3=A9crit :
> [SNIP]
> I'm wondering if something shorter like this is possible ? (where the=20
> client is resolving the "space" parameter as the Pubsub node)
>=20
> Proposal 2: xmpp:spaces.server.tld?;space=3Dx56ae32

It's a problem that we already had, and so far I think that the consensus w=
as=20
the query the node to check its type. However I would be happy too to have=
=20
something in the URI which would avoid a round-trip. I would avoid somethin=
g=20
tied to space though, and I agree with Kev that we would need something mor=
e=20
generic. I see two ways:

=2D `type=3Durn:xmpp:spaces:0`.=20
The URI would be: `xmpp:spaces.server.tld?;node=3D123;type=3Durn:xmpp:space=
s:0`
That would work and be generic, probably the cleanest option in my opinion,=
=20
but I understand that you want something more user-friendly. Will those URI=
s=20
be exposed easily to end-user like an HTTP URL? If not, I suspect that user-
friendliness is not that important.

=2D we could use short name, something like `s=3Dspaces`.
The URI would then be: `xmpp:spaces.server.tld?;node=3D123;s=3Dspaces`
It could work in most cases and be more user friendly.

>   * to prevent non "space-ready" XMPP clients to open it as a Pubsub
>     node by mistake

Why would this be a problem? A pubsub node is generic, a client must expect=
=20
generic things, and it may be intended to inspect the node or whatever.

I'm not keen on removing the `node` query argument, but if there is a=20
consensus on that, I suspect that using it as query type would be better.

> Because this is having effect on the XMPP uris format I'm wondering if
> there's some kind of rules or specific requests to follow ?

I believe that is should go trough registrar:
https://xmpp.org/registrar/querytypes.html


Best,
Goffi
--nextPartLb2wAq3ARv6lWz2_rHCSag
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmooHt8ACgkQKqmcu6xu
KwwgvwgAskB/2fl+j+zR81z35/0rb2eDcgClZw3ShC9JVvWLeVpoffJNPVFVclPL
r82qi60upSRClosnOaut6SWp9GYgaiY64F6dDaK2CXuRAdl3RLwEUmvkuGH38GFC
j6vKiH4OqKJWP2eXzzJWLBavl58wFvU/iH8xM3Yxf7bDsEllwvkQIbYxQyPSRnOt
uDgL8sLywRbPgqYqOBWO39MeJXvhIpbN7PTi7Q57ak4DhmgFdx1ejRxixZd7BcHr
WNSjfy3zZm8O1iL0PIigMJkKbzVLFb2Lvgnud5m1JvZcvyWsFDRvx26mv1Vaa21X
NMQ4SbpupqQLFWHrZo0Fi9c6wTpU+A==
=6puq
-----END PGP SIGNATURE-----

--nextPartLb2wAq3ARv6lWz2_rHCSag--




--===============2969413375109381914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============2969413375109381914==--