[core] Resource Directory vs RFC 6690

[Kovatsch, Matthias]

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

[Esko Dijk]

Dear Matthias, WG,

Indeed the query formats are currently defined differently for RFC 6690 (i.e. potentially very constrained CoAP server) and for draft-RD (i.e. typically a resource-rich CoAP server). That makes sense to me; and we do not want to inherit the very limited RFC 6690 behaviour of a single query parameter into the RD. The RD could benefit from more powerful query expressions using multiple query parameters, AND-ed together.

The interoperability problems could come when people try to send multi-parameter queries to /.well-known/core , the handling of which is currently not specified at all in RFC 6690. In fact this industry alliance wants to support multiple query parameters *both* for RD and /.well-known/core queries ;)

The above brings up the issue that RFC 6690 does not specify what to do with a multi-parameter query on /.well-known/core. Since it does not match the template exactly it's out of 6690 scope it would seem. Possible behaviors for a RFC 6690 compliant device, that supports the 1-parameter query only, are:


1. Return full resource list (device decides "I do not support this form of querying" and falls back to the "don't support querying" case in RFC 6690);
2. Return filtered list, only first parameter used (this is the "let's make the best of it, it looks roughly ok" approach);
3. Return an error (4.xx or 5.xx);
4. Suppress response (only possible for multicast request);
5. Undefined - up to implementation (this is the current state I believe)

This might be clarified as an erratum to RFC 6690. Option 2 looks good to in case there are additional query parameters i.e. the RFC6690 template with a multi-element list. Option 3 looks good in case the query does not match the template at all i.e. the server can't get a valid single query parameter out of it.

Regards
Esko

From: core [mailto:core-***@ietf.org] On Behalf Of Kovatsch, Matthias
Sent: Tuesday, April 11, 2017 13:06
To: ***@ietf.org
Subject: [core] Resource Directory vs RFC 6690

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


________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.

[Vicari, Norbert]

Dear Esko,

from an IoT communication point of view, I would expect that a device is able to determine that it cannot process a request correctly and thus will act accordingly, i.e. option 3 or 4.

best
Norbert




From: core [mailto:core-***@ietf.org] On Behalf Of Esko Dijk
Sent: Montag, 18. September 2017 17:18
To: Kovatsch, Matthias (CT RDA NEC EMB-DE); ***@ietf.org
Subject: Re: [core] Resource Directory vs RFC 6690

Dear Matthias, WG,

Indeed the query formats are currently defined differently for RFC 6690 (i.e. potentially very constrained CoAP server) and for draft-RD (i.e. typically a resource-rich CoAP server). That makes sense to me; and we do not want to inherit the very limited RFC 6690 behaviour of a single query parameter into the RD. The RD could benefit from more powerful query expressions using multiple query parameters, AND-ed together.

The interoperability problems could come when people try to send multi-parameter queries to /.well-known/core , the handling of which is currently not specified at all in RFC 6690. In fact this industry alliance wants to support multiple query parameters *both* for RD and /.well-known/core queries ;)

The above brings up the issue that RFC 6690 does not specify what to do with a multi-parameter query on /.well-known/core. Since it does not match the template exactly it's out of 6690 scope it would seem. Possible behaviors for a RFC 6690 compliant device, that supports the 1-parameter query only, are:


1. Return full resource list (device decides "I do not support this form of querying" and falls back to the "don't support querying" case in RFC 6690);
2. Return filtered list, only first parameter used (this is the "let's make the best of it, it looks roughly ok" approach);
3. Return an error (4.xx or 5.xx);
4. Suppress response (only possible for multicast request);
5. Undefined - up to implementation (this is the current state I believe)

This might be clarified as an erratum to RFC 6690. Option 2 looks good to in case there are additional query parameters i.e. the RFC6690 template with a multi-element list. Option 3 looks good in case the query does not match the template at all i.e. the server can't get a valid single query parameter out of it.

Regards
Esko

From: core [mailto:core-***@ietf.org] On Behalf Of Kovatsch, Matthias
Sent: Tuesday, April 11, 2017 13:06
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [core] Resource Directory vs RFC 6690

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


________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.

[Esko Dijk]

Hello Norbert

After some thought - what you suggest could be even the preferred approach, to make sure that either one of the below situations can be reliably detected by a client:


1. The multi-parameter query went ok at the server (so the link-format response is correct - only fully matching query results sent back)


1. The multi-parameter query was detected but not executed at the server (so, an error response - no non-matching query results are sent back)


1. The query component was ignored, since the target server does not support querying as per RFC 6690 (so the link format response contains all resources)


The case 3 should be more easily detectable by a client than the case of "query results are almost correct, but not quite".

Also agree that in multicast case, a server can just suppress the response in case it has nothing useful to return - as per RFC 7252 / 6690.

I propose to file an erratum on RFC 6690 requesting for more detail on how to handle the case of 'malformed queries' and queries with too many parameters; and suggest the error response as appropriate.

Esko

From: Vicari, Norbert [mailto:***@siemens.com]
Sent: Monday, September 18, 2017 17:30
To: Esko Dijk <***@philips.com>; Kovatsch, Matthias <***@siemens.com>; ***@ietf.org
Subject: RE: Resource Directory vs RFC 6690

Dear Esko,

from an IoT communication point of view, I would expect that a device is able to determine that it cannot process a request correctly and thus will act accordingly, i.e. option 3 or 4.

best
Norbert




From: core [mailto:core-***@ietf.org] On Behalf Of Esko Dijk
Sent: Montag, 18. September 2017 17:18
To: Kovatsch, Matthias (CT RDA NEC EMB-DE); ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [core] Resource Directory vs RFC 6690

Dear Matthias, WG,

Indeed the query formats are currently defined differently for RFC 6690 (i.e. potentially very constrained CoAP server) and for draft-RD (i.e. typically a resource-rich CoAP server). That makes sense to me; and we do not want to inherit the very limited RFC 6690 behaviour of a single query parameter into the RD. The RD could benefit from more powerful query expressions using multiple query parameters, AND-ed together.

The interoperability problems could come when people try to send multi-parameter queries to /.well-known/core , the handling of which is currently not specified at all in RFC 6690. In fact this industry alliance wants to support multiple query parameters *both* for RD and /.well-known/core queries ;)

The above brings up the issue that RFC 6690 does not specify what to do with a multi-parameter query on /.well-known/core. Since it does not match the template exactly it's out of 6690 scope it would seem. Possible behaviors for a RFC 6690 compliant device, that supports the 1-parameter query only, are:


1. Return full resource list (device decides "I do not support this form of querying" and falls back to the "don't support querying" case in RFC 6690);
2. Return filtered list, only first parameter used (this is the "let's make the best of it, it looks roughly ok" approach);
3. Return an error (4.xx or 5.xx);
4. Suppress response (only possible for multicast request);
5. Undefined - up to implementation (this is the current state I believe)

This might be clarified as an erratum to RFC 6690. Option 2 looks good to in case there are additional query parameters i.e. the RFC6690 template with a multi-element list. Option 3 looks good in case the query does not match the template at all i.e. the server can't get a valid single query parameter out of it.

Regards
Esko

From: core [mailto:core-***@ietf.org] On Behalf Of Kovatsch, Matthias
Sent: Tuesday, April 11, 2017 13:06
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [core] Resource Directory vs RFC 6690

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


________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.

________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.

[Carsten Bormann]

Post by Esko Dijk
file an erratum on RFC 6690

The errata process is not really suited for technical enhancements like this.

We may indeed want to capture RFC 6690 issues at one place (there are some other issues that may come up as a result of 5988bis/RFC8228-to-be). I’m not sure this must lead to a formal 6690bis effort right now, but ultimately that will be something we will have to do.

Grüße, Carsten