Re: [core] CoAP's handling of trailing slash in URI - to file erratum?

[Klaus Hartke <[e-mail]>]

Esko Dijk wrote:
> one would like to encode the below two CoAP URIs as separate CoAP requests
> because the two are in principle semantically different:
>
>   Example #1:  coap://host.example.com/path
>   Example #2:  coap://host.example.com/path/
> [...]
> The Example #1 URI will be encoded with a single Uri-Path option containing
> 4 bytes "path".
>
> The #2 URI should be encoded with two Uri-Path options, one containing
> "path" and a second one of zero bytes.

This is the correct behavior.

Section 3.3 of RFC 3986 [1] defines the path component of a URI as a
sequence of (possibly empty) segments separated by a slash character:

      path-abempty  = *( "/" segment )
      path-absolute = "/" [ segment-nz *( "/" segment ) ]
      path-noscheme = segment-nz-nc *( "/" segment )
      path-rootless = segment-nz *( "/" segment )
      path-empty    = 0<pchar>

As the ABNF shows, there are two segments in Example #2 ("path" and
"") and segments do not include the slash character. RFC 7252 Section
6.4 step 8 tries to make that double clear by saying "let that
option's value be the segment (not including the delimiting slash
characters)".

So I don't think that RFC 7252 is wrong. Of course, there is always
room for improvement of the text.

Klaus

[1] https://tools.ietf.org/html/rfc3986#section-3.3