Original text:
elective option.  More detailed information SHOULD be included as a diagnostic payload. <del> One reason for an sender to generate an Abort message is a general syntax error in the byte-stream received.  No specific option has been defined for this, as the details of that syntax error are best left to a diagnostic payload. </del>  5.7.

Reviewer comments:
URL - WGLC review by Esko Dijk. In RFC 7252, the Reset message (RST) is also used to deal with certain cases of malformed CoAP messages or incorrect field values. Since the RST message is now removed, I think there should be text on how to deal with these cases. For example in Figure 21 (RFC 7252) the Token value is not recognized which leads to a RST. How should CoAP-over-reliable deal with this case and related cases? Although the draft suggests that Client (if we take the Fig 21 case) could abort the connection, that sounds rather drastic and unnecessary – the client and server need to keep talking to each other typically. Silently ignoring seems better in that case. And in case the receiver of an 'incorrect' message decides not to abort, what should it do instead – anything normative? Related cases for CoAP message receivers are: Token not recognized -> could happen in the Figure 21 use case, silently ignore seems best. Or would there be a reason to notify the response sender that the response is not recognized? (RFC 7252 allows to do this at least.) Token Length TKL is wrong (e.g. length is 9 to 15) -> could be sent by a malicious CoAP endpoint, good reason to abort perhaps Code unrecognized (e.g. 1.xx, 3.xx, 0.31 … ) -> could happen if one of the endpoints supports other/newer CoAP features, perhaps abort, or perhaps silently ignore? Possibly malicious endpoint. Summarizing it seems to me the best to specify a receiver MAY abort the connection and also MUST silently ignore the malformed message. This could be made more explicit in the text.
~
URL My initial instinct would be MUST abort the connection. Can those with early (but shipping) implementations offer any guidance on how this case is currently being handled? What do others think?
The protocol design problem here is that any new feature that is treated harshly by old peers effectively cannot be used. So it is generally better to react with diagnostics to unknown features. Unless there is a way to provide a feature capability indication, which we do have. This then becomes essentially mandatory for any new feature. Clearly MUST abort for syntax violations such as TKL > 8. (If we ever find a use for these field values, they will need a capability indication.) An unrecognized token in a response should never happen. To me this also looks like a MUST abort. (RFC 7252 Figure 21 is about a client losing its state, in which case it would also lose its TCP connection, so that particular case cannot happen on an existing TCP connection.) Grüße, Carsten
Could we indicate that CoAP over reliable aborts the connection for any message format error defined in RFC7252 (plus the unrecognized token case)? URL URL Option Delta: Option Length: URL
Sounds good to me. Message format error = syntax violation Unrecognized token = failure of mandatory matching I’m just trying to think whether there are other “cannot happen”s that need to be on this list. Grüße, Carsten
While you're thinking about other "cannot happens" ... The existing text in the Abort section can be updated to cover this issue in a general way:

Revised text:
elective option.  More detailed information SHOULD be included as a diagnostic payload.  <ins> For CoAP over UDP, messages which contain syntax violations MUST be processed as message format errors.  As described in Sections 4.2 and 4.3 of RFC7252, such messages are rejected by sending a matching Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </ins> 5.7.