Proposal for Profile ID Registry #87
Conversation
|
|
||
| | ID value | Template | Note | | ||
| |:=========:|:==================:|:=============:| | ||
| | `[0x00]` | `{"version": 772}` | cTLS 1.3-only | |
There was a problem hiding this comment.
This change deletes the template, so there's no longer anything that explains the meaning of ID [0x00].
Is there a reason not to include the full template in the registry? Adding a layer of indirection is confusing to me, especially for FCFS registrations (length > 2). Under this policy, these registrations could have a Reference that points to any "document", leading to interoperability challenges if that document changes or disappears.
There was a problem hiding this comment.
The profile id does more than just indicating a version number. Hence, a reader will always have to look at the specification that defines what the template does. Hence, I believe it is fine to have a reference to the spec included for the profile id.
If there is the worry that the referenced specification "disappears" then we should add that we want a stable reference there.
There was a problem hiding this comment.
The profile id does more than just indicating a version number. Hence, a reader will always have to look at the specification that defines what the template does.
The "Template" field in the current version provides the exact, entire template indicated by this profile ID. (It just so happens that profile ID zero corresponds to a template that uses default settings for everything except the TLS version.) An implementor does not need to read the reference; they just need to copy+paste the registry into their source code.
I think this is a good arrangement, especially if we don't expect many registrations of very large templates. (Registrations containing certificates would be ugly, but it's not clear why anyone would want to do that.)
However, even if we decide to leave the template out of the registry, I maintain that this change doesn't work, because the template corresponding to ID zero is not specified in this document.
There was a problem hiding this comment.
Added text to the draft to get this point accross: "profile ID zero corresponds to a template that uses default settings for everything except the TLS version."
There was a problem hiding this comment.
I'm fine with expanding "Note" to "Description" and adding Change Controller and Reference, but I don't understand why we shouldn't include the template. Registered IDs are exactly equivalent to a specific template, which is easily represented here in JSON. Without it, we are asking implementors to go read the reference and look for the template, so they can copy-paste it from there. I think this would result in far less interoperability for registered IDs. (Servers can only use registered IDs if they know that 100% of their client pool supports that ID, so easy implementation of new IDs is very important for them to be useful.)
In fact, an implementor using that strategy would fail here, because the 0x00 template is not provided anywhere in this document. The implementor has to find the description in the text and interpret it to mean {"version": 772}.
Additionally, I have some concerns about the "name" column. This column seems to be intended for use as some kind of unique identifier, but its format (e.g., allowed characters) is not defined.
|
|
||
| The ID values of length 1 are subject to a "RFC Required" registry | ||
| policy. Values of length 2 are subject to an "Specification Required" policy. | ||
| Values of length 3 and 4 are subject to a "Private Use" policy. |
There was a problem hiding this comment.
I don't understand the utility of a "private use" range here. All IDs longer than 4 bytes are already basically "private use". It would seem more sensible to me to shorten Value to 1-2 octets, or possibly to mark lengths 3 and 4 as Reserved.
|
Let's discuss this PR at the next IETF meeting rather than merging it right now. It looks like we are not settled on the design yet. |
No description provided.