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

Commentary: sig-02 did not define the length for options with uint values . Can you confirm whether 0 - 4 is correct ? I note that there are variants in the  options with uint values . 
 Good catch . 0 - 4 definitely is right for  - Message - Size . 0 - 4 is a bit over the top for Hold - Off , but arbitrarily limiting the time at , say , seconds ( 0 - 2 ) or seconds ( 0 - 3 ) does n't sound right either -- well , maybe half a year  ( 0 - 3 ) is about right . Option numbers are  , so Bad - CSM - Option needs to be 0 - 2 . 
 https://core- Missed this one while simplifying the option names . 
  has Table 4 for Options which includes : Critical Name Format Length Default A similar table should be for Signaling Options at a glance . 
 We need to decide whether this feature is required . If not , then I do n't think that it 's useful to include speculative text : CoAP is defined in RFC 7252 with a version number of 1 . In contrast to the message layer for UDP and DTLS , the CoAP over TCP message layer does not send the version number in each single message . Instead , options for the Capability and Settings message can be used to perform a version negotiation . At the time of writing , there is no known reason for supporting version numbers different from 1 . The details of a version negotiation , once it is actually needed , will depend on the specifics of the new version(s ) , so the present specification makes no attempt to specify these details . However , Capability and Settings messages have been specifically designed with a view to supporting such a potential future need . 
 It is not required , because we do n't have a version ≠ 1 . ( The whole point of the section is actually to explain that it is not required , and it would be misguided to define it now because we do n't know what characteristics a new version would have , but that the feature is easily provided using CSM . ) I strongly believe that a standard should provide guidance with respect to its own evolution . Too often , that information is lost when the standard is completed in its 1.0 version , and when people go about making 2.0 ( or 1.1 ) they make all kinds of stupid mistakes because they simply do n't know what evolvability is already built in . But maybe that material can be moved into an appendix if it is too much out of place here . 
 In previous versions of the WebSockets draft , we defined the WebSocket subprotocol name as " coapv1 " during the upgrade handshake and for the last version ( now merged ) , the WebSocket subprotocol name has been altered to simply " coap " , for the same reasons , ie , there 's no good reason to consider other versions . If we keep the above section on CSM and versioning into the main body , I think it would be a good idea to consider if and how harmonising can be done with the text talking about CoAP versions for WebSockets in the following sections : : " Any later , incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name . " : " Furthermore , since the CoAP version is already negotiated during the opening handshake , the “ Ver ” field can be elided as well . " Alternatively , the text in Section 4.2 can simply be amended to mention no version negotiation is performed during the upgrade handshake , and therefore the field is elided . 
 Until there 's broader discussion , I have retained the CSM section on version negotiation . In my private branch , I 've previously updated the section related to the “ Ver ” field can be elided as well " to reference the CSM speculative section . 
 Addressed in
