openlcb / documents

The OpenLCB specification: standards, recommended practices and other documentation.
3 stars 7 forks source link

Clarification of Reject Addressed Optional Interaction #86

Closed bobjacobsen closed 5 months ago

bobjacobsen commented 1 year ago

Message Standard 3.5.1 says:

If a Node receives an addressed message with an MTI that is not part of the mandatory set, and it does not want to take part in that interaction, it shall send an Optional-Interaction Rejected (OIR) message addressed to the originating node, with the original MTI in the message content to indicate that the MTI is not recognized or not implemented by this node. The OIR message content may also contain a reason code and a data value, as defined by the protocol, as listed below in section 3.5.6.

The "if ... it does not want to take part in that interaction" seems to be unclear.

Some existing nodes will send an OIR to every self-addressed MTI that they don't otherwise implement. Other existing nodes will silently ignore them.

The original intent was that a node would always reply with OIR if it received a self-addressed MTI that it was not going to process via some other interaction. That way, the sending node would be told that the receiving node wasn't able to properly handle a request, and could invoke some error handling. The goal here was to provide that error handling (without need for timeouts) for future interactions that might involve MTIs that pre-existing nodes didn't implement.

I think the "does not want to take part" language leaves this behavior as somewhat optional, and think it should be updated. Perhaps a suitable replacement would be "does not otherwise implement".

dpharris commented 1 year ago

The Message Standard says "shall", ie mandatory. I think the intent was that a node that does not implement the MTI, OR does not or cannot, temporarily or otherwise, process the MTI (for some reason, eg no memory space, busy, etc), shall respond with an OIR, with a reason.

Perhaps the Standard should say: "and it does not implement or cannot otherwise process that interaction" ?

David

On Tue, May 30, 2023 at 5:12 AM Bob Jacobsen @.***> wrote:

Message Standard 3.5.1 says:

If a Node receives an addressed message with an MTI that is not part of the mandatory set, and it does not want to take part in that interaction, it shall send an Optional-Interaction Rejected (OIR) message addressed to the originating node, with the original MTI in the message content to indicate that the MTI is not recognized or not implemented by this node. The OIR message content may also contain a reason code and a data value, as defined by the protocol, as listed below in section 3.5.6.

The "if ... it does not want to take part in that interaction" seems to be unclear.

Some existing nodes will send an OIR to every self-addressed MTI that they don't otherwise implement. Other existing nodes will silently ignore them.

The original intent was that a node would always reply with OIR if it received a self-addressed MTI that it was not going to process via some other interaction. That way, the sending node would be told that the receiving node wasn't able to properly handle a request, and could invoke some error handling. The goal here was to provide that error handling (without need for timeouts) for future interactions that might involve MTIs that pre-existing nodes didn't implement.

I think the "does not want to take part" language leaves this behavior as somewhat optional, and think it should be updated. Perhaps a suitable replacement would be "does not otherwise implement".

— Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/issues/86, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDQSUQVGDXKFLXKPNHQRDXIXP2DANCNFSM6AAAAAAYT5KE4M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

balazsracz commented 5 months ago

We know that OpenMRN's behavior is incorrect according to the intent of the standard. That is a bug in OpenMRN. (https://github.com/bakerstu/openmrn/issues/785)