Opened 10 years ago

Closed 10 years ago

#264 closed other technical (fixed)

Content-Format of error responses

Reported by: cabo@… Owned by: draft-ietf-core-coap@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-12
Severity: In WG Last Call Keywords:
Cc:

Description

Klaus Hartke notes:

Section 5.5.2

The Content-Format Option MUST NOT be included by the sender and MUST be treated like an unrecognized option by the recipient.

For future extensibility (HATEOAS) and to reduce variability it might be better if the format of the representation of an error was determined by the Content-Format Option like the format of any other representation.

Require the inclusion of a Content-Format Option with a value indicating a human-readable diagnostic message (i.e., text/plain or some new media type).

Comment (Carsten Bormann):

Originally, the assumption was that on error messages, some developer-readable (as opposed to human-readable) messages would suffice that were essentially assumed to be in Content-Format 0 (text/plain; charset=UTF-8). It is useful to retain this diagnostic capability, which was originally meant to solve the same problem the "reason phrase" solves on an HTTP status line.

However, even error messages may want to guide the application state on the client. So, not being able to supply a representation that, e.g., provides alternate links to be used by the application, is a significant limitation from a full REST model.

If we want to enable sending a content-format for this, defaulting to ct=0 just for error messages sounds wrong, but maybe could be justified.

Change History (1)

comment:1 Changed 10 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [1097]:

close #264 as discussed

Note: See TracTickets for help on using tickets.