CAN Frame: `is_remote_frame()` and `new_remote()`

[ocornu]

The CAN Frame method is_remote_frame() returns:

• true if the frame is a Remote Transmission Request (RTR bit is set)
• false if the frame is a Data Frame (RTR bit is clear)

In other words, it allows to distinguish between:

• a frame which contains actual data, and
• a frame which contains no data, but requests that data be sent back

Calling the latter a "remote frame" is terribly misleading:

1. It's no more "remote" than a data frame: both come from another device on the bus
2. It does not convey that it contains no data, nor that it wants data to be sent back
3. it's not the exclusive opposite to its boolean alternative (the opposite of "remote" is "local" ―not "data", and the opposite of "data" is "no data" ―not "remote"), leading to confusing code like this:

    /// Returns true if this frame is a data frame.
    fn is_data_frame(&self) -> bool {
        !self.is_remote_frame()
    }

4. Lastly, in device testing mode (we receive the frames we send), it's not even "remote" anymore! Now this unfortunate name has lost any and all connection to whatever meaning it was trying to convey to begin with…

If one wants to shorten "Remote Transmission Request", the only important word in there is: request. Therefore, I'm suggesting that:

• is_remote_frame() be renamed into is_request_frame()
• new_remote() be renamed into new_request()

This way, it makes it clear that we're in a "transactional" context, where each frame is either a request or a reply/broadcast:

    /// Returns true if this frame is a data frame.
    fn is_data_frame(&self) -> bool {
        !self.is_request_frame()
    }

Thank you!

[fard-draf]

Calling an RTR frame a RemoteFrame may indeed seem confusing when DataFrame and RemoteFrame are interpreted as ordinary English terms. However, they are not intended to be linguistic opposites: they are the terms used by the CAN specification for the two frame types.

The important question is therefore which abstraction layer the API should describe.

RemoteFrame preserves CAN data-link-layer terminology. RequestFrame describes what an RTR frame does, but introduces a broader term that may already have a distinct meaning in higher-layer protocols.

J1939 provides a concrete example. It defines a Request message (PGN 59904) that is transported in a CAN Data Frame. Therefore, for a valid J1939 Request message:

 frame.is_data_frame()    == true;
 frame.is_request_frame() == false;

Consequently, although this implementation would be correct at the CAN layer:

 fn is_data_frame(&self) -> bool {
     !self.is_request_frame()
 }

it could be misleading when the frame is used by a higher-layer protocol in which “request” has its own meaning.

For this reason, I think retaining RemoteFrame has value: it preserves standard CAN terminology and keeps it distinct from higher-layer concepts such as a J1939 Request message.

That's just my interpretation of it!