Responses lack "origin" details

[romanojd]

PROBLEM

Response messages need to contain information specifying the sender of the response.

---

POTENTIAL SOLUTION

As we discussed at the bi-weekly meeting, 10/13, we will add "origin" information to the response and alert messages and not rely on external dependencies.

Option A: use "origin" modifier

• Create an action-specific modifier for RESPONSE and ALERT. The value will be the UUID of the sender of the message.

Option B: use "actuator" field

• The Language Description Document does not currently use the "actuator" field for RESPONSE and ALERT. For most actions, the "actuator" field is used to specify the destination of the action, but for a response it could be used to specify the origin.

[jyoverma]

I vote for Option A: using a modifier. However, there is already a command-ref in the response modifier today which IMO could carry the UUID unless it is meant for something else.

Option B will need a bit of re-training of the mind and can lead to confusion since we haven't seen it in this light so far.

[jmbrule]

The command-ref in the response was 'Command Reference' which was an early attempt to link it to the action that stimulated the response, so populating the command-ref field with the UUID is consistent... If for whatever reason, the group decides against using the command reference field, then go with option A. Option B (using the actuator field) is going to lead to unnecessary confusion.

[jmbrule]

Unless I am mistaken, this issue has been TCO. The latest format of the response frame that I have seen is: response { source DeviceID, cmdref CommandID, status StatusCode, statusText UTF8String, results UTF8String } The source is spelled out. May I suggest we close this issue?

[romanojd]

The RESPONSE format will have origin details. This issue is closed.