Original text:
address, potentially followed by a transport layer port number, are usually used in the authority component for the "http" and "coap" schemes.  The path and query contain data to identify a resource <del> within the scope of the URI's scheme and naming authority.  The path is hierarchical; the query is non-hierarchical.  The fragment allows to refer to some portion of the resource, such as a section in an HTML document. </del>  For RESTful IoT applications, typical schemes include "https", "coaps", "http", and "coap".  These refer to HTTP and CoAP, with and example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the response).  Query parameters in PUT and POST requests do not have <del> such established semantics and are not commonly used. </del>  3.5. 5. The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero <del> Kauppinen, and Michael Koster for the reviews and feedback. </del> 

Reviewer comments:
Removed "path is hierarchical query not" comment. Added note about query component order being unspecified.
This addresses issue
URL
Fixed in PR Hi, In reading draft-keranen-t2trg-rest-iot-01 I note the following: It is my understanding that this statement is subject to debate. Certainly some RESTful APIs assign hierarchical semantics to the path. For example, /foo may refer to a "collection-style" resource and /foo/bar may refer to a resource within that collection. However, is this a necessary requirement? From my perspective, this could potentially limit extensibility as future revisions of a RESTful API may, for instance, wish to insert a resource "between" /foo and /foo/bar. If the resources themselves are truly self-describing, containing links to "subordinate" resources, then the path portion of the URI can become an opaque identifier and backward compatibility in this hypothetical RESTful API could be maintained. Likewise, I have seen RESTful APIs where the order of the elements in the query portion of the URI matters (particularly if a given element occurs multiple times). I would suggest staying silent on the semantics of these parts of the URI or noting that they MAY be hierarchical / non-hierarchical. Thanks, Robby

Revised text:
address, potentially followed by a transport layer port number, are usually used in the authority component for the "http" and "coap" schemes.  The path and query contain data to identify a resource  <ins> within the scope of the URI's scheme and naming authority.  The fragment allows to refer to some portion of the resource, such as a section in an HTML document. </ins> For RESTful IoT applications, typical schemes include "https", "coaps", "http", and "coap".  These refer to HTTP and CoAP, with and example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the response).  Query parameters in PUT and POST requests do not have  <ins> such established semantics and are not commonly used.  Whether the order of the query parameters matters in URIs is unspecified and they can be re-ordered e.g., by proxies.  Therefore applications should not rely on their order; see Section 3.3 of RFC6943 for more details. </ins> 3.5. 5. The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero  <ins> Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, and Dave Thaler for the reviews and feedback. </ins>