| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | "* Neustradamus *" <neustradamus(at)hotmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "alexey(dot)melnikov(at)isode(dot)com" <alexey(dot)melnikov(at)isode(dot)com>, Nico Williams <nico(at)cryptonector(dot)com> |
| Subject: | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
| Date: | 2025-11-21 16:38:37 |
| Message-ID: | CAOYmi+nq2ryqYbKGTLcYZOWbm0zbWfRi++Ue3QApo1GvS7p2kQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 21, 2025 at 12:49 AM * Neustradamus *
<neustradamus(at)hotmail(dot)com> wrote:
> At the same time, about these XEPs, it is the base of the "draft-melnikov-sasl2" done by Alexey Melnikov (author of several RFCs):
> - https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2
Right, but even that draft says
All of the features below are optional (in order to remain backward
compatible with RFC 4422). However if any is implemented, all of
them MUST be implemented in a protocol. This makes client
implementations easier.
So even if we were to charge ahead and assume that the XEP
implementation is exactly what's going to be standardized in a future
version of SASL, we're still introducing interoperability pain if we
don't do other currently-experimental things too.
In the past, we've said that we're going to wait for published RFCs,
and I think that's served us well. We just need to keep an eye on what
the Kitten WG is up to.
That doesn't stop anyone from maintaining a patchset that tracks the
state of the drafts, though. It's only a barrier to getting it
committed and released.
Thanks,
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | feichanghong | 2025-11-21 16:54:10 | Optimize cardinality estimation when unique keys are fully covered |
| Previous Message | 河田達也 | 2025-11-21 16:25:58 | Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE |