Opened 10 years ago

Closed 10 years ago

#265 closed other technical (fixed)

ETag Option in responses other than 2.05

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


Klaus Hartke notes:

Section 5.10.7:

The ETag Option in a response provides the current value of the entity-tag for the enclosed representation of the target resource.

In other words, the ETag Option must not be included in responses other than 2.05 (Content), because no other response type transfers the representation of the target resource.

However, Section says on the 2.03 (Valid) response type:

Related to HTTP 304 "Not Modified", but only used to indicate that the response identified by the entity-tag identified by the included ETag Option is valid. Accordingly, the response MUST include an ETag Option.

So Section 5.10.7 should be updated to reflect that.

Furthermore, the ETSI CoAP Plugtest 2 test specification (v009b) contains the following step:

Server sends response containing:

  • Code = 68 (2.04 Changed)
  • Option type = ETag
  • Option value = an arbitrary ETag value which differs from the ETag sent in step 3

So the test specification is wrong according to Section 5.10.7, but it might be more useful to extend the draft with ETag Options in 2.04 (Changed) responses than fix the test specification.

Comment (Carsten Bormann):

In httpbis, this was recently addressed in ticket 330:

See also:

This Changeset 1571 to httpbis part 3 introduced a new term from part 4: selected representation.
Part 2 has:

8.2. Selected Representation Header Fields

We use the term "selected representation" to refer to the the current
representation of a target resource that would have been selected in
a successful response if the same request had used the method GET and
excluded any conditional request header fields.

(If you are as confused by the restructuring of HTTP into "parts" as I am, you are in good company.)

It also defines ETag as a header field (the HTTP name for what we call "Option") for

metadata about the selected
representation, which might differ from the representation included
in the message for responses to some state-changing methods.

I believe the CoRE WG should do the same, which makes clear what the ETag in 2.03 means.
(We also could probably benefit from a more operable definition of what the selected representation is in our context.)

The CoRE WG then could (or could not) go ahead and allow ETag in 2.04 and 2.01 (not quite so sure about 2.02 :-).
We should discuss the use cases that would benefit from this.

Change History (1)

comment:1 Changed 10 years ago by cabo@…

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

Fixed in [1109]:

Close #265

Note: See TracTickets for help on using tickets.