Multiple "ct" link attributes in a link

[ektrah]

Errata ID: 5078 Type: Technical Reported By: Jim Schaad Date Reported: 2017-08-07

Section 7.2.1 says/should say:

 The Content-Format code
 attribute MAY include a space-separated sequence of Content-Format
-codes, indicating that multiple content-formats are available.  The
-syntax of the attribute value is summarized in the production "ct-
-value" in Figure 12, where "cardinal", "SP", and "DQUOTE" are defined
-as in [RFC6690].
+codes, indicating that multiple content-formats are available.
+The Content-Format code attribute MUST NOT appear more than once in a
+link.  The syntax of the attribute value is summarized in the
+production "ct-value" in Figure 12, where "cardinal", "SP", and
+"DQUOTE" are defined as in [RFC6690].

Insert a sentence that says that the code MUST NOT appear more than once. This appears to be what was intended, but not stated, by the authors since it supports the space separated values to appear in a single attribute value.

[cabo]

The server can offer more than one content type; the client can choose between them. This is the intended semantics. But this should be done in one attribute as a space-separated list, not in multiple attributes. Check whether this is a correction or a clarification.

[mcr]

(apparently, my mute does not unmute) while it is useful to tell creators of the CT not to repeat, what advice to consumers of the CT if it occurs more than once?

[chrysn]

This should be clarified together with the relevant RFC6690 text that establishes this behavior for rt= (from where ct= probably drew inspiration); there it says "MUST NOT appear more than once in a link", without guidance as to what recipients do when they are repeated.

RFC8288 is not explicit about whether there can be significance in the order of target attributes. If there is, and we are reasonably confident that nobody is yet producing multiple ct= attributes per link, we could accept this erratum as a correction and add that "and clients MUST ignore any later occurrence of the attribute".

[cabo]

We don't have to specify what it means to a link-format interpreter if a link-format source violates a MUST. (The C language has this great idea of "undefined behavior" where the implementation can do what it wants including lighting the candles on a birthday cake for you.)

[sbernard31]

This clarification would be welcome, by the past we face some interpretation issue about this :

• https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/544
• https://github.com/eclipse/leshan/issues/1229#issuecomment-1086111310