[OracleReview] 5.3.1.3 PropertyAffordance

[egekorkan]

• invalid combinations of op values: some combinations don't make sense and should be prohibited. Examples include observe+unobserve.
• observable: RFC2119 SHOULD assertion

[egekorkan]

My comment was:

Actually, exactly this makes sense. In MQTT, we have the default assumption that observing is subscribing and unobserving is unsubscribing on the same topic. Thus, in MQTT it would redundant to split the operations. This is also valid for events.

[benfrancis]

Actually, exactly this makes sense. In MQTT, we have the default assumption that observing is subscribing and unobserving is unsubscribing on the same topic. Thus, in MQTT it would redundant to split the operations. This is also valid for events.

This is also the case for Server-sent Events, where the same URL endpoint is implicitly used for both subscribing and unsubscribing (unsubscribing basically just involves closing the connection). See Example 22 in the HTTP SSE Profile.

[mlagally]

The current text for observable says:

A hint that indicates whether Servients hosting the Thing and Intermediaries should provide a Protocol Binding that supports the observeproperty and unobserveproperty operations for this Property.

This should become an RFC assertion.

[egekorkan]

Like I have said in a previous comment, all tables are assertive but we should probably capitalize this. See the implementation report screenshot below

[sebastiankb]

Combinations of op values heavily depends on the used (sub-)protocols. I think, it is hard find useful restriction that has not a potential impact of a specific protocol.

observable: RFC2119 SHOULD assertion

it is an assertion (see Ege's comment above). Also see my comment here:

#1600 (comment)

Propose to close this issue.

[sebastiankb]

from today's TD call, decided to close

@mlagally please reopen, if you disagree