<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">

<html lang="en">

<head>

<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">

<title>

GitLab

</title>

<style>img {

max-width: 100%; height: auto;

}

</style>

</head>

<body>

<div class="content">

<p style="color: #777777;">

<a href="https://gitlab.com/nmav">Nikos Mavrogiannopoulos</a>

commented:

</p>

<div style="">

<p dir="auto">Thank you for starting this discussion. Let me try to put my perspective. I think that we should answer how we treat non-standardized protocols in text as policy (e.g., in CONTRIBUTION guide) before we finalize a technical solution. Few examples of how we handled it in the past from the top of my head:</p>

<ol dir="auto">

<li>We have introduced ietf draft-28 from TLS 1.3 even before they were standardized but disabled by default (new APIs were defined)</li>

<li>Introduced <a href="https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/" rel="nofollow noreferrer noopener" target="_blank">GOST ciphersuites</a> even on a non-final draft, but they are disabled by default. New functionality was defined - e.g., ciphers, but compatibility was broken when a cipher had a wrong s-box assigned.</li>

<li>Introduced Ed25519 signing in certificates and TLS KX from draft-ietf-tls-rfc4492bis-17.</li>

</ol>

<p dir="auto">In all of these cases I believe the code was included when we had reasonable expectation that no significant changes are to be done in the standards.</p>

<p dir="auto">So if the proposal is to go beyond that, let's set the bar with amending our guide, or if the proposal is for no bar, let's define the expectations from that functionality and then we finalize the API to protect from such changes.</p>

<p dir="auto">Said that, even if decide to go for including ongoing features my concern is that even if we provide a technical solution to make certain APIs/ABIs look temporary applications that use them may expect them to continue working anyway on an ABI compatible upgrade (though I'd really like to hear more from potential consumers of such experimental features).</p>

</div>

</div>

<div class="footer" style="margin-top: 10px;">

<p style="font-size: small; color: #777;">

—

<br>

Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_296523593">view it on GitLab</a>.

<br>

You're receiving this email because of your account on gitlab.com.

If you'd like to receive fewer emails, you can

<a href="https://gitlab.com/sent_notifications/6ee694e3893b80452c94d42c502b3fbe/unsubscribe">unsubscribe</a>

from this thread or

adjust your notification settings.

<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Merge request","url":"https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_296523593"}}</script>

</p>

</div>

</body>

</html>