Subject: [core] #389 (coap-tcp-tls): Version negotiation

From: "core issue tracker" <[email-masked]>
Date: Tue, 08 Dec 2015 13:13:42 -0000

#389: Version negotiation

 How does a client figure out which CoAP versions a server speaks? For
 example, what should happen when a client sends a message in a version
 that the server does not implement? Should the server just close the
 connection?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-coap-tcp-
  [email-masked]         |  [email-masked]
     Type:  protocol     |     Status:  new
  defect                 |  Milestone:
 Priority:  minor        |    Version:
Component:  coap-tcp-    |   Keywords:
  tls                    |
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/389>
core <https://tools.ietf.org/core/>

---

From: Bill Silverajan <[email-masked]>
Date: Thu, 10 Dec 2015 21:54:52 +0200

Hi,

My reply is inline:

>   that the server does not implement? Should the server just close the

It seems useful to look at section 6 of RFC 7231 
(https://tools.ietf.org/html/rfc7231#section-6.6.6) :

   "The 505 (HTTP Version Not Supported) status code indicates that the 
   server does not support, or refuses to support, the major version of 
   HTTP that was used in the request message ....  The server SHOULD 
generate a representation for the 505 response that describes why   that 
version is not supported and what other protocols are supported   by 
that server."

- Mostly because RFC7252 attempts to relate CoAP Response Codes to HTTP 
where possible. However, since 5.05 is already used to indicate 
"Proxying Not Supported", existing options are 5.01 Not Implemented, or 
extending CoAP with a new 5.06 Version Not Supported, with perhaps the 
response payload providing the server supported version(s).

On a related note, section 5.9 of RFC 7252 refers to a part of RFC 2616 
that has now been updated by RFC 7231. Please see 
https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

Regards,
Bill