Opened 11 years ago

Closed 11 years ago

#183 closed editorial (fixed)

Check consistency of statements about RST on NON

Reported by: cabo@… Owned by: draft-ietf-core-coap@…
Priority: major Milestone:
Component: coap Version:
Severity: Active WG Document Keywords:
Cc:

Description

Thomas Fossati notes:

apropos, section 4.3 of coap-08 seems to imply that RST can be sent in reply to a NON message, but then 4.4.4 associates RST to CON only (consistently with the usage in current Observe I-D.). To add some more entropy, the changelog says that 05->06 transition included an "Allowed RST message in reply to a NON message with unexpected token", but I can't see it anywhere in -08.
This all leaves some degree of ambiguity about whether RST is a valid response to a NON message or not.
_

Change History (2)

comment:1 Changed 11 years ago by cabo@…

Salvatore also notes:

sections seems to imply that RST MUST be used only with confirmable messages
4.4.4. Reset (RST)

A Reset message indicates that a specific confirmable message was
received, but some context is missing to properly process it. This
condition is usually caused when the receiving node has rebooted and
has forgotten some state that would be required to interpret the
message.

A reset message MUST echo the Message ID of the confirmable message,
and MUST be empty.

however, section 4.2 states that it MAY be used also with an Unreliable Message

4.2. Unreliable Messages

As a more lightweight alternative, a message can be transmitted less
reliably by marking the message as "non-confirmable". A non-
confirmable message MUST NOT be acknowledged by the recipient. If a
recipient lacks context to process the message properly, it MAY
reject the message with a reset message or otherwise MUST silently
ignore it.

comment:2 Changed 11 years ago by zach@…

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

Done.

Note: See TracTickets for help on using tickets.