On Fri, Mar 22, 2024 at 9:46 AM Florian Schmaus wrote:
> - § 7. says 'None' whereas this XEP introduces a new namespace
> 'urn:xmpp:sasl:2' which should be registered in the registrars namespace
> registry (Yes I know that the XSF registrar is not in a good shape, but
> still).
Thanks. I've
On 18/03/2024 09.59, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on
XEP-0388.
Title: Extensible SASL Profile
Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
URL:
> This message constitutes notice of a Last Call for comments on
> XEP-0388.
>
> Title: Extensible SASL Profile
> Abstract:
> This document describes a replacement for the SASL profile documented
> in RFC 6120 which allows for greater extensibility.
>
> URL:
> Yes, I have implemented this for xmpp.js -- except for "tasks" which I have
> not implemented and I think there are no official profiles of, making that a
> somewhat more risky area of the spec.
There is a task defined in XEP-0480 (for upgrading server-stored SCRAM hashes,
for example from
On Mon, 18 Mar 2024, 17:32 Stephen Paul Weber,
wrote:
> >> However it does lack any way to support indicating to the server
> >> which
> >> credential will be used, other than perhaps by implication from the SASL
> >> mechanism.
> >>
> >>
> >That's not the purview of a SASL profile. If a SASL
However it does lack any way to support indicating to the server
which
credential will be used, other than perhaps by implication from the SASL
mechanism.
That's not the purview of a SASL profile. If a SASL mechanism supports
multiple credentials, that's entirely encapsulated within that
On Mon, 18 Mar 2024 at 14:19, Stephen Paul Weber
wrote:
> >1. Is this specification needed to fill gaps in the XMPP protocol
> >stack or to clarify an existing protocol?
>
> Yes, we currently have no way to use multiple SASL or otherwise to acheive
> a
> similar result.
>
> >2. Does the
On Mon, 18 Mar 2024 at 09:00, Daniel Gultsch wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0388.
>
> Title: Extensible SASL Profile
> Abstract:
> This document describes a replacement for the SASL profile documented
> in RFC 6120 which allows for greater
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes, we currently have no way to use multiple SASL or otherwise to acheive a
similar result.
2. Does the specification solve the problem stated in the introduction
and requirements?
