On Jun 9, 2022, at 12:51 AM, Carsten Bormann < cabo@xxxxxxx> wrote:
On 2022-06-08, at 21:26, Laurence Lundblade < lgl@xxxxxxxxxxxxxxxxx> wrote:
The decoding of indefinite length strings requires a memory allocator or some strategy to coalesce string chunks. The COSE payload, which must be hashed, could be many independent string chunks. COSE header parameter values could be lots of string chunks. However you do the coalescing or processing, it is going to be more code and it is something people may not always implement. My t_cose implementation of COSE doesn’t support indefinite length strings yet.
OK, you are focusing on indefinite length encoded strings. (I couldn’t imagine why you would want to discuss indefinite length encoded arrays or maps.) Let’s simplify this term to “segmented strings”. ….
Yes, all the background and rationale for segmented strings (and indefinite length maps and arrays) makes good sense to me.
As you notice, some applications of COSE could be in a space where “streaming” (segmented processing) is natural or even the only way to do things. So it probably doesn’t make sense to disallow segmented strings for COSE in general.
Yes, COSE’s applicability is very broad, so it should not disallow segmented strings (or indefinite length maps and arrays). For example, segmented strings might even be useful in chunking blocks through AES so a large payload doesn’t have be in contiguous memory.
For EAT, you may want to make the decision that you don’t support segmented processing, alleviating the intrusion of segmentation into the decoder API.
Yes, we could do that in EAT, but should we?
My answer is no because:
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 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.
That is indeed a valid decision you may want to make. But note that this is less of an interoperability decision than a decision to simplify some parts of your systems as a tradeoff to decreased performance or capability in other parts of the system — which decrease you may want to consider insignificant. It is a bit like deciding that floating point values cannot be used in an EAT, except that this decision is not visible at the data model level.
I still see it as an interoperability problem. One person legitimately implements sending EATS with segmented strings Another person legitimately implements without being able to decode segmented strings. These two independent fully conforming implementations will fail to interoperate.
With EAT profiles, I think we’re kind of “in for a penny, in for a pound”. There are many reasons to have EAT profiles and there is strong support for them. They can’t be eliminated. So we might as well be upfront and through and cover all the potential interoperability issues.
LL
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
