On Sat, May 26, 2018 at 11:42:38PM +0900, Michael Paquier wrote:
> On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
>> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
>>>
>>> OK, I can live with that as well. So we'll go in the direction of two
>>> parameters then:
>>> - scram_channel_binding, which can use "prefer" (default), "require" or
>>> "disable".
>>> - scram_channel_binding_name, developer option to choose the type of
>>> channel binding, with "tls-unique" (default) and "tls-server-end-point".
>>> We could also remove the prefix "scram_". Ideas of names are welcome.
>>
>> scram_channel_binding_method?
>
> Or scram_channel_binding_type. The first sentence of RFC 5929 uses this
> term.
I just went with scram_channel_binding_mode (require, disable and
prefer) and scram_channel_binding_type as parameter names, in the shape
of the attached patch.
>> Do we really know someone is going to want to actually specify the
>> channel binding type? If it is only testing, maybe we don't need to
>> document this parameter.
>
> Keeping everything documented is useful as well for new developers, as
> they need to guess less from the code. So I would prefer seeing both
> connection parameters documented, and mentioning directly in the docs if
> a parameter is for developers or not.
So done this way. Feel free to pick me up at PGcon this week if you
wish to discuss this issue. Docs, tests and a commit message are
added.
--
Michael
