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

Commentary: wrote :  , setting a default value for Max - Message - Size means that the option is virtually present in any CSM message , setting that value . In other words , an empty CSM resets      to 1152 . That is probably not what we want . It is probably best to point out that pitfall when introducing CSM options -- they never should have default values ( the settings expressed by these options very well can ) . The original text in : As per Section 4.6 of [ RFC7252 ] , the default value ( and the value used when this Option is not implemented ) is 1152 . Could you clarify what you 're proposing ? I 'm also still unclear about this notion of empty CSM(s ) resetting all options to default values . 
 Closed in 
 Both capability and and setting options are cumulative ... An option that is given might override a previous value for the same option ; the option defines how to handle this , if needed . My model for options is simpler . New options replace existing options . The value of an option is the last value received by the peer . What does cumulative mean in the current text and how does it relate to might override . ? 
 Closed in 
 Both capability indication options and setting options are cumulative , i.e. , a capability message without any option is a no - operation ( and can be used as such ) . Could you clarify the meaning / intent of this text ? 
 - I still do not understand the phrase -and can be used as such . What is the scenario for sending a no - op CSM ? I 'd expect different language indicating that it can be ignored . 
 This might make more sense in the context of - where an empty ( no option ) message is possible . 
 Closing since we 're adopting which is a scenario for this case . 
 Capturing embedded issues from : a UDP - to - TCP gateway may simply not have the context to convert a message with a Block option into the equivalent exchange without any use of a Block option . commented : I do n't understand this argument . 
 - who authored that text ? Hannes responded that he did not write this . 
 I do n't know who this , but I do remember a conversation in Yokohama around the scenario of the UDP - TCP gateway needing to buffer the complete set of blocks ( from the UDP side ) before passing it onto the TCP side . For large numbers of blocks , this would result in a large storage requirement on the gateway in order to buffer the entire set of blocks . 
 This text came in slightly before the July 2015 meeting . I put it in , but that does n't mean I wrote it ... 
 I spoke with  and he noted that it was a f2f comment at the Yokohama meeting . Perhaps it 's in the meeting minutes . 
 Closed in
CoAP over WebSockets is intentionally very similar to CoAP as defined
over UDP.  Therefore, instead of presenting CoAP over WebSockets as a
new protocol, this document specifies it as a series of deltas from
RFC7252.
CoAP over WebSockets is intentionally very similar to CoAP over UDP.
Therefore, instead of presenting CoAP over WebSockets as a new
protocol, this document specifies it as a series of deltas from
RFC7252.
Messages MUST NOT be Empty (Code 0.00), i.e., messages always carry
either a request or a response.
Empty messages (Code 0.00) are ignored by the recipient (see also
sec-ping).
Both capability and and setting options are cumulative, i.e., a
capability message without any option is a no-operation (and can be
used as such).  An option that is given might override a previous
value for the same option; the option defines how to handle this, if
needed.
Both capability and settings options are cumulative, i.e., a
Capability and Settings message does not invalidate a previously made
capability indication or setting even if that is not repeated, and a
capability message without any option is a no-operation (and can be
used as such).  An option that is given might override a previous
value for the same option; the option defines how to handle this, if
needed.
Default values given below for CSM Options are not default values for
the option (this would mean that an empty Capability and Settings
message would set the option back to its default value).  Instead
they give the base value for the Capability and Setting before any
Capability and Settings message sends a modified value.
The Bad-CSM-Option indicates that the sender is unable to process the
CSM option identified by its option number, e.g. when it is critical
and the option number is unknown by the sender, or when there is
parameter problem with the value of an elective option.  More
detailed information SHOULD be included as a diagnostic payload.
The Bad-CSM-Option Option indicates that the sender is unable to
process the CSM option identified by its option number, e.g. when it
is critical and the option number is unknown by the sender, or when
there is parameter problem with the value of an elective option.
More detailed information SHOULD be included as a diagnostic payload.