> On Aug 10, 2020, at 5:49 PM, Jim Schaad <i...@augustcellars.com> wrote:
>
> This is all based on my understanding that the surrounding protocol for must
> specify exactly when CBOR tags are to be used and when they are not to be
> used and that the surrounding protocol must not leave it as an optional
> implementation choice. In this case application/cwt is the supporting
> protocol.
>
> [JLS] What is the text that says that this is true. This would be a
> surprising statement for me.
Here’s three things that lead me to this.
CBORbis
The sentence of the first paragraph in 4.2.2
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14#section-4.2.2> very
clearly states this, though this is only for deterministic encoding.
Typical CDDL
Most CDDL that describes tagged data describes it only as tagged or untagged,
not as optionally tagged. COSE is one example of this.
Email threads
This thread
<https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=Hz7VjeBab9DxPas9E5_KfOmZwN0>
and this thread
<https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=y1EZ-IylFpJ3_MndQGADSbKhx0s>.
I summarized this behavior in this email
<https://mailarchive.ietf.org/arch/msg/cbor/Hz7VjeBab9DxPas9E5_KfOmZwN0/> and
no where in the rest of the thread was it indicated differently.
So, it is not a hard requirement because 4.2.2 is only for deterministic
encoding, but seems like a “should" in spirit. It is the preferred way to
design a CBOR protocol.
However you slice it, I think it is up to the surrounding protocol to say
whether a tag is always required, never required or optionally required. If the
protocol doesn’t say, then it defaults to optionally required.
Defaulting or explicitly allowing optional tagging means the receiver has to
allow for all the tagging scenarios and makes possible the error case where the
surrounding protocol says the data is of one type and the tag conflicts with
it. (e.g. an application/cwt that contains a tagged CoSWID).
I don’t think optional tagging is of any advantage in a protocol design. It
doesn’t enable anything.
It has some disadvantage because it introduces error conditions and potential
confusion.
I think there are several scenarios with section 6 and application/cwt that
could be more clear.
Can you use tag 61 or not? I think the current answer is that in
application/cwt, tag 61 is optional.
How do you know what the COSE type is? It is somewhat obvious that COSE tags
will work, but there is no requirement to use them. A MIME parameter or other
is entirely allowed here.
Section 6 does say that determination that something is a CWT is application
dependent, but doesn’t say that the COSE type is also application dependent.
Section 7 does address this.
Said another way, my fully general CWT decoder that is called by some
application needs an input parameter to indicate the COSE type because there is
no requirement in 8392 that a CWT indicate which COSE type is in use. Sometimes
the caller will be able to provide the COSE type and sometimes they won’t.
Sometimes there will be an error of conflicting COSE type and sometimes the
error will be that the COSE type can’t be determined.
I think it would have been cleanest if CWT always indicated the COSE type be
used and the tagging optionality didn’t span two protocol layers, but that
would be an incompatible change. Maybe a recommendation that CWT’s SHOULD
always indicate their COSE type?
LL
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
