[core] Resource Directory vs RFC 6690

["Kovatsch, Matthias" <[e-mail]>]

Dear list,
dear Michael

While talking with people from an industry alliance building their standard on CoAP, it came up that RD lookups need to support multiple query parameters with an AND conjunction. draft-ietf-core-resource-directory-10, Section 7 supports this:

        "Multiple query parameters MAY be included in a lookup"

It might be clearer to also mention the logical AND conjunction here.
The confusion for this requirement mainly arose from the Link Format RFC 6690, Section 4:

        "/.well-known/core{?search*}
         where the variable "search" is a 1-element list that has a single name/value pair"

The lookup on /.well-known/core only allows a single query parameter. This was decided to not demand too much query processing from constrained devices. The query feature is overall a MAY, that is, it might not be implemented at all. That means, also links that do not match the query could be returned.

This is in conflict with draft-ietf-core-resource-directory-10, Section 7, where it says further:

        "all included parameters MUST match for a resource to be returned."

I say conflict because we should have the principle of the least surprise. RD res-lookup and /.well-known/core are very similar. The latter could also offer the same filtering as RD based on the server's resource(=link) attributes.

Furthermore, I think the "MUST match" is inappropriate. It must be up to the client to select the correct link. Just compare it to Google, where besides irrelevant results also ads are included in the results and it is up to the user to decide which links to click on. While I fully understand that there is usually no user involved, it would make a more robust system, when the client has the responsibility to select the appropriate link and not blindly the first one because it trusts the MUST in a specification.

What do you think?
Should we file errata for RFC 6690 and fix this?
Did I miss updates from RFC 7252?

Ciao
Matthias