> On Jul 26, 2017, at 03:08, Kazu Yamamoto (山本和彦) 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 `
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
On Jul 25, 2017, at 01:29, Kazu Yamamoto (山本和彦) wrote:
>> 3. Change the definition of `select`'s `case` statements to have 0 or more
>> fields (types and names) and remove the optional label.
>> 4. Change the `select` example to match the new definition.
>
> I agree if this means 1 or more. (S
Hi Stephen,
Thank you for your nice work.
> Concretely, I think we should make the following changes.
> 1. Replace `length` with `TLSCiphertext.length` in the definition of
> `TLSCiphertext`.
I agree.
> 2. Replace `Hash.length` with `hash_length` throughout (9 instances).
I agree.
> 3. Chang
For the most part, the presentation language (somewhat informally) described in
section 3 and its use throughout the document is clear, but the use doesn't
always match the description and some things are written in different ways. I
have a few examples below of the issues I've noticed. After th
