Subject: [core] coap #86 (new): Response code numbering

From: "core issue tracker" <[email-masked]>
Date: Thu, 25 Nov 2010 17:17:40 -0000

#86: Response code numbering

 From RFC2616:

   HTTP status codes are extensible. HTTP applications are not required to
 understand the meaning of all registered status codes, though such
 understanding is obviously desirable. However, applications MUST
 understand the class of any status code, as indicated by the first digit,
 and treat any unrecognized response as being equivalent to the x00 status
 code of that class, with the exception that an unrecognized response MUST
 NOT be cached. For example, if an unrecognized status code of 431 is
 received by the client, it can safely assume that there was something
 wrong with its request and treat the response as if it had received a 400
 status code.

 To maintain reasonable behavior as we introduce new status codes in CoAP,
 we want to have similar language in the base CoAP spec.

 This raises the question about how to number CoAP-specific error codes.

 The current draft specifies CoAP-specific error codes in the new 240-255
 class. We don't want to treat all unknown CoAP errors as "240 Token
 Required."

 Possible solutions include:

   * Instead of using 6xx codes (240 base 10-10) for CoAP-specific
 applications, we might reserve x3x.
   So the set of CoAP-specific 400-kind codes would be 430, 431, etc.

   This still works with the [http://www.iana.org/assignments/http-status-
 codes HTTP assignments] so far. If somebody really comes up with an HTTP
 43x and we want to use that, we can map it to a CoAP status code.

   *  Taking advantage of what would be the nonsensical "0xx" status code
 range in HTTP:

       1 - 9 : CoAP-specific 2xx-class responses
       10 - 19: CoAP-specific 3xx-class responses
       20 - 29: CoAP-specific 4xx-class responses
       30 - 39: CoAP-specific 5xx-class responses

   Alternately, as it seems unlikely that CoAP-specific responses are
 unlikely to ever be in the 2xx or 3xx class, we could give ourselves more
 headroom by defining them as:

       1 - 19: CoAP-specific 4xx-class responses
       20 - 39 : CoAP-specific 5xx-class responses

   Since this conflicts with method codes, these would need to be moved to
 the 240-255 space, substantially reducing the headroom for future method
 codes.

   * Limit ourselves to a maximum of 20 methods, and take 20-29 for 4xx-
 like codes and 30-39 for 5xx-like codes.

-- 
----------------------------+-----------------------------------------------
 Reporter:  hartke@…        |       Owner:     
     Type:  task            |      Status:  new
 Priority:  minor           |   Milestone:     
Component:  coap            |     Version:     
 Severity:  -               |    Keywords:     
----------------------------+-----------------------------------------------

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

---

From: Peter Bigot <[email-masked]>
Date: Thu, 25 Nov 2010 13:02:24 -0600

Not to be more of a pain than I usually am, but I've never understood the
desire to use decimal groupings for these types.  They need to be recognized
and processed on constrained nodes; if there's a value at all in assigning
them to groups, wouldn't a bit-partitioning scheme make more sense than
doing a series of range checks or dividing by ten?  Maybe mask with 0x70 and
shift right four bits to get the HTTP code class.  That'd give us 32 codes
in each class, plus a few classes left over for CoAP-specific needs.

Just a thought.

Peter

On Thu, Nov 25, 2010 at 11:17 AM, core issue tracker <[email-masked]>wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>