Open ektrah opened 5 years ago
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.
(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?
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".
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.)
This clarification would be welcome, by the past we face some interpretation issue about this :
Errata ID: 5078 Type: Technical Reported By: Jim Schaad Date Reported: 2017-08-07
Section 7.2.1 says/should say:
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.