|
|
Post by vincent0607 on Aug 10, 2022 14:28:03 GMT
Hi All,
assuming a created OEM message registry, not sure if this OEM message can include partial DMTF Message registry (such like from 'Base')?
And is it legal? any copyright problem?
Note:
Basic idea is that, for example, we want to copy some related HTTP meesages from DMTF 'Base' message registry to OEM 'HttpStatus' message registry for usage,
Thus, it can be more flexiable to subscribe event with more options in 'RegistryPrefixes' subscription parameter
Thanks
|
|
|
|
Post by jautor on Aug 10, 2022 15:58:27 GMT
Why are you copying the messages instead of just using them? For interoperability, you would want clients to subscribe to the standard RegistryPrefixes as well as your OEM ones. Your OEM messages should really be "in addition to the standard messages, we have these..."
Are you adding "more information" to the messages or creating new ones for cases that aren't covered in Base? For both of those cases, I'd suggest contributing those to the DMTF to see if it makes sense to just add them to the standard registry.
(not going to get into the legal aspects here - talk to your legal folks, but generally speaking, ensuring that property attribution is given on derivative works is the "important" part)
Jeff
|
|
|
|
Post by vincent0607 on Aug 11, 2022 8:41:41 GMT
Thanks your explicit explanation, and learned a lots .
Some opinion from my side, not sure if you guys will consider, in future, to move related messages topic from 'Base' registry to other independent official registry, such like "Http" or "Security" registry. If do so, this benefit might be that event subscription in RegistryPrefixes filter can narrow down easily to specific topic or more flexible to choose messages types to filter
|
|
|
|
Post by mraineri on Aug 12, 2022 19:10:51 GMT
We've certainly been publishing "topic" related registries over the years, such as a "Storage" registry for storage-related events. We certainly plan to continue this type of expansion. If there are areas that are of high value to you (and others), we can take that feedback to prioritize some of our work in this space.
|
|
|
|
Post by vincent0607 on Aug 16, 2022 16:26:32 GMT
We've certainly been publishing "topic" related registries over the years, such as a "Storage" registry for storage-related events. We certainly plan to continue this type of expansion. If there are areas that are of high value to you (and others), we can take that feedback to prioritize some of our work in this space. Thanks your feedback, not sure if it is good idea that in 'Base' message registry could move related Http part (such like Http status code and Http header) to itself registry? About related HTTP part, for example from 'Base' v1.13.0 as below * PayloadTooLarge (413 code) * PreconditionFailed (412 code) * PreconditionRequired (428 code) * OperationNotAllowed (405 code) * AccessDenied/ResourceAtUriUnauthorized (401 code) * ResourceCreationConflict/.../... (409 code) * InternalError (500 code) * InsufficientStorage (507 code) * Created (201 code) * HeaderMissing * HeaderInvalid ... |
|
|
|
Post by mraineri on Aug 16, 2022 17:25:38 GMT
The Base Message Registry is predominantly meant to convey error responses to client requests (so, not necessarily relevant to asynchronous events). Assuming your HTTP message usage is meant for error responses back to clients, it seems like your that category would fit as part of that registry. The mapping you've started looks pretty reasonable to me.
One thing to note is that most of the messages in the Base Message Registry augment information returned as part of a 400 status; messages are used to convey to the client what specifically about the request is bad (invalid properties, unsupported values for properties, bad data types, etc). We've added messages over time for other status codes for consistency in the message reporting back to a user so that a Redfish client since the "error" object with some sort of message is mandatory in responses with 4XX and 5XX status codes (otherwise OEM messages would need to be added for something seemingly standard).
|
|
|
|
Post by vincent0607 on Aug 17, 2022 1:59:49 GMT
thanks your detail explanation
not sure my understanding is correct, so you mean that in 'Base' registry it already included lots of HTTP status information (400, 4xx,5xx),
so it is not necessary to sperate to the part of messages (4xx, 5xx) to new DMTF registry, right?
|
|
|
|
Post by mraineri on Aug 17, 2022 12:54:08 GMT
That's correct. We want "Base" to be the bare minimum registry for clients to be able to handle responses from a service, which includes different types of HTTP statuses. It should be a fairly reliable registry for clients to code against for managing error responses from services. If there are gaps in the registry, we'd certainly like to know about them so we can extend it as needed.
|
|
