[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Dave Cridland dave at cridland.net
Tue May 19 15:11:49 UTC 2020


On Sun, 10 May 2020 at 14:43, Sam Whited <sam at samwhited.com> wrote:

> > I'd be fine with putting channel bindings alongside mechanisms, just
> > not pretending they are mechanisms.
>
> I still don't see why it bothers anyone. We already do this with "-
> PLUS", so what is wrong with adding another suffix? So far it's just "I
> don't like it" and "I'm not fine with it". I can't really do much to fix
> it if I don't know why.


Sorry, I missed this earlier.

"-PLUS" is a suffix, yes, but it is not a pseudo-mechanism - you can (and
should, indeed) use this as the mechanism name in the authenticate command.

Note that I say "authenticate command" intentionally - while RFC 6120 uses
an <auth/> element, RFC 3501 uses an AUTHENTICATE command, and an IMAP
client doesn't care a hoot if the mechanisms listed include ones with a
"-PLUS" suffix or not - that is handled by the SASL layer entirely.

What you're asking for is that the mechanisms list no longer contains just
mechanisms, and the list actually needs preprocessing by an XMPP client
before use by a generic SASL library.

Not only that, but your "pseudo-mechanisms" are not valid mechanism names,
unlike "-PLUS" - mechanism names aren't random strings, they have a fixed
syntax given by RFC 4222:

https://tools.ietf.org/html/rfc4422#section-3.1

(Note: no colons, and 20 characters max).

So in summary, you're stuffing data that has the wrong syntax, and the
wrong semantics, into a well-defined slot.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200519/fe5ec558/attachment.html>


More information about the Standards mailing list