Review of draft-ietf-core-conditional-attributes-10

[bsilverajan]

From https://mailarchive.ietf.org/arch/msg/core/JFK9bJOBiZfP_TNFgcWUMOWOf0c/

*Q4:*Is it correct to assume that Conditional Notification Attributes,
Conditional Control Attributes and other query parameters can be present
in the same query? Is there some order in the evaluation? maybe this
does not matter as all of them have to be valid anyways? For example,
the example below:

|REQ: GET
coap://coap.me:5683/sensor?precision=0.1&c.band&c.gt=30&c.con&|c.pmax=10

• |precision=0.1|: application specific, indicates precision of|0.1|.
• |c.gt=30|: This parameter sets a threshold, indicating that a
  notification should be triggered when the resource value exceeds 30.
• |c.band|: Modifier of|c.gt|parameter. It is alone so it sets an
  upper bound. We will get notifications that are less than 30.
• |c.con|: This parameter indicates that the notification must be
  confirmable, requiring an acknowledgment from the client.
• |c.pmax|: This parameter indicates that we should get notifications
  at least every 10 seconds.

[bsilverajan]

Yes multiple query parameters can be included in the same query (with or without Observe, obviously). However, when Observe is applied, do you recommend that all the query parameters provided in the request be registered or do we allow mixing with non-registered query parameters?

Both control and notification parameters are allowed, and there is no order in the evaluation: The server provides a response if any condition holds true. See Section 3.7 and Appendix A

[jaimejim]

OK so the topics here are:

• Attributes that can be present. It seems there is no order in the evaluation.
• Mixing observe query params and "normal" query params. Which should be OK.
• Mixing registered vs non-registered. Which, I think, should be OK too.

Maybe check too with the group?