Ok, the authors will be pleased to read that this is my last note
on this particular subject.
Yes, we could do that in EAT, but should we?
My answer is no because:
I could be convinced on this particular one, but I can’t see ever getting the number of issue to zero without severely crippling EAT. For example, algorithm flexibility has to stay in IMO. Key identification and distribution is another that has to stay.1) EAT should stay aligned with COSE and CWT as much as possible.
2) Disallowing string chunks in EAT would remove one issue, but 15 more remain (section 7 has 16 subsections). It’s not enough of a gain to justify divergence from CWT.
I won't claim in any way to be EAT expert. I was asked to do an external review, and as a reviewer it would be wrong for me to dictate, “Do things my way”. You guys are the ones who are going to have to live with this work far more than I will. My last suggestions to the working group are simply these: go through each of those 16 sections and see what can be agreed/constrained. With what remains, where possible, I encourage you to enumerate options in as much detail as is practicable. That will allow for more code reuse.
Regards,
Eliot
Attachment:
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