The underlying reliable protocols have methods to configure
connection properties and manage the connection.  In many cases,
these methods are inadequate for managing CoAP's use of the
connection.
Signaling messages are introduced to signal information about the
connection.  They define a third basic kind of messages in CoAP,
after requests and responses.
Signaling messages share a common structure with the existing CoAP
messages.  There is a code, a token, options, and an optional
payload.
Signaling is a third basic kind of message in CoAP, after requests
and responses.  Signaling messages share a common structure with the
existing CoAP messages.  There is a code, a token, options, and an
optional payload.
Capability options advertise a capability from the sender to the
recipient.
Both capability options 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.  Most CSM options are useful mainly as initial messages in
the connection.
Server-Name is a critical option and carries a "string" value, with
the same restrictions as Uri-Host (Section 5.10 of RFC7252: length is
between 1 and 255).
For Websockets, the initial value for the Server-Name is given by the
HTTP Host header field.
A sender can indicate a maximum message size that it can receive.
A sender can indicate that it supports the block-wise transfer
protocol defined in I-D.ietf-core-block.
Block-wise-Transfer is an elective option with an empty value.  If
the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not.  An
implementation that supports block-wise transfers SHOULD indicate the
Block-Wise Transfer option.  If a Max-Message-Size option is
indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-Wise Transfer option also indicates
support for BERT (see bert).
CoAP is defined in RFC7252 with a version number of 1.  In contrast
to the message layer for UDP and DTLS, the CoAP over TCP message
layer does not send the version number in each single message.
Instead, options for the Capability and Settings message can be used
to perform a version negotiation.
At the time of writing, there is no known reason for supporting
version numbers different from 1.  The details of a version
negotiation, once it is actually needed, will depend on the specifics
of the new version(s), so the present specification makes no attempt
to specify these details.  However, Capability and Settings messages
have been specifically designed with a view to supporting such a
potential future need.
A Ping message is responded to by a single Pong message with the same
token.  As with all Signaling messages, the recipient of a Ping or
Pong message MUST ignore elective options it does not understand.
A Custody Option can also be sent in a Ping message to explicitly
request the return of a Custody Option in the Pong message.  A peer
is always free to indicate that it has finished processing all
previous request/response messages by sending a Custody Option (which
is therefore elective) in a Pong message.  A peer is also free NOT to
send a Custody Option in case it is still processing previous
request/response messages; however, it SHOULD delay its response to a
Ping with a Custody Option until it also can return one.
The Custody option is an elective option with an empty value.
Capability options advertise the capabilities of the sender to the
recipient.
Most CSM options are useful mainly as initial messages in the
connection.
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.
A client can use the Server-Name critical option to indicate the
default value for the Uri-Host options in the messages that it sends
to the server.  It has the same restrictions as the Uri-Host option
(Section 5.10 of RFC7252.
For Websockets, the initial value for the Server-Name option is given
by the HTTP Host header field.
The sender can use the Max-Message-Size elective option to indicate
the maximum message size in bytes that it can receive.
As per Section 4.6 of RFC7252, the default value (and the value used
when this option is not implemented) is 1152.  A peer that relies on
this option being indicated with a certain minimum value will enjoy
limited interoperability.
A sender can use the Block-wise Transfer elective option to indicate
that it supports the block-wise transfer protocol I-D.ietf-core-
block.
If the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not.  An
implementation that supports block-wise transfers SHOULD indicate the
Block-wise Transfer option.  If a Max-Message-Size option is
indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-wise Transfer option also indicates
support for BERT (see bert).
Upon receipt of a Ping message, a single Pong message is returned
with the identical token.  As with all Signaling messages, the
recipient of a Ping or Pong message MUST ignore elective options it
does not understand.
A Custody elective option can also be sent in a Ping message to
explicitly request the return of a Custody option in the Pong
message.  A peer is always free to indicate that it has finished
processing all previous request/response messages by sending a
Custody option in a Pong message.  A peer is also free NOT to send a
Custody option in case it is still processing previous request/
response messages; however, it SHOULD delay its response to a Ping
with a Custody option until it can also return one.
Bad-Server-Name indicates that the default as set by the CSM option
Server-Name is unlikely to be useful for this server.  It has an
empty value.
Alternative-Address requests the peer to instead open a connection of
the same kind as the present connection to the alternative transport
address given.  The value is a string of the form "authority" as
defined in Section 3.2 of RFC3986.
Hold-Off indicates that the server is requesting that the peer not
reconnect to it for the number of seconds given in the "uint" value.
The Bad-Server-Name elective option indicates that the default
indicated by the CSM Server-Name option is unlikely to be useful for
this server.
The Alternative-Address elective option requests the peer to instead
open a connection of the same kind as the present connection to the
alternative transport address given.  Its value is in the form
"authority" as defined in Section 3.2 of RFC3986.
The Hold-Off elective option indicates that the server is requesting
that the peer not reconnect to it for the number of seconds given in
the value.
An abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly
release.  The sender shuts down the connection immediately after the
abort (and may or may not wait for a release or abort message or
connection shutdown in the inverse direction).  A diagnostic payload
SHOULD be included in the Abort message.  Messages may be in flight
when the sender decides to send an abort message; the general
expectation is that these will NOT be processed.
An abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly
release.  The sender shuts down the connection immediately after the
abort (and may or may not wait for a release or abort message or
connection shutdown in the inverse direction).  A diagnostic payload
SHOULD be included in the Abort message.  Messages may be in flight
when the sender decides to send an abort message.  The general
expectation is that these will NOT be processed.
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.  The value is
a "uint".  More detailed information SHOULD be included as a
diagnostic payload.
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 use of this new extension is signalled by sending Block1 or
Block2 options with SZX == 7 (a "BERT option").  SZX == 7 is a
reserved value in I-D.ietf-core-block.
The use of this new extension is signaled by sending Block1 or Block2
options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved
value in I-D.ietf-core-block.