Subject: [core] Uri Query Option

From: Guido Moritz <[email-masked]>
Date: Wed, 27 Oct 2010 10:17:23 +0200

Dear WG,

the draft-ietf-core-coap-03 specifies in section 3.2.4: Uri-Query Option
MUST be supported by all end-points

But in draft-ietf-core-link-format-01 section 3.1, a server MAY implement
this feature

Is this a contradiction or am I wrong at some point?

BRGDs,
Guido

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Oct 2010 10:49:38 +0200

Uri-Query is for encoding the query-part of a URI, see section 3.4 of RFC 3986.
URI queries are a feature that is not just used in link-format.

I think the language "MUST support" in 3.2.4 may be a bit misleading, because a node need not actually support any URIs that indeed have a query, so sending back a 404 on anything that has an option 15 is one form of "support".

The intention is certainly not to require support of the link-format's discovery query filtering by all nodes -- that is indeed the reason the link-format draft says MAY.

Gruesse, Carsten

---

From: Guido Moritz <[email-masked]>
Date: Wed, 27 Oct 2010 11:23:33 +0200

> URI queries are a feature that is not just used in link-format.
Agreed.

> 
> I think the language "MUST support" in 3.2.4 may be a bit misleading,
> because a node need not actually support any URIs that indeed have a
> query, so sending back a 404 on anything that has an option 15 is one form
of
> "support".
Indeed, not having a resource in the arsenal which fits the query causes a
404. But the "MUST support" requires the server to act somehow on the query
and not simply ignore it and send an error.

> 
> The intention is certainly not to require support of the link-format's
discovery
> query filtering by all nodes -- that is indeed the reason the link-format
draft
> says MAY.
I don't have implemented CoAP, but when the query "filtering" described in
coap-03 MUST be supported (despite the according resource might not exist or
the query does not fit to be applied to the resource), why can't this "query
filtering" be reused for the discovery query filtering?

So it might not be a contradiction, but somehow misleading...

> Gruesse, Carsten
RGDs,
Guido

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Oct 2010 12:39:43 +0200

> and not simply ignore it and send an error.

No, requiring every server to implement at least one URI with a query-part is not the intention, and that's why I said the language may be misleading.

The "support" required is approximately

if (option_number == 15) {
  ack_with(404);
  return;
}

We can discuss whether that is too much of a burden and returning a parameter problem (602 == 242 in CoAP's base 10-4 representation) would be sufficient.

> coap-03

coap-03 does not define any filtering.
It provides a syntactic way to transport a query-part of a URI.
Nothing in coap-03 assigns any semantics to this syntactic element, so no support of any specific semantics can be required from that alone.
link-format-01 assigns semantics to the query-part for /.well-known/core only.  
And implementing those is optional.

switch(option) {
	...
	case 15: break; /* ignore option */
	...
}

is probably the minimal implementation that is most appropriate here.

Gruesse, Carsten