I wrote:

I think we need to understand why this text:

 A missing dynamic property is defined to be the same as a dynamic property with value null.

is only present in the section “Set a Value to null”.

Is it also intended that that same text would apply to the request payload of entity-level (not property-level) POST and PUT requests?

Would a server be considered spec-compliant if it responds to a missing value by generating a non-null default, and responds to a null value by having no value at all?

—

then Ralf wrote:

I think there’s no corresponding text in the sections for Create (POST) and Replace (PUT) because the text would have to differentiate between client-defined (“open”) dynamic properties and server-defined (“hidden”) dynamic properties.

For client-defined dynamic properties the same statement is obviously valid for Create: the server does not know that property, the client does not state its value, so it is completely unknown to the server.

For client-defined dynamic properties and Replace there’s the edge case that the property had been sent in a previous request and has a known value for the server. Here the server can decide to
1. Completely forget that this dynamic property ever existed
2. Keep a trace that this property once existed and now doesn’t have a value
3. Something else I wouldn’t think of

For server-defined dynamic properties the behavior can be server-specific and even vary between different “hidden” properties: no value, implicit default value, explicitly stored default value – that’s completely up to the server.