On Wed May 6, 2020 at 8:19 PM CEST, Sam Whited wrote: > On Wed, May 6, 2020, at 18:03, Dave Cridland wrote: > > The TL;DR is "horrible syntax, but really useful idea". … So, I would > > love to see this problem tackled properly, but without a syntax that > > involves me wanting to stab myself in the eyes with a fork. > > Daniel said something similar but I don't understand what either of you > don't like about it? It's such a small thing it can hardly even be > described as syntax since you'd likely hard code mechanism names that > you implement.
Overloading of already defined fields is weird. > > I wonder if just listing channel bindings, and mandating that channel > > bindings are offered for all mechanisms that support them equally, > > might be better. > > How would you list them? If it's another stream feature, it would have > to be special cased that it's not something to be negotiated, but > somehow has to have its state be saved and understandable from whatever > parses the <mechanisms/> feature. This would break a lot of assumptions > I made when implementing stream negotiation that I think were reasonable > assumptions from reading 6120. If it is negotiated, see my response to > Daniel. I just don't really know what that would mean and it adds a lot > of complexity. I note that there's prior art for advertising extra SASL data in https://xmpp.org/extensions/xep-0233.html I don't do a lot of client work but I don't think having the data as simling to <mechanisms> is a problem for the Verse client library, as each stream feature handler act on the whole <stream:features> element. > Also, as I said in my other email: I don't think you can mandate that > channel bindings are offered equally for all mechanisms. Right now we > just have SCRAM, but in the future we may also have OAuth or something > that uses channel binding. It may not have all the same channel binding > methods defined for it. Of course, this risk may be minimal enough that > we don't care. As I understand it, channel bindings are defined by GSS-API which in turn can be used by other SASL mechanisms, so unless someone invents a new class of non-GSS-API channel bindings then assuming that all advertised channel bindings work with all channel binging-capable mechanisms seems fine to me. -- Kim "Zash" Alvefur _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
