WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hello Laurence, others,
On 2022-06-10 04:57, Laurence Lundblade wrote:
>
>> On Jun 9, 2022, at 12:30 PM, Carsten Bormann <cabo@xxxxxxx> wrote:
>>
>> On 2022-06-09, at 21:17, Laurence Lundblade <lgl@xxxxxxxxxxxxxxxxx> wrote:
>>>
>>> One person legitimately implements sending EATS with segmented strings Another person legitimately implements without being able to decode segmented strings.
>>
>> Well, an implementation that doesn’t handle segmented strings may be “legitimate”, but it won’t be a complete implementation (and thus not interoperable) if you decide EAT to make no restrictions on generating segmented strings.
>
> Maybe use the term “fully conforming” rather than “legitimate” or “complete” where "fully conforming" means adherence to what is in the specification and its normative references and no more. No tacit assumptions about the way typical libraries behave or
their level of completeness are required to guarantee interoperability.
"fully conforming" doesn't sound right to me. I'd expect everybody to
expect that two fully conforming implementations would be guaranteed to
interoperate.
What about "minimally conforming"? "Two minimally conforming
implementations are not guaranteed to interoperate." sounds much more
reasonable than "Two fully conforming implementations are not guaranteed
to interoperate."
[JOD] As far as I can tell from the specification, for a “fully conforming” CBOR implementation:
- Indefinite length maps and arrays consisting of up to 2^64 entries must be supported (and note that, as far as I can tell, there is nothing preventing every entry in an array from
being a definitely encoded string of length 2^64)
- There appears to be no limit at all to the length of indefinite encoded strings.
There may exist hardware platforms wishing to support EAT which cannot fully support those requirements. In fact, I suggest that there likely exists NO fully conforming CBOR implementation based on the above limits (and others in the specification).
Add the need to layer COSE over the CBOR and I am even more certain that the concept of “fully conforming” doesn’t really exist – at least in the absence of a normative compliance test suite that defines appropriate limits for CBOR and COSE.
Statements along the lines of “an entity capable of receiving <thing> MUST support a payload of at least <number> bytes” are commonplace. Perhaps profiles are the right place for additional restrictions, but it seems reasonable to at least
discuss implementation considerations in the main text.
Since the CBOR specification also says “some applications and protocols will not want to use indefinite-length encoding”, I’d like to understand if there even exists a reasonable case
for an EAT which requires indefinite length encoding. If there is not, I would be minded to explicitly exclude indefinite length items from EAT. This would address the “one person legitimately implements EATs with segmented strings” problem. I accept that
this potentially deviates from “EAT is a CWT” as CWT doesn’t exclude indefinite length encoding.
Regards
Jeremy
Regards, Martin.
> I kind of expected the IETF to harass me if fully conforming implementations of something I wrote aren’t 100% guaranteed interoperable. That during review all the nooks and crannies where there might be interoperability issues would be ferreted out.
>
> LL
