> On Jul 26, 2017, at 03:08, Kazu Yamamoto (山本和彦) <k...@iij.ad.jp> wrote:
>
> Hi Stephen,
>
>> Initially, I thought proposal I would be the best, but now I have a
>> mild preference for proposal III. I think it makes the language
>> simpler over all. It essentially becomes two primitive types
>> (`opaque` and `uint8`) and four type definitions:
>
>
> I like III, too. But I don't want to keep unused labels such as
> 'server_share'. So, I like the following definition.
>
> struct {
> KeyShareEntry client_shares<0..2^16-1>;
> } ClientKeyShares;
>
> struct {
> select (Handshake.msg_type) {
> case client_hello: ClientKeyShares;
> case hello_retry_request: NamedGroup;
> case server_hello: KeyShareEntry;
> };
> } KeyShare;
That would be fine too, but `server_share` really is described in the text and
there's no good way to discuss it without having a field name.
>
>> Neither the current presentation language nor my proposed one above
>> gives meaning to `uint16 ProtocolVersion;`. Absent a compelling
>> reason for type aliases, I think this should be written as `uint8
>> ProtocolVersion[2];`
>
> If I remember correctly, ProtocolVersion is defined:
>
> struct {
> uint8 major;
> uint8 minor;
> } ProtocolVersion;
>
> And its value is described as { 3, 1 }.
I believe that's how it was defined in previous versions. Now it's defined (see
B.3.1) as
uint16 ProtocolVersion;
But this notation (a type alias/typedef) isn't defined in the presentation
language and isn't, to the best of my knowledge, used anywhere else.
--
Stephen Checkoway
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
