On Tue, Mar 7, 2017 at 4:36 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 03/02/2017 08:50 AM, Michael Paquier wrote:
>> Attached is a new patch set. I have combined SASLprep with the rest
>> and fixed some conflicts. At the same time when going through NFKC
>> this morning I have noticed that the implementation was doing the
>> canonical decomposition and reordered the characters using the
>> combining classes, but the string recomposition was still missing.
>> This is addressed in this patch set, and well as on my dev tree:
> I've now committed the bulk of these patches. Many thanks to everyone
> involved, and especially you, Michael, for your persistence!
Currently, the AuthenticationSASL protocol message specifies the mechanism
> that the client must use, but as future-proofing, it'd probably be best to
> redefine that to be a list of mechanisms, and let the client choose among
> those. That's not a show-stopper, but would be good to get that right in
> version 10, so that clients can prepare for that, even if we only support
> one mechanism ATM.
+1, and let's make sure we get it into 10. We don't want to be stuck with
something without flexibility -- then we're going to have to do the whole
"is it time yet" dance again. It would be especially bad since the
underlying protocol is pluggable.
This seems like an obvious place, but are there any other places where we
should also consider something like that for compatibility?