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. > 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. 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. > I would absolutely encourage KITTEN people to review it, though, and > the only thing stopping me raising it there now is that I'm assuming > Sam will. I hadn't actually thought about that, but will do. I've got enough threads open there to pester people with, so I'll wait until we've discussed a little further internally first and I've been convinced one way or another WRT the approach. —Sam -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
