On Tue, 12 May 2020 at 18:39, Sam Whited <[email protected]> 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: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
