Draft: draft-ietf-core-coap-tcp-tls

Commentary: Do we need to include the  note for emphasis ? 
 Probably not , as we are not changing anything about 5.10.1 , are we ? ( But then 7.5 also points out a place where we maintain a property of 5.10.1 . ) ( ( But then , again , where would be put this ? ) ) 
 We need to identify the ABNF fragments as ABNF as in so they become easier to check in BAP . 
 We could add the note to Section 7 , right after the new reference to " fragment " : 
 Merged in abnf annotations from 
 is relevant to Section 7 . 
 Good point . So I assume applying the same fix ( add » [ " # " fragment ] « ) four times to the ABNF in 7.1 to 7.4 would fix that ? ( We probably want to line - break before path - abempty in all four cases . ) 
 If would be helpful to have more context for how the fragment identifier is used in CoAP . I do n't see much detail in  besides : Note : Fragments ( [ RFC3986 ] , Section 3.5 ) are not part of the request URI and thus will not be transmitted in a CoAP request . 
 Fragment identifiers are not used in a transfer protocol ; their use is a local matter on the client side . The mistake we made in RFC 7252 is providing ABNF that does n't show fragment identifiers at all in the URI syntax . While CoAP as a protocol does not care about them , they are intended to be allowed in CoAP URIs so they can indeed be used on the client side . The note mentions this , but the ABNF does not reflect that . Same for coap - tcp - tls . Does it matter ? The meaning of fragment identifiers is defined by the media type . So far , there has been little use of fragment identifiers in the media types being used with CoAP . Now , SenML actually does go ahead and defines a meaning for them , and other media types in the future might as well . So it would be good if the ABNF in the CoAP standards did not give the impression fragment identifiers can not be used at all with CoAP URIs . 
 Note from Carsten : We may have to reopen that issue based on the about - face that the HTTP WG made here : 
 From which references : Absolute URI Some protocol elements allow only the absolute form of a URI without a fragment identifier . For example , defining a base URI for later use by relative references calls for an absolute - URI syntax rule that does not allow a fragment . absolute - URI = scheme " : " hier - part [ " ? " query ] URI scheme specifications must define their own syntax so that all strings matching their scheme - specific syntax will also match the < absolute - URIgrammar . Scheme specifications will not define fragment identifier syntax or usage , regardless of its applicability to resources identifiable via that scheme , as fragment identification is orthogonal to scheme definition . However , scheme specifications are encouraged to include a wide range of examples , including examples that show use of the scheme 's URIs with fragment identifiers when such usage is appropriate . and further states : Requirements for Permanent Scheme Definitions This section gives considerations for new schemes . Meeting these guidelines is REQUIRED for ' permanent ' scheme registration . ' Permanent ' status is appropriate for , but not limited to , use in standards . For URI schemes defined or normatively referenced by IETF Standards Track documents , ' permanent ' registration status is REQUIRED . [ RFC3986 ] defines the overall syntax for URIs as : URI = scheme " : " hier - part [ " ? " query ] [ " # " fragment ] A scheme definition can not override the overall syntax for URIs . For example , this means that fragment identifiers can not be reused outside the generic syntax restrictions and that fragment identifiers are not scheme specific . A scheme definition must specify the scheme name and the syntax of the scheme - specific part , which is clarified as follows : URI = scheme " : " scheme - specific - part [ " # " fragment ] scheme - specific - part = hier - part [ " ? " query ]
The syntax for the URI schemes in this section are specified using
Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of
"host", "port", "path-abempty", and "query" are adopted from RFC3986.
The syntax for the URI schemes in this section are specified using
Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of
"host", "port", "path-abempty", "query", and "fragment" are adopted
from RFC3986.