Hi.
We have one outstanding issue about the TLS-Flags draft. It’s about the IANA
registry. The way the extension is defined, low identifiers for flags result in
shorter extension encoding. For this reason, we want the most popular flags to
have low numbers. This is especially true for flags that everyone will use
(think RI)
So the current text says this:
4.1. Guidance for IANA Experts
This extension allows up to 2040 flags. However, they are not all
the same, because the length of the extension is determined by the
highest set bit.
We would like to allocate the flags in such a way that the typical
extension is as short as possible. The scenario we want to guard
against is that in a few years some extension is defined that all
implementations need to support and that is assigned a high number
because all of the lower numbers have already been allocated. An
example of such an extension is the Renegotiation Indication
Extension defined in [RFC5746].
For this reason, the IANA experts should allocate the flags as
follows:
* Flags 0-7 are reserved for documents coming out of the TLS working
group with a specific request to assign a low number.
* Flags 8-31 are for standards-track documents that the experts
believe will see wide adoption among either all users of TLS or a
significant group of TLS users. For example, an extension that
will be used by all web clients or all smart objects. The only
entry in the initial registry is from this range.
* Flags 32-63 are for other documents, including experimental, that
are likely to see significant adoption.
* Flags 64-79 are not to be allocated. They are for reserved for
private use.
* Flags 80-2039 can be used for temporary allocation in experiments,
for flags that are likely to see use only in very specific
environments, for national and corporate extensions, and as
overflow, in case one of the previous categories has been
exhausted.
Quite verbose. Martin Thomson suggests a shorter version that only reserves
flags 0-7 for standards action and leaves everything else for “specification
required”. No reservation for special request. No private use reserve. No
experimental or judgment based on the likelihood of wide adoption:
https://github.com/tlswg/tls-flags/pull/14/files
<https://github.com/tlswg/tls-flags/pull/14/files>
Please comment.
Yoav
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
