[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Dave Cridland dave at cridland.net
Tue May 19 14:59:43 UTC 2020


On Tue, 12 May 2020 at 18:39, Sam Whited <sam at samwhited.com> wrote:

> No one has indicated why they think this is a bad thing yet.


They are not mechanisms, but pretend to be, thus breaking the semantics of
what that element is intended to contain.


> It seems
> fine to me. As I said, these mechanisms aren't full mechanisms designed
> for use outside of XMPP.


"Seems fine to me" is insufficient as an argument; you're aiming to break
with convention here so it's up to you to provide the argument in favour of
doing so.


> They are also dependent on the values in the
> mechanisms registry, therefore they cannot and should not be in the
> mechanisms registry themselves or we'd have a weird recursive list of
> mechanisms.
>

I believe you're saying here that it's essential for every mechanism to
support a different array of channel bindings.

I do not think this is the case - the channel binding support comes from
GS2 in terms of layers, and in general should be part of the SASL library,
not the mechanism code itself. An implementation which supports different
channel bindings for different mechanisms suggests some poor design, and I
see no reason to support this, let alone optimize for such behaviour.

(As I've said before, though, I'd rather get this on experimental and fix
it there).


>
> —Sam
>
> On Tue, May 12, 2020, at 13:16, Jonas Schäfer wrote:
> > -1 as is, because it puts non-standard information in the SASL
> > mechanism name, which does have a proper registry at the IANA [1] for
> > no good reason.
>
> --
> Sam Whited
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200519/f262965d/attachment.html>


More information about the Standards mailing list