Post by malbolge on Jan 15, 2020 11:59:47 GMT
This post abstracts away all the RDE stuff like PDRs and dictionaries.
Suppose we have an RDE enabled toaster, supporting one resource/schema - Toaster_v1.0.0.xml serving us JSONs in the form of:
{
"Wattage":1000,
"Brand": "Krisptec",
"Status": "Off"
}
The resource itself supports reads and writes. Blue properties are read-only, red properties are read-write.
Suppose the user requests (though the MC) an RDE UPDATE to our Toaster resource:
{
"Wattage":9000,
"Brand": "MaillardMaster",
}
Our RDE toaster is, according to my understanding of the DSP0218 spec, supposed to return success (and a successful FSM operation) to the MC. The MC, upon seeing this from the RDE toaster, returns 400 OK
However, notice that we haven't actually written anything. We can't change the wattage nor the manufacturer through RDE. The RDE toaster silently ignores all RO properties. Even though the operation is technically successful (on the PLDM return code and RDE FSM level), it has had no effect.
My understanding is that if an operation with no effect like this one occurs, we err on the side of permissiveness. This does seem to contradict the Redfish (DSP0266) specification, which states that the expected result of such an operation would be HTTP 200.
To summarize the question: How should RDE devices react to attempts to perform writes to read-only properties? What should be the end result (user-facing HTTP) of such an attempt? Is behavior for Redfish-native devices and RDE-enabled ones diffrerent by design, or by accident?
Suppose we have an RDE enabled toaster, supporting one resource/schema - Toaster_v1.0.0.xml serving us JSONs in the form of:
{
"Wattage":1000,
"Brand": "Krisptec",
"Status": "Off"
}
The resource itself supports reads and writes. Blue properties are read-only, red properties are read-write.
Suppose the user requests (though the MC) an RDE UPDATE to our Toaster resource:
{
"Wattage":9000,
"Brand": "MaillardMaster",
}
Our RDE toaster is, according to my understanding of the DSP0218 spec, supposed to return success (and a successful FSM operation) to the MC. The MC, upon seeing this from the RDE toaster, returns 400 OK
However, notice that we haven't actually written anything. We can't change the wattage nor the manufacturer through RDE. The RDE toaster silently ignores all RO properties. Even though the operation is technically successful (on the PLDM return code and RDE FSM level), it has had no effect.
My understanding is that if an operation with no effect like this one occurs, we err on the side of permissiveness. This does seem to contradict the Redfish (DSP0266) specification, which states that the expected result of such an operation would be HTTP 200.
To summarize the question: How should RDE devices react to attempts to perform writes to read-only properties? What should be the end result (user-facing HTTP) of such an attempt? Is behavior for Redfish-native devices and RDE-enabled ones diffrerent by design, or by accident?
