Fragment identifiers in CoAP URIs

[ektrah]

Errata ID: 4946 Type: Technical Reported By: Klaus Hartke Date Reported: 2017-02-22

Section 6.1 says/should say:

 coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]
+               [ "#" fragment ]

The optional fragment component allows for indirect identification of a secondary resource, as defined in Section 3.5 of RFC 3986. The fragment identifier is separated from the rest of the URI prior to a dereference; fragment identifiers are processed client-side and are not included in CoAP requests. The original text shows the syntax of coap:// URIs after separating the fragment identifier, which leaves ambiguity as to whether fragment identifiers are supported or not. The corrected text shows the syntax of CoAP URIs before separating the fragment identifier, which makes clear that fragment identifiers are supported.

---

Errata ID: 4947 Type: Technical Reported By: Klaus Hartke Date Reported: 2017-02-22

Section 6.2 says/should say:

 coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty
-               [ "?" query ]
+               [ "?" query ] [ "#" fragment ]

The optional fragment component allows for indirect identification of a secondary resource, as defined in Section 3.5 of RFC 3986. The fragment identifier is separated from the rest of the URI prior to a dereference; fragment identifiers are processed client-side and are not included in CoAP requests. The original text shows the syntax of coaps:// URIs after separating the fragment identifier, which leaves ambiguity as to whether fragment identifiers are supported or not. The corrected text shows the syntax of CoAP URIs before separating the fragment identifier, which makes clear that fragment identifiers are supported.

[cabo]

There has been a lot of confusion about this issue, not just for CoAP. RFC 3986 Section 4.3 says that individual schemes do not define fragment identifier syntax. This probably should be a clarification because of the ongoing confusion.