Draft: draft-ietf-core-coap-tcp-tls

Commentary: WGLC review by   . 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  ( if we take the  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  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 . 
 ~ 
 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 can not 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 can not happen on an existing TCP connection . )  ,  
 Could we indicate that CoAP over reliable aborts the connection for any message format error defined in  ( plus the unrecognized token case ) ? Option Delta : Option Length : 
 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 “ can not happen”s that need to be on this list .  ,   While you 're thinking about other " can not happens " ... The existing text in the  section can be updated to cover this issue in a general way :
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.
For CoAP over UDP, messages which contain syntax violations MUST be
processed as message format errors.  As described in Sections 4.2 and
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.