Subject: [core] #183: Check consistency of statements about RST on NON

From: "core issue tracker" <[email-masked]>
Date: Mon, 13 Feb 2012 19:44:54 -0000

#183: Check consistency of statements about RST on NON

 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.
 _______________________________________________

-- 
--------------------------------+------------------------------------
 Reporter:  cabo@…              |      Owner:  draft-ietf-core-coap@…
     Type:  editorial           |     Status:  new
 Priority:  major               |  Milestone:
Component:  coap                |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+------------------------------------

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

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 15 Feb 2012 09:06:25 -0000

Comment (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.

-- 
--------------------------------+-------------------------------------
 Reporter:  cabo@…              |       Owner:  draft-ietf-core-coap@…
     Type:  editorial           |      Status:  new
 Priority:  major               |   Milestone:
Component:  coap                |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/183#comment:1>
core <http://tools.ietf.org/core/>