2.2. <del> Both the client and the server MUST send a Capability and Settings </del>  message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise provided by CoAP over UDP.  The Type (T) and Message ID fields in the CoAP message header are elided. <del> The Version (Vers) field is elided as well.  In constrast to the UDP message layer for UDP and DTLS, the CoAP over TCP message layer does not send a version number in each message.  If required in the future, a new Capability and Settings Option (see negotiation) could be defined to support version negotiation. </del>  In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP Signaling messages are introduced to allow peers to: <del> Share characteristics such as maximum message size for the </del>  connection <del> Shutdown the connection in an ordered fashion </del>  <del> Terminate the connection in response to a serious error condition </del>  Signaling is a third basic kind of message in CoAP, after requests and responses.  Signaling messages share a common structure with the 4.1. <del> A code in the 7.01-7.31 range indicates a Signaling message.  Values </del>  in this range are assigned by the "CoAP Signaling Codes" sub-registry (see message-codes). For each message, there is a sender and a peer receiving the message. <del> Payloads in Signaling messages are diagnostic payloads (see </del>  Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling message option. 4.3. <del> Capability and Settings messages (CSM) are used for two purposes: </del>  Each capability option advertises one capability of the sender to the recipient. Setting options indicate a setting that will be applied by the sender. <del> A Capability and Settings message MUST be sent by both endpoints at the start of the connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. </del>  <del> Both capability and settings options are cumulative.  A Capability and Settings message does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no-operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if needed. </del>  Base values are listed below for CSM Options.  These are the values <del> for the Capability and Setting before any Capability and Settings </del>  messages send a modified value. These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty <del> Capability and Settings message would result in the option being set to its default value. </del>  <del> Capability and Settings messages are indicated by the 7.01 code </del>  (CSM). 4.3.1. the maximum message size in bytes that it can receive. As per Section 4.6 of RFC7252, the base value (and the value used <del> when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability. </del>  4.3.3. A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown.  The <del> details are in the options.  A diagnostic payload MAY be included.  A peer will normally respond to a Release message by closing the TCP/ TLS connection.  Messages may be in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </del>  Release messages are indicated by the 7.04 code (Release). release.  The sender shuts down the connection immediately after the abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload <del> SHOULD be included in the Abort message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </del>  Abort messages are indicated by the 7.05 code (Abort). TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over <del> TLS connection that does not meet this requirement (see sec-abort) and SHOULD include a diagnostic payload. </del>  The TLS usage guidance in RFC7925 SHOULD be followed.

One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.

2.2.  <ins> Both the client and the server MUST send a Capabilities and Settings </ins> message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise provided by CoAP over UDP.  The Type (T) and Message ID fields in the CoAP message header are elided.  <ins> The Version (Vers) field is elided as well.  In contrast to the message format of CoAP over UDP, the message format for CoAP over TCP does not include a version number.  CoAP is defined in RFC7252 with a version number of 1.  At this time, there is no known reason to support version numbers different from 1.  If version negotiation needs to be addressed in the future, then Capabilities and Settings Messages (CSM see csm) have been specifically designed to enable such a potential feature. </ins> In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP Signaling messages are introduced to allow peers to:  <ins> Related characteristics such as maximum message size for the </ins> connection  <ins> Shut down the connection in an orderly fashion </ins>  <ins> Provide diagnostic information when terminating a connection in response to a serious error condition </ins> Signaling is a third basic kind of message in CoAP, after requests and responses.  Signaling messages share a common structure with the 4.1.  <ins> A code in the 7.00-7.31 range indicates a Signaling message.  Values </ins> in this range are assigned by the "CoAP Signaling Codes" sub-registry (see message-codes). For each message, there is a sender and a peer receiving the message.  <ins> Payloads in Signaling messages are diagnostic payloads as defined in </ins> Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling message option. 4.3.  <ins> Capabilities and Settings messages (CSM) are used for two purposes: </ins> Each capability option advertises one capability of the sender to the recipient. Setting options indicate a setting that will be applied by the sender.  <ins> One CSM MUST be sent by both endpoints at the start of the connection.  Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. </ins>  <ins> Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no- operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if needed. </ins> Base values are listed below for CSM Options.  These are the values  <ins> for the capability and setting before any Capabilities and Settings </ins> messages send a modified value. These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty  <ins> Capabilities and Settings message would result in the option being set to its default value. </ins>  <ins> Capabilities and Settings messages are indicated by the 7.01 code </ins> (CSM). 4.3.1. the maximum message size in bytes that it can receive. As per Section 4.6 of RFC7252, the base value (and the value used  <ins> when this option is not implemented) is 1152. </ins> 4.3.3. A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown.  The  <ins> details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </ins> Release messages are indicated by the 7.04 code (Release). release.  The sender shuts down the connection immediately after the abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload  <ins> (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </ins> Abort messages are indicated by the 7.05 code (Abort). TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over  <ins> TLS connection that does not meet this requirement (see sec-abort). </ins> The TLS usage guidance in RFC7925 SHOULD be followed.


8.2. <del> IANA is requested to create a sub-registry for signaling options similar to the CoAP Option Numbers Registry (Section 12.2 of RFC7252), with the single change that a fourth column is added to the sub-registry that is one of the codes in the Signaling Codes subregistry (message-codes). The name of this sub-registry is "CoAP Signaling Option Numbers". </del>  Initial entries in this sub-registry are as follows:

URL The table 2 below isn't correct as it includes names not the signal codes from Table 1
URL Cl.8.2: I wonder if the first column in Table 3 should be "Applies to"? It seems more natural to look up the Signal Code to find the option, instead of the options which could have the same number.
URL 8.2. CoAP Signaling Option Numbers Registry s/one/one or more/

8.2.  <ins> IANA is requested to create a sub-registry for Options Numbers used in CoAP signaling options within the "CoRE Parameters" registry.  The name of this sub-registry is "CoAP Signaling Option Numbers". Each entry in the sub-registry must include one or more of the codes in the Signaling Codes subregistry (message-codes), the option number, the name of the option, and a reference to the option's documentation. </ins> Initial entries in this sub-registry are as follows:


Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets  transports. 1. namely TCP RFC0793, in some situations secured by TLS RFC5246. In addition, some corporate networks only allow Internet access via a <del> HTTP proxy.  In this case, the best transport for CoAP would be the </del>  RFC6455.  The WebSocket protocol provides two-way communication between a client and a server after upgrading an RFC7230 connection and may be available in an environment that blocks CoAP over UDP. intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should.
URL Appendix A. Updates to RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) This needs to be referenced from the main body in some form.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets <ins> transports.  It also formally updates RFC7641 for use with these </ins> transports. 1. namely TCP RFC0793, in some situations secured by TLS RFC5246. In addition, some corporate networks only allow Internet access via a  <ins> HTTP proxy.  In this case, the best transport for CoAP might be the </ins> RFC6455.  The WebSocket protocol provides two-way communication between a client and a server after upgrading an RFC7230 connection and may be available in an environment that blocks CoAP over UDP. intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. <ins> observing updates RFC7641 for use with CoAP over reliable transports. RFC7641 is an extension to the CoAP core protocol that enables CoAP clients to "observe" a resource on a CoAP server.  (The client retrieves a representation of a resource and registers to be notified by the server when the representation is updated.) </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


The payload of a CoAP message that is affected by a BERT Option in descriptive usage (Section 2.1 of RFC7959).  2. The request/response interaction model of CoAP over TCP is the same

And changed Len to Len=0 for websocket message format in Figure 14.
URL Figure 4: CoAP frame with 8-bit Extended Length field. This (and neither does the text) does not make clear that the payload marker is sent only if there is a non-zero-length payload. (Same for other below.) Please cf. text from Section 3 of RFC 7252: Figure 14: CoAP Message Format over WebSockets Maybe show 0, not Len here. (This also does not make clear that the payload marker is sent only if there is a non-zero-length payload.)
It's a bit awkward to insert text about the Payload Marker, since other fields are not re-introduced from RFC7252. In RFC8030, we used the Conventions and Terminology section to also provide more context for examples based on feedback from the reviewers. One possibility is to use a similar approach here and indicate that all framing examples have the Payload Marker set. And of course, the "(if any)" would need to be removed. And then there's still the need to clarify the WS case due to the requirement to set the Len to 0 and rely on the WS frame.

The payload of a CoAP message that is affected by a BERT Option in descriptive usage (Section 2.1 of RFC7959). <ins> For simplicity, a Payload Marker (0xFF) is present in all examples for message formats: The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see section 3 of RFC7252). </ins> 2. The request/response interaction model of CoAP over TCP is the same


in the namespace of the CoAP server.  When the WebSocket protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket <del> endpoint.  This means it is necessary for the client to identify both the WebSocket endpoint (identified by a "ws" or "wss" URI) and the path and query of the CoAP resource within that endpoint from the same URI.  When the WebSocket protocol is used from a web page, the choices are more limited RFC6454, but the challenge persists. uris defines a new "coap+ws" URI scheme that identifies both a WebSocket endpoint and a resource within that endpoint as follows: </del>  Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint.  Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (arch-2), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint.  The client specifies the resource <del> to be updated or retrieved in the Proxy-URI Option. </del>  A third possible configuration is a CoAP server running inside a web browser (arch-3).  The web browser initially connects to a WebSocket 6. <del> CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource. </del>  <del> 6.1. </del>  <del> CoAP over TCP uses the "coap+tcp" URI scheme.  CoAP over TLS uses the "coaps+tcp" scheme.  The rules from Section 6 of RFC7252 apply to both of these URI schemes. </del>  Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes. <del> Resources made available via one of the "coap+tcp" or "coaps+tcp" schemes have no shared identity with the other scheme or with the "coap" or "coaps" scheme, even if their resource identifiers indicate the same authority (the same host listening to the same port).  The schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers. </del>  <del> 6.1.1. </del>  <del> The semantics defined in Section 6.1 of RFC7252 apply to this URI scheme, with the following changes: </del>  The port subcomponent indicates the TCP port at which the CoAP server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.) <del> 6.1.2. </del>  <del> The semantics defined in Section 6.2 of RFC7252 apply to this URI </del>  scheme, with the following changes: The port subcomponent indicates the TCP port at which the TLS given, then the default port 443 is assumed (this is different from the default port for "coaps", i.e., CoAP over DTLS over UDP). <del> If a server does not support the Application-Layer Protocol Negotiation Extension (ALPN) RFC7301 or wishes to accommodate </del>  clients that do not support ALPN, it MAY offer a coaps+tcp endpoint on TCP port 5684.  This endpoint MAY also be ALPN <del> enabled.  A server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled. </del>  <del> For TCP ports other than port 5684, the client MUST use the ALPN extension to advertise the "coap" protocol identifier (see alpnpid) in the list of protocols in its ClientHello.  If the </del>  server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection <del> succeeds.  If the server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the client MUST close the connection. </del>  <del> For TCP port 5684, a client MAY use the ALPN extension to </del>  advertise the "coap" protocol identifier in the list of protocols <del> in its ClientHello.  If the server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds.  If the server returns a no_application_protocol alert, then the client MUST close the connection.  If the server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected. </del>  <del> For TCP port 5684, if the client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected. </del>  <del> 6.2. </del>  <del> For the first configuration discussed in websockets-overview, this document defines two new URIs schemes that can be used for identifying CoAP resources and providing a means of locating these resources: "coap+ws" and "coap+wss". </del>  <del> Similar to the "coap" and "coaps" schemes, the "coap+ws" and "coap+wss" schemes organize resources hierarchically under a CoAP origin server.  The key difference is that the server is potentially reachable on a WebSocket endpoint instead of a UDP endpoint. </del>  <del> The WebSocket endpoint is identified by a "ws" or "wss" URI that is composed of the authority part of the "coap+ws" or "coap+wss" URI, respectively, and the well-known path "/.well-known/coap" RFC5785. The path and query parts of a "coap+ws" or "coap+wss" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </del>  <del> The syntax of the "coap+ws" and "coap+wss" URI schemes is specified below in Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty" and "query" are the same as in RFC3986. </del>  <del> The port component is OPTIONAL; the default for "coap+ws" is port 80, while the default for "coap+wss" is port 443. </del>  <del> Fragment identifiers are not part of the request URI and thus MUST NOT be transmitted in a WebSocket handshake or in the URI options of a CoAP request. </del>  <del> 6.2.1. </del>  <del> The steps for decomposing a "coap+ws" or "coap+wss" URI into CoAP options are the same as specified in Section 6.4 of RFC7252 with the following changes: </del>  <del> The <scheme> component MUST be "coap+ws" or "coap+wss" when converted to ASCII lowercase. </del>  <del> A Uri-Host Option MUST only be included in a request when the <host> component does not equal the uri-host component in the Host header field in the WebSocket handshake. </del>  <del> A Uri-Port Option MUST only be included in a request if |port| does not equal the port component in the Host header field in the WebSocket handshake. </del>  <del> The steps to construct a URI from a request's options are changed accordingly. </del>  7. 9.5. <del> This document registers two new URI schemes, namely "coap+tcp" and "coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over TCP, respectively.  The "coap+tcp" and "coaps+tcp" URI schemes can thus be compared to the "http" and "https" URI schemes. The syntax of the "coap" and "coaps" URI schemes is specified in Section 6 of RFC7252 and the present document re-uses their semantics for "coap+tcp" and "coaps+tcp", respectively, with the exception that TCP, or TLS over TCP is used as a transport protocol. IANA is requested to add these new URI schemes to the registry established with RFC7595. </del>  9.5.1. <del> This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+ws".  The registration request complies with RFC7595. </del>  <del> coap+ws </del>  Permanent <del> Defined in Section N of [RFCthis] </del>  <del> The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket protocol. </del>  <del> The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. </del>  <del> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. </del>  <del> None. </del>  <del> See Section N of [RFCthis] </del>  IETF chair <chair@ietf.org> IESG <iesg@ietf.org> <del> [RFCthis] </del>  <del> 9.5.2. </del>  <del> This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+wss".  The registration request complies with RFC7595. </del>  <del> coap+wss </del>  Permanent <del> Defined in Section N of [RFCthis] </del>  <del> The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket protocol secured with Transport Layer Security (TLS). </del>  <del> The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. </del>  <del> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. </del>  <del> None. </del>  <del> See Section N of [RFCthis] </del>  IETF chair <chair@ietf.org> IESG <iesg@ietf.org> <del> [RFCthis] </del>  9.6. [RFCthis]

URL Ensure that all "Section N" references are updated.
URL Cl.8.5: I think it would be easier for IANA if the coaps+tcp and coap+tcp URI schemes were described like the websockets ones in 8.5.1 and 8.5.2. This is another case with a heavy dependency on RFC7252 references.
URL We need to fill in the template.
URL s/are potentially accessible/are intended to be accessible/ [Editor] Same language is used for coap+wss. [Editor] Ironically, "potentially accessible" was copied from CoAP Classic - RFC7252. ~
URL Cl.6.2: This indicates ABNF is used for the definitions. However clause 6.1.1 and 6.1.2 make no mention of the ABNF syntax or reference to RFC3986. The descriptions of the definitions of the URI schemes in 6.2, 6.1.1 and 6.1.2 should be harmonised. This could be more consistent. Currently, coap+tcp and coaps+tcp rely on references to coap and coaps in RFC7252: The semantics defined in [RFC7252], Section 6.1, apply to this URI scheme, with the following changes and require that the reader is also familiar with URL The syntax of the "coap" and "coaps" URI schemes is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query", "segment", "IP-literal", "IPv4address", and "reg-name" are adopted from [RFC3986].
Additional feedback - URL CoAP URIs In this section, the terms "client" and "server" are used WRT the TCP connection, not WRT CoAP, and that may be very confusing. Maybe use different terms here (initiator/responder)? [Note from editor] - The terms are used in the coaps+tcp section on ALPN. Since there are already references to ClientHello and ServerHello perhaps it could be clarified with "TCP client" and "TCP server"? 6.1. CoAP over TCP and TLS URIs Not sure this belongs here, but it also should apply to 6.2, so maybe move it up to 6. Ditto. s/potentially reachable/intended to be reached/ The following paragraph applies to 6.1.1, 6.1.2, and this subsection. (Move up to 6.) (They can't be in a CoAP request; not sure what the MUST NOT means. But again, this also applies to the TCP/TLS case.) 6.2.1. Decomposing and Composing URIs Wrong use of MUST. (MUST it be included or is this a MUST NOT if equal?) Ditto.
The outline for the URI scheme definitions needs to follow the guidance in URL which now requires:

in the namespace of the CoAP server.  When the WebSocket protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket  <ins> endpoint. coap-ws-scheme and coaps-ws-scheme define new URI schemes that enable the client to identify both a WebSocket endpoint and the path and query of the CoAP resource within that endpoint.  When the WebSocket protocol is used from a web page, the choices are more limited RFC6454, but the challenge persists. </ins> Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint.  Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (arch-2), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint.  The client specifies the resource  <ins> to be updated or retrieved in the Proxy-Uri Option. </ins> A third possible configuration is a CoAP server running inside a web browser (arch-3).  The web browser initially connects to a WebSocket 6.  <ins> CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes. This document introduces four additional URI schemes for identifying CoAP resources and providing a means of locating the resource: </ins>  <ins> the "coap+tcp" URI scheme for CoAP over TCP the "coaps+tcp" URI scheme for CoAP over TCP secured by TLS the "coap+ws" URI scheme for CoAP over WebSockets the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS </ins>  <ins> Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the same host listening to the same TCP port).  They are distinct namespaces and are considered to be distinct origin servers. 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. </ins> Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes.  <ins> 6.1. </ins>  <ins> The "coap+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP. </ins>  <ins> The syntax defined in Section 6.1 of RFC7252 applies to this URI scheme with the following changes: </ins> The port subcomponent indicates the TCP port at which the CoAP server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.)  <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. </ins>  <ins> None. See Section 11.1 of RFC7252. 6.2. The "coaps+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP secured with TLS. The syntax defined in Section 6.2 of RFC7252 applies to this URI </ins> scheme, with the following changes: The port subcomponent indicates the TCP port at which the TLS given, then the default port 443 is assumed (this is different from the default port for "coaps", i.e., CoAP over DTLS over UDP).  <ins> If a TCP server does not support the Application-Layer Protocol Negotiation Extension (ALPN) RFC7301 or wishes to accommodate TCP </ins> clients that do not support ALPN, it MAY offer a coaps+tcp endpoint on TCP port 5684.  This endpoint MAY also be ALPN  <ins> enabled.  A TCP server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled. </ins>  <ins> For TCP ports other than port 5684, the TCP client MUST use the ALPN extension to advertise the "coap" protocol identifier (see alpnpid) in the list of protocols in its ClientHello.  If the TCP </ins> server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection  <ins> succeeds.  If the TCP server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the TCP client MUST close the connection. </ins>  <ins> For TCP port 5684, a TCP client MAY use the ALPN extension to </ins> advertise the "coap" protocol identifier in the list of protocols  <ins> in its ClientHello.  If the TCP server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds.  If the TCP server returns a no_application_protocol alert, then the TCP client MUST close the connection.  If the TCP server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected. </ins>  <ins> For TCP port 5684, if the TCP client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected. </ins>  <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. </ins>  <ins> See Section 11.1 of RFC7252. </ins>  <ins> 6.3. </ins>  <ins> The "coap+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets. </ins>  <ins> The port component is OPTIONAL.  The default is port 80. </ins>  <ins> The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path "/.well-known/coap" RFC5785.  The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </ins>  <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. See Section 11.1 of RFC7252. 6.4. </ins>  <ins> The "coaps+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets secured by TLS. </ins>  <ins> The port component is OPTIONAL.  The default is port 443. The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path "/.well-known/coap" RFC5785.  The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. </ins>  <ins> See Section 11.1 of RFC7252. </ins>  <ins> 6.5. </ins>  <ins> The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: </ins>  <ins> If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws" then fail this algorithm. If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. 6.6. The steps are the same as specified in Section 6.5 of RFC7252 with the following changes: For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://".  Otherwise, let |url| be the string "coap+tcp://".  For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://".  Otherwise, let |url| be the string "coap+ws://". If the request includes a Uri-Port Option, let |port| be that option's value.  Otherwise, let |port| be the request's destination TCP port. </ins> 7. 9.5.  <ins> URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [1]. </ins> 9.5.1.  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coap+tcp".  This registration request complies with RFC7595. </ins>  <ins> coap+tcp </ins> Permanent  <ins> The scheme is used by CoAP endpoints to access CoAP resources using TCP. </ins>  <ins> IETF chair <chair@ietf.org> </ins>  <ins> IESG <iesg@ietf.org> </ins>  <ins> coap-tcp-scheme in [RFCthis] 9.5.2. </ins>  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coaps+tcp".  This registration request complies with RFC7595. </ins>  <ins> coaps+tcp Permanent The scheme is used by CoAP endpoints to access CoAP resources using TLS. </ins> IETF chair <chair@ietf.org> IESG <iesg@ietf.org>  <ins> coaps-tcp-scheme in [RFCthis] </ins>  <ins> 9.5.3. </ins>  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coap+ws".  This registration request complies with RFC7595. </ins>  <ins> coap+ws </ins> Permanent  <ins> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. </ins>  <ins> IETF chair <chair@ietf.org> </ins>  <ins> IESG <iesg@ietf.org> </ins>  <ins> coap-ws-scheme in [RFCthis] 9.5.4. </ins>  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coaps+ws".  This registration request complies with RFC7595. coaps+ws </ins>  <ins> Permanent The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. </ins> IETF chair <chair@ietf.org> IESG <iesg@ietf.org>  <ins> coaps-ws-scheme in [RFCthis] </ins> 9.6. [RFCthis] <ins> 10.  References 10.1.  URIs [1] http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml </ins>


1.1. <del> The data model derives from the Web Linking model of RFC8288 and consists primarily of two elements: "links" that describe the relationship between two resources and the type of that relationship; and "forms" that describe a possible operation on a resource and the type of that operation. The data model can additionally make simple statements about resources in a way similar to the W3C.REC-rdf11-concepts-20140225. In contrast to RDF, however, the focus of CoRAL is not on the description of a graph of resources, but on the discovery of possible future application states. </del>  The interaction model derives from the processing model of W3C.REC- html52-20171214 and specifies how an automated software agent can

State a formal information model, and distinguish between the sea-of-triple-ish and the ordered-and-treeified structured data. I'll need to do some more polishing, but this is the rough form of what I'd like to try the various applications out with.
Thanks for the comments, and even more for sending them quickly. There are several stages of normalization; what I'd like to highlight here is that of the 4 steps on the comparison ladder (RFC3986 Section ), precisely this particular step should be taken. This might easily be said better somewhere else, and hopefully CRIs will turn out in a way that they are always in syntax based form, and thus the practical comparison is for identity. It is, but treating them by value is not. The canonocal example is two resources being labelled "Gift", but one is { "Gift" :lang :en } meaning present, and one { "Gift" :lang :de } meaning "present. It definitely needs much better phrasing -- or do you think the mechanism should be different too? What I meant writing this down is that if you have a bag of things and want to turn them into a mathematical (should have stressed that) set, there needs to be an equivalence relation that deduplicates items in the set. Same for the (mathematical) graph: items need identity to wind up as the identical node. I've written much of this in mental "math mode" (and it doesn't help that all the courses I did on basic maths were in German, so there might be translation errors too); in final ID form, this wil need different language. I've understood many practical concerns to necessitate a sequence on the items -- if the application should try items in a sequence, that sequence needs to be part of the information model at some point. There is no generic criterion, the ordering is just part of the additional information that the structured model carries and the general does not; clarified "structure (including the order)" below. "oriented" is a word I missed, making it explicit ("ordered oriented tree"). Yes, taken in. Is this a question in "why would you do that" (belonging to the rationale) or "what kind of tree allows that" (which means that I may need to pick a better word than the "ordered oriented tree" and have to resist the urge to hardcode it in even more unreadable set definitions)? (also see next comment). That's what you get from the odd tree above -- each time a node is entered, a different choice of picking a subtree can be made. That's what we get from expressing the tree acr^Wover the graph as a CBOR tree that may visit a node multiple times. If, of course, we choose to take the serialization avenue where such things are forbidden (and a multiply visited node must always come from the dictionary), then all the worries of these multi-ish trees go away. I'm very open to exploring that, it's just that AFAIR we haven't been there yet; all the proposals I remember on how to treat multiply visited nodes always had some optionality to using them. Taken in. What I'm trying to say is that if the serialization somehow manages to use the identical CBOR object again, it could easily manage to express that. The current serialization format can't do that (noted in the text for the time being), but if (for example) we were to cherry-pick the web linking feature of using multiple rel values in the same link, then a serializer could express a literal with multiple ingress edges, provided they all come from the same node and the serializer groups them together so that in the end the CBOR object is only in the document once. We'll find one in time. (This is so WIP that I don't expect much of the line-by-line text to make it to an uploaded ID, trying to hammer out the concepts first and slowly gathering phrases). That necessitated making "blank node" a term of CoRAL, but the change set in which I'm applying this contains such a change now.
Sorry for replying so late, I just realised this mega reply existed -- I don't know why I didn't receive an email notification from Github :-( I have to say bundling all comments and replies together makes replying a pretty hard task though. Maybe it'd be easier to use the threading that comes for free in the UI -- i.e., on each individual comments. Ah OK, I hadn't realised syntax-based is what you were aiming at here. Maybe s/syntax/syntax-based/ and a ref to the right place in the URI spec would dissolve any potential confusion.
Sorry for that -- they arrived at my mailbox in that format, and only later I realized that in the GitHub GUI they show as different threads. Good point, taken for update.
Action items for me before merging this: The term I've been looking for was probably DAG with ordering of the edges. [edit: it's not, because that doesn't encode when we go down which branch] (It may make sense to mention somewhere in there the possibility that subsets of statements and ontologies limit expresitivity to the point where there can only be one tree through the graph). Example of both versions of literals [edit: "Gift" -(lang)-> "de", -(direction)-> LTR vs. "Gift"NAME in the information model] with RDF mapping (with CBOR w/ cri"" extension as diagnostic format). Spell out dictionary mapping CBOR back and forth to XSD? (Might be moved to different issue that rebuilds RDF mapping based on this) Maybe point out things varying in serialization that are not even part of the structured thing (but still may be profiled), like absolute vs relative URs
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).
Thanks! I've left a few comments.

1.1.  <ins> 1.1.1. The is similar to the W3C.REC-rdf11-concepts-20140225 information model: Data is expressed as an (unordered) set of triples (also called statements), consisting of a subject, a predicate and an object.  The predicate is always a URI, and subject and object are each either a URI, or a concrete CBOR object (a literal).  All URIs here are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the edge.  That graph is equivalent to the data. To form a set and a graph, we define an equivalence relation: URIs are only equal to URIs and if they are identical byte-wise.  Literals carry an identity from their serialization format (think of it as the file and cursor position from which it was read - but if cbor-packed is involved it's more like the stack of cursors at parsing time), and are only equivalent to themselves.  Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. The is a sequence of "passings" the basic model's edges, where each edge is passed at least one time in total, each edge is passed at most one time after each passing that ends in its start point (with the obvious exception that edges from the root node can be passed once from the start), and between a passing of an edge from A to B and a later passing from B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. The passings starts at the root node, defined as the URI from which the document is obtained. For better understanding, think of the structured information model as a sort of tree spanning from the root node, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. 1.1.2. The structured form of a data set is in general not unique: If a node has more than one child, their sequence can be varied.  If a node has more than one parent, its children may be expressed on any non-empty set of its parents to obtain a structured data set that expresses the same data set. In general, arbitrary basic data can not be expressed in a structured data set, because There may not be a tree that covers the directed graph, or the tree's root may not be the URI from which the document is obtained. There may be multiple edges into a literal, and the serialization can not build a file where these are expressed at the same spot (which the current serialization can not do at all). In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements can be added to make a data set that is expressible elsewhere, and subsets of the data can be taken and expressed. Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization formats (which have more efficient notations for them), and are used by the interaction model for special operations. The structured information model contains more information than the basic information model.  [ TBD put this into a different context because it's not an observation any more: ] Which precise structure is picked is to suit the processing application, typically by profiling the information and its serialization.  It is recommended that the information encoded in the structure (including the order) be derived from data available in the general data set, even though the statements that guide the structure are not necessarily encoded in the subset of data that is being structured. Serializations like the one in binary have even more choices than the structured information model: They can choose to use or not use packed CBOR to compress parts, can spell out URIs in full or use relative references, or can exercise freedoms of the CBOR encoding. Variation there is not to have an influence on the interpretation of a CoRAL document. 1.1.3. Each URI is tagged with whether it is intended to be dereferenced or used as an identifier. Equivalence of literals over CBOR packing could be revisited; literals could gain an identity from all their outgoing trees being identical.  (But that'd need an exception for Null literals).  It might help to explicitly limit these sub-trees. Alternatively, literals in the model could be replaced with this, and be disallowed in the subject position: Literals can have properties in addition to their literal (CBOR) value.  These properties are expressed in key-value pairs very similar to statements about the literal in that the keys are URIs, the values URIs or literals, and keys can occur multiple times. (In serializations like binary, they are expressed exactly the same).  However, unlike statements, these properties of the literal and (transitively) part of the literal's identity, and are always expressed completely in the structured information model. If this model is adopted, literals obtain their identity from being identical in value and all properties in an unordered comparison.  "null" values need to be excluded from literals, as they need to retain the instance-of-their-own semantics. 1.1.4. This subsection illustrates the information model and serialization based on an example from RFC6690: After an extraction (currently not defined in this document), this list represents the content of the basic information model representing the above.  For the basic model, the table is to be considered unsorted in the first step. During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data preserves some sequence aspects of the Link-Format file (like the order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved. For serialization, a (so far unspecified) packing was picked, resulting in a binary CBOR file with this CBOR diagnostic notation: Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of reg-name style and thus would be registered as CoRE Parameters, and be included in the packing as well. 1.1.4.1. To illustrate the handling options for literals, a link example of RFC8288 is converted. (Note that even the conversion scheme hinted at above for RFC6690 link format makes no claims at being applicable to general purpose web links like the below; this is merely done to demonstrate how literals can be handled.  The example even so happens well illustrate that point: General link attributes may only be valid on the target when the link is followed in that direction ("letztes Kapitel" means last chapter), whereas convertible link-format documents use titles that apply to the described resource independent of which link is currently being followed.) In the currently described model, the extracted data would be: If the alternative literals-with-properties approach were chosen, the extraction would produce: In CBOR serialization, both would produce the same output: 1.1.5. </ins> The interaction model derives from the processing model of W3C.REC- html52-20171214 and specifies how an automated software agent can


2.3.  A describes a relationship between two resources on the Web.  As in This section defines the encoding of documents in the CoRAL binary format. <del> A document in the binary format is encoded in RFC8949.  The encoding MUST satisfy the Core Deterministic Encoding Requirements specified in RFC8949. </del>  The CBOR structure of a document is presented in the RFC8610.  All CDDL rules not defined in this document are defined in RFC8610.

The requirement was probably a left-over from when CRIs where specified in here; the current document has no use for the properties obtainable from this. Closes: URL
The current text says: I think this is a remnant from when CoRAL and CRI were a single document; I don't see any reason to prescribe this for CoRAL. Any objections to removing that?

2.3. <ins> [ TBD move information model in here ] </ins> A describes a relationship between two resources on the Web.  As in This section defines the encoding of documents in the CoRAL binary format.  <ins> A document in the binary format is encoded in RFC8949. </ins> The CBOR structure of a document is presented in the RFC8610.  All CDDL rules not defined in this document are defined in RFC8610.


is similar to the W3C.REC-rdf11-concepts-20140225 information model: Data is expressed as an (unordered) set of triples (also called statements), consisting of a subject, a predicate and an object.  The <del> predicate is always a URI, and subject and object are each either a URI, or a concrete CBOR object (a literal).  All URIs here are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. </del>  These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the edge.  That graph is equivalent to the data. To form a set and a graph, we define an equivalence relation: URIs <del> are only equal to URIs and if they are identical byte-wise.  Literals carry an identity from their serialization format (think of it as the file and cursor position from which it was read - but if cbor-packed is involved it's more like the stack of cursors at parsing time), and are only equivalent to themselves.  Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. </del>  The B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. <del> The passings starts at the root node, defined as the URI from which the document is obtained. </del>  For better understanding, think of the structured information model as a sort of tree spanning from the root node, with the oddity that tree's root may not be the URI from which the document is obtained. <del> There may be multiple edges into a literal, and the serialization can not build a file where these are expressed at the same spot (which the current serialization can not do at all). </del>  In particular, the precise data from one structured information <del> document can only be expressed at the same URI.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries- information-about" predicate being usable here), and subsets of the data can be taken and expressed. Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. </del>  Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization Each URI is tagged with whether it is intended to be dereferenced or used as an identifier. <del> Equivalence of literals over CBOR packing could be revisited; literals could gain an identity from all their outgoing trees being identical.  (But that'd need an exception for Null literals).  It might help to explicitly limit these sub-trees. Alternatively, literals in the model could be replaced with this, and be disallowed in the subject position: Literals can have properties in addition to their literal (CBOR) value.  These properties are expressed in key-value pairs very similar to statements about the literal in that the keys are URIs, the values URIs or literals, and keys can occur multiple times. (In serializations like binary, they are expressed exactly the same).  However, unlike statements, these properties of the literal and (transitively) part of the literal's identity, and are always expressed completely in the structured information model. If this model is adopted, literals obtain their identity from being identical in value and all properties in an unordered comparison.  "null" values need to be excluded from literals, as they need to retain the instance-of-their-own semantics. </del> 1.1.4. This subsection illustrates the information model and serialization 1.1.4.1. <del> To illustrate the handling options for literals, a link example of RFC8288 is converted. </del>  (Note that even the conversion scheme hinted at above for RFC6690 link format makes no claims at being applicable to general purpose that apply to the described resource independent of which link is currently being followed.) <del> In the currently described model, the extracted data would be: </del>  <del> If the alternative literals-with-properties approach were chosen, the extraction would produce: </del>  <del> In CBOR serialization, both would produce the same output: </del>  1.1.5.

Closes: URL In the comments there's the question of whether we need that properties of literals that are literals themselves can have properties again. Right now it does no harm, but no good either; I have no use case that's not completely contrived, and the number of properties we can round-trip through RDF is quite limited anyway.
I think we should pick the information model variation where literals can't have arbitrary outgoing statements, but only properties (that happen to be serialized just like other statements). Allowing nested statements from literals is kinda nice conceptually, but it is hard to explain (as it requires all the "blank node" explanations over again) is impractical in conversions is hard to visualize correctly Realistically, literals can have a type (if they're string-form; for everything else conversion can be guided by tags) or a language (which AIU is also a type these days when considering LTR/RTL). We might also see things like content format (for embedded representations), but if we want to carry them over to RDF, we can't do the literal attributes anyway, and I think we don't need to (because we now also have 's tags for content formats and can thus easily tag things inside CBOR). Are there any arguments we should have in an issue beforehand? Otherwise I'd start a pull request at my next CoRAL session.
While writing this up, I stumbled over which CBOR data model to pick for equivalence. Making literals identical to each other if they are identical in the CBOR generic data model seems the right thing to do (as opposed to going into the extended data model), as it is easier and stable. I think that we (or applications) can still define additional equivalences later on.

is similar to the W3C.REC-rdf11-concepts-20140225 information model: Data is expressed as an (unordered) set of triples (also called statements), consisting of a subject, a predicate and an object.  The  <ins> predicate is always a URI, the subject is a URI or a blank node, and the object is either a URI, a blank node or a litreal.  All URIs here are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. Blank nodes are unnamed entities.  Literals are non-null CBOR objects that may have a set of properties (e.g. a language tag) attached to them; properties have a (not necessarily unique) URI as their name and a URI or literal as their value. </ins> These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the edge.  That graph is equivalent to the data. To form a set and a graph, we define an equivalence relation: URIs  <ins> are only equal to URIs and if they are identical byte-wise.  A blank node is only equal to itself.  A literal is equal to a different literal if its value is equal to another literal's value in the CBOR generic data model, and have the same set of properties. Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. </ins> The B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing.  <ins> The passings starts at the root node, usually defined as the URI from which the document is obtained. </ins> For better understanding, think of the structured information model as a sort of tree spanning from the root node, with the oddity that tree's root may not be the URI from which the document is obtained.  <ins> There may be multiple edges into a blank node. </ins> In particular, the precise data from one structured information  <ins> document can only be expressed with the same root node.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries-information-about" predicate being usable here), and subsets of the data can be taken and expressed. Literals with properties behave similar to blank nodes (where their properties resemble statements from a blank node) - so similar that they are serialized precisely like that.  The difference is that properties are part of the literal's identity.  The structured model does not add structure to properties. </ins> Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization Each URI is tagged with whether it is intended to be dereferenced or used as an identifier.  1.1.4. This subsection illustrates the information model and serialization 1.1.4.1.  <ins> To illustrate properties of literals, a link example of RFC8288 is converted. </ins> (Note that even the conversion scheme hinted at above for RFC6690 link format makes no claims at being applicable to general purpose that apply to the described resource independent of which link is currently being followed.)  <ins> The model this would be converted to is: </ins>  <ins> | Subject | Predicate | Object | |------+-------+-----+ | http://.../ | rel:previous | http://.../TheBook/chapter2 | | http://.../TheBook/chapter2 | linkformat:title | "letztes Kapitel" with xml:lang "de" | {: #fig-8288-data-properties title='Information model extracted from fig-8288-orig'} </ins>  <ins> In CBOR serialization, this produces: </ins> 1.1.5.


The <del> is a sequence of "passings" the basic model's edges, where </del>  each edge is passed at least one time in total, each edge is passed at most one time after each passing that ends in its start point (with the obvious exception that edges from the <del> root node can be passed once from the start), and </del>  between a passing of an edge from A to B and a later passing from B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. <del> The passings starts at the root node, usually defined as the URI from which the document is obtained. </del> For better understanding, think of the structured information model <del> as a sort of tree spanning from the root node, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. </del>  1.1.2. data set, because There may not be a tree that covers the directed graph, or the <del> tree's root may not be the URI from which the document is obtained. </del>  There may be multiple edges into a blank node. In particular, the precise data from one structured information <del> document can only be expressed with the same root node.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the </del>  "http://www.iana.org/assignments/relation/carries-information-about" predicate being usable here), and subsets of the data can be taken and expressed.

Closes: URL This builds on
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).

The  <ins> is a sequence of "passings" of the basic model's edges, starting at a node identifying the document (its retrieval context, typically URI from which it was obtained) where </ins> each edge is passed at least one time in total, each edge is passed at most one time after each passing that ends in its start point (with the obvious exception that edges from the  <ins> retrieval context can be passed once from the start), and </ins> between a passing of an edge from A to B and a later passing from B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing.  For better understanding, think of the structured information model  <ins> as a sort of tree spanning from the retrieval context, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. </ins> 1.1.2. data set, because There may not be a tree that covers the directed graph, or the  <ins> tree's root may not be the retrieval context. </ins> There may be multiple edges into a blank node. In particular, the precise data from one structured information  <ins> document can only be expressed with the same retrieval context. However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries- information-about" relation type leading to the </ins> "http://www.iana.org/assignments/relation/carries-information-about" predicate being usable here), and subsets of the data can be taken and expressed.


In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements <del> can be added to make a data set that is expressible elsewhere, and subsets of the data can be taken and expressed. </del>  Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. This subsection illustrates the information model and serialization based on an example from RFC6690: <del> After an extraction (currently not defined in this document), this list represents the content of the basic information model representing the above.  For the basic model, the table is to be considered unsorted in the first step. </del>  During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved. <del> For serialization, a (so far unspecified) packing was picked, resulting in a binary CBOR file with this CBOR diagnostic notation: </del>  Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of

As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).

In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements  <ins> can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries- information-about" predicate being usable here), and subsets of the data can be taken and expressed. </ins> Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. This subsection illustrates the information model and serialization based on an example from RFC6690:  <ins> After an extraction described in convert-6690, this list represents the content of the basic information model representing the above. For the basic model, the table is to be considered unsorted in the first step. </ins> During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved.  <ins> For serialization, the use of the packing described with the conversion results in a binary CBOR file with this CBOR diagnostic notation: [ TBD: Numbers are made up ] </ins> Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of


are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. <del> Blank nodes are unnamed entities.  Literals are non-null CBOR objects that may have a set of properties (e.g. a language tag) attached to them; properties have a (not necessarily unique) URI as their name and a URI or literal as their value. </del>  These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the To form a set and a graph, we define an equivalence relation: URIs are only equal to URIs and if they are identical byte-wise.  A blank node is only equal to itself.  A literal is equal to a different <del> literal if its value is equal to another literal's value in the CBOR generic data model, and have the same set of properties. </del>  Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. predicate being usable here), and subsets of the data can be taken and expressed. <del> Literals with properties behave similar to blank nodes (where their properties resemble statements from a blank node) - so similar that they are serialized precisely like that.  The difference is that properties are part of the literal's identity.  The structured model does not add structure to properties. </del> Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization formats (which have more efficient notations for them), and are used 1.1.4.1. <del> To illustrate properties of literals, a link example of RFC8288 is </del>  converted. (Note that even the conversion scheme hinted at above for RFC6690 5.5. Text strings can be associated with a RFC5646 and a base text <del> direction (right-to-left or left-to-right) by nesting links of types <http://coreapps.org/base#language> and <http://coreapps.org/ base#direction>, respectively: </del>  <del> The link relation types <http://coreapps.org/base#language> and <http://coreapps.org/base#direction> are defined in core-vocabulary. </del>  5.6.

With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.

are limited to the syntax-based normalized form of RFC3986 Section 6.2.2.  <ins> Blank nodes are unnamed entities.  Literals are CBOR objects. </ins> These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the To form a set and a graph, we define an equivalence relation: URIs are only equal to URIs and if they are identical byte-wise.  A blank node is only equal to itself.  A literal is equal to a different  <ins> literal if its value is equal to the other literal's value in the CBOR generic data model. </ins> Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. predicate being usable here), and subsets of the data can be taken and expressed.  Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization formats (which have more efficient notations for them), and are used 1.1.4.1.  <ins> To illustrate non-trivial literals, a link example of RFC8288 is </ins> converted. (Note that even the conversion scheme hinted at above for RFC6690 5.5. Text strings can be associated with a RFC5646 and a base text  <ins> direction (right-to-left or left-to-right) by using CBOR tag 38. </ins>  <ins> [ Maturity note: Whether direction will actually be expressed in an updated tag 38, how precisely that is done, or whether a new tag will be allocated for text with direction is currently still under discussion. ] </ins> 5.6.


3.2. A document in the binary format MAY reference values from an external <del> dictionary.  This helps to reduce representation size and processing cost.  Dictionary references can be used in place of link relation types, link targets, operation types, submission targets, form field types, and form field values. </del>  <del> 3.2.1. A dictionary reference is encoded as an unsigned integer.  Where a dictionary reference cannot be expressed unambiguously, the unsigned integer is tagged with CBOR tag TBD6, as follows: </del>  <del> A dictionary reference MUST NOT refer to a dictionary value that would otherwise not be syntactically allowed in that position.  For example, a dictionary reference in the position of a link relation type cannot refer to a Boolean value; it can only refer to an IRI. </del>  <del> 3.2.2. </del>  The "application/coral+cbor" media type for documents in the binary format is defined to have a "dictionary" parameter that specifies the

This replaces the previous mechanism of having bespoke dictionaries with Packed CBOR. Other places in the text still talk of "dictionaries", but that's not necessarily wrong, it's a term even used occasionally in packed.

3.2. A document in the binary format MAY reference values from an external  <ins> dictionary using Packed CBOR I-D.ietf-cbor-packed.  This helps to reduce representation size and processing cost. </ins>  <ins> Dictionary references can be used subject to [ yet to be defined ] profiling. </ins>  <ins> Implementers should note that Packed CBOR is not designed to be uncompressed, but to be used in a compressed form.  In particular, constrained devices may operate without even knowing what a given dictionary entry expands to (as long as they know its meaning) . </ins>  <ins> 3.2.1. </ins> The "application/coral+cbor" media type for documents in the binary format is defined to have a "dictionary" parameter that specifies the


2. <del> A CoAP Problem Details is a CoRAL document with the following </del>  elements: "type" (id) - The problem type.  This is a mandatory element. Consumers MUST use "type" as primary identifiers for the problem type; the "title" string is advisory and included only for consumers <del> who are not aware of the semantics of the "type" value. </del>  The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information. 3.  Problem type definitions MAY extend the Problem Details document with additional elements to convey additional, problem-specific information. they do not recognize; this allows problem types to evolve and include additional information in the future. <del> 3.1. </del>  The example in fig-example-ext-full has all the basic elements as well as an additional, type-specific element. <del> 4. </del>  Problem Details for CoAP APIs are serialized in the CoRAL binary format.  See Section 11 of RFC7252 for security considerations The security and privacy considerations outlined in Section 5 of RFC7807 apply in full. <del> 5. </del>  TODO.

Note that this PR sits on top of
CoAP Response Codes are an optional feature and should be discussed in a separate section. Rationale for the feature The CoAP response-code is already carried by the CoAP header, so it doesn't make sense adding it to the PD payload that goes from Server to Client. It does however make sense for a Client that is about to ingest the received PD into a log pipeline to "enrich" it with ancillary Information from the underlying CoAP transaction. In this context, response-code is probably the most basic attribute that one wants to carry over as it is also commonly used as a high-level partition key for log visualisation.
addressed by
We should provide a default set of ready-to-use PD types associated with the existing CoAP status codes, intended for carrying (and enriching) the associated status code semantics. The (rough) plan is to define an “about:coap” namespace with one PD type for each registered . An application could use such PDs without the need to register anything. Just pick the "right" type and populate the relevant fields, job done. As a nice side-effect, this would allow exercising the registration procedure, including the definition of the PD type's registry structure and providing a first set of registrations.

2.  <ins> A CoRE Problem Details is a CoRAL document with the following </ins> elements: "type" (id) - The problem type.  This is a mandatory element. Consumers MUST use "type" as primary identifiers for the problem type; the "title" string is advisory and included only for consumers  <ins> who are not aware of the semantics of the "type" value.  An initial set of "type"s and corresponding "title"s is defined in sec-response- code-types. </ins> The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information. 3. <ins> This document defines an initial set of Problem Detail types that match the corresponding CoAP response codes in the 4.xx (client error) and 5.xx (server error) space.  See tbl-response-code-types. When using one such problem type, an application MUST make sure that the type matches the CoAP response code in the underlying CoAP transaction. If a title element is used in the Problem Details payload, it SHOULD be populated with the title corresponding to the type. The types defined in this document reflect the state of the relevant portion of the "CoAP Codes" registry at the time of writing. 4. In the following sections we introduce specific (albeit "common enough") use cases, and define the extensions to the basic format needed to support them. 4.1. Consumers of Problem Details might be located at the far end of a logging and analytics pipeline.  For example, this might be the case when a CoAP server or CoAP API gateway is located in an edge gateway node and forwards its logs to a cloud collector, which in turn aggregates a potentially huge number of different servers and transactions (see fig-log-pipeline). It is quite common in a situation like the above that an already deployed server is temporarily put in "tracing mode" to diagnose a failure.  In this case having a separate channel for the tracing info provides a superior solution (in terms of ease of ingesting and processing) to overloading the "detail" field and having to write ad- hoc filtering logics to extract the relevant information from it. Cost-wise, the producer would not incur any added overhead while, from the transport perspective, the slight increase in bandwidth to support the extra structuring is typically dwarfed by the (verbose) content of the diagnostic payload.  The same mechanism would also be useful during the development and test of a new application, giving the developer insight into the internal state of the application. The additional protocol element is: "diag" (text) - a string.  It may contain anything of user's choice: extra information complementing the what already present in "detail", a stack trace, a distributed trace span ending in an error condition, etc. Leaking private or sensitive data SHOULD be avoided. 4.1.1. The example in fig-example-diag-stack has a "diag" element with a stack trace associated with the error condition. 5. </ins> Problem type definitions MAY extend the Problem Details document with additional elements to convey additional, problem-specific information. they do not recognize; this allows problem types to evolve and include additional information in the future.  <ins> 5.1. </ins> The example in fig-example-ext-full has all the basic elements as well as an additional, type-specific element.  <ins> 6. </ins> Problem Details for CoAP APIs are serialized in the CoRAL binary format.  See Section 11 of RFC7252 for security considerations The security and privacy considerations outlined in Section 5 of RFC7807 apply in full.  <ins> 7. </ins> TODO.


<del> Problem Details For CoAP APIs </del>  draft-ietf-core-problem-details-latest Abstract This document defines a "problem detail" as a way to carry machine- <del> readable details of errors in a CoAP response to avoid the need to define new error response formats for CoAP APIs.  The proposed format is inspired by the Problem Details for HTTP APIs defined in RFC 7807. </del>  1. <del> CoAP RFC7252 response codes are sometimes not sufficient to convey enough information about an error to be helpful.  This specification defines a simple and extensible CoRAL I-D.ietf-core-coral vocabulary to suit this purpose.  It is designed to be reused by CoAP APIs, which can identify distinct "problem types" specific to their needs. Thus, API clients can be informed of both the high-level error class (using the response code) and the finer-grained details of the problem (using this vocabulary), as shown in fig-problem-details. </del>  <del> The vocabulary presented is largely inspired by the Problem Details for HTTP APIs defined in RFC7807. </del>  1.1. 2. <del> A CoRE Problem Details is a CoRAL document with the following elements: </del>  <del> "type" (id) - The problem type.  This is a mandatory element. </del>  <del> "title" (text) - A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem. </del>  <del> "detail" (text) - A human-readable explanation specific to this occurrence of the problem. </del>  <del> "instance" (uri) - A URI reference that identifies the specific occurrence of the problem.  It may or may not yield further information if dereferenced. Consumers MUST use "type" as primary identifiers for the problem type; the "title" string is advisory and included only for consumers who are not aware of the semantics of the "type" value.  An initial set of "type"s and corresponding "title"s is defined in sec-response- code-types. </del>  The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information. prone ways to obtain such information. Note that the "instance" URI reference may be relative; this means <del> that it must be resolved relative to the document's base URI, as per I-D.ietf-core-coral. 2.1. This section presents a series of examples of the basic vocabulary in CoRAL textual format (Section 4 of I-D.ietf-core-coral).  The examples are fictitious.  No identification with actual products is intended or should be inferred.  All examples involve the same CoAP problem type with semantics of "unknown key id", defined in the fictitious namespace "http://vocabulary.private-api.example". Note that CoRAL documents are exchanged in CoRAL binary format (Section 3 of I-D.ietf-core-coral) in practice.  This includes the use of I-D.ietf-core-href as an alternative to URIs that is optimized for constrained nodes. The example in fig-example-minimalist has the most compact representation.  It avoids any non-mandatory element.  This is suitable for a constrained receiver that happens to have precise knowledge of the semantics associated with the "type". The example in fig-example-full-fledged has all the mandatory as well as the optional elements populated.  This format is appropriate for a less constrained receiver (for example, an edge gateway forwarding to a log server that needs to gather as much contextual information as possible, including the problem "headline", details about the error condition, and an error-specific instance URL). 3. This document defines an initial set of Problem Detail types that match the corresponding CoAP response codes in the 4.xx (client error) and 5.xx (server error) space.  See tbl-response-code-types. </del>  <del> When using one such problem type, an application MUST make sure that the type matches the CoAP response code in the underlying CoAP transaction. </del>  <del> If a title element is used in the Problem Details payload, it SHOULD be populated with the title corresponding to the type. </del>  <del> The types defined in this document reflect the state of the relevant portion of the "CoAP Codes" registry at the time of writing. </del>  4. <del> In the following sections we introduce specific (albeit "common enough") use cases, and define the extensions to the basic format needed to support them. 4.1. </del>  <del> Consumers of Problem Details might be located at the far end of a logging and analytics pipeline.  For example, this might be the case when a CoAP server or CoAP API gateway is located in an edge gateway node and forwards its logs to a cloud collector, which in turn aggregates a potentially huge number of different servers and transactions (see fig-log-pipeline). </del>  <del> It is quite common in a situation like the above that an already deployed server is temporarily put in "tracing mode" to diagnose a failure.  In this case having a separate channel for the tracing info provides a superior solution (in terms of ease of ingesting and processing) to overloading the "detail" field and having to write ad- hoc filtering logics to extract the relevant information from it. Cost-wise, the producer would not incur any added overhead while, from the transport perspective, the slight increase in bandwidth to support the extra structuring is typically dwarfed by the (verbose) content of the diagnostic payload.  The same mechanism would also be useful during the development and test of a new application, giving the developer insight into the internal state of the application. </del>  <del> The additional protocol element is: </del>  <del> "diag" (text) - a string.  It may contain anything of user's choice: extra information complementing the what already present in "detail", a stack trace, a distributed trace span ending in an error condition, etc. </del>  <del> Leaking private or sensitive data SHOULD be avoided. </del>  <del> 4.1.1. </del>  <del> The example in fig-example-diag-stack has a "diag" element with a stack trace associated with the error condition. </del>  <del> 5. </del>  <del> Problem type definitions MAY extend the Problem Details document with additional elements to convey additional, problem-specific information. </del>  <del> Clients consuming problem details MUST ignore any such elements that they do not recognize; this allows problem types to evolve and include additional information in the future. </del>  <del> 5.1. </del>  <del> The example in fig-example-ext-full has all the basic elements as well as an additional, type-specific element. </del>  <del> 6. </del>  <del> Problem Details for CoAP APIs are serialized in the CoRAL binary format.  See Section 11 of RFC7252 for security considerations relating to CoAP.  See Section 7 of I-D.ietf-core-coral for security considerations relating to CoRAL. </del>  <del> The security and privacy considerations outlined in Section 5 of RFC7807 apply in full. </del>  <del> 7. </del>  <del> TODO. </del>

This PR provides the write-up of the discussed at the interim. Note that it branches off Carsten's "bundled" PR ()
I did a little bit of editing. Comments welcome...

<ins> Concise Problem Details For CoAP APIs </ins> draft-ietf-core-problem-details-latest Abstract This document defines a "problem detail" as a way to carry machine-  <ins> readable details of errors in a REST response to avoid the need to define new error response formats for REST APIs.  The format is inspired by, but intended to be more concise than, the Problem Details for HTTP APIs defined in RFC 7807. </ins> 1.  <ins> REST response status information such as CoAP response codes (RFC7252) is sometimes not sufficient to convey enough information about an error to be helpful.  This specification defines a simple and extensible framework to define CBOR STD94 data items to suit this purpose.  It is designed to be reused by REST APIs, which can identify distinct "problem types" specific to their needs.  Thus, API clients can be informed of both the high-level error class (using the response code) and the finer-grained details of the problem (using this vocabulary), as shown in fig-problem-details. </ins>  <ins> The framework presented is largely inspired by the Problem Details for HTTP APIs defined in RFC7807.  comp7807 discusses applications where interworking with RFC7807 is required. </ins> 1.1. 2.  <ins> A Concise Problem Details data item is a CBOR data item with the following structure (notated in CDDL RFC8610): </ins>  <ins> A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, see new-spdk): </ins>  <ins> Note that, unlike RFC7807, Concise Problem Details data items have no explicit type. </ins>  <ins> Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38 for the definition of the latter. </ins>  <ins> The "title" string is advisory and included to give consumers a shorthand for the category of the error encountered. </ins> The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information. prone ways to obtain such information. Note that the "instance" URI reference may be relative; this means  <ins> that it must be resolved relative to the representation's base URI, as per STD66. </ins>  <ins> Note that the "response code" value is a numeric representation of the actual code, so it does not take the usual form that resembles an HTTP status code -- "4.04 Not found" is represented by the number 132. </ins>  <ins> 3. </ins>  <ins> This specification defines a generic problem type container with only a minimal set of attributes to make it usable. It is expected that applications will extend the base format by defining new attributes. These new attributes fall into two categories: generic and application specific. Generic attributes will be allocated in the "standard-problem-detail- entries" slot according to the registration procedure defined in new- spdk. Application-specific attributes will be allocated in the "custom- problem-detail-entries" slot according to the procedure described in new-cpdk. 3.1. Beyond the Standard Problem Detail keys defined in cddl, additional Standard Problem Detail keys can be registered for use in the "standard-problem-detail-entries" slot (see iana-spdk). Standard Problem Detail keys are negative integers, so they never can conflict with Custom Problem Detail keys defined for a specific application domain (which are unsigned integers or URIs.) In summary, the keys for Standard Problem Detail entries are in a global namespace that is not specific to a particular application domain. Consumers of a Concise Problem Details instance MUST ignore any Standard Problem Detail entries that they do not recognize; this allows problem details to evolve. 3.2. Applications may extend the Problem Details data item with additional entries to convey additional, application-specific information. Such new entries are allocated in the "custom-problem-detail-entries" slot, and carry a nested map specific to that application.  The map key can either be an (absolute!)  URI (controlled by the entity defining this extension), or an unsigned integer.  Only the latter needs to be registered (iana-cpdk). Within the nested map any number of attributes can be given for a single extension.  The semantics of each custom attribute MUST be described in the documentation for the extension; for extension that are registered (i.e., are identified by an unsigned int) that documentation goes along with the registration. The unsigned integer form allows a more compact representation, in exchange, authors are expected to comply with the required registration and documentation process.  In comparison, the URI form is less space-efficient but requires no registration.  It is therefore useful for experimenting during the development cycle and for applications deployed in environments where producers and consumers of Concise Problem Details are more tightly integrated. (The URI form thus covers the potential need we might otherwise have for a "private use" range for the unsigned integers.) Note that the URI given for the extension is for identification purposes only and, even if dereferenceable in principle, MUST NOT be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans). An example of a custom extension using a URI as "custom-problem- detail-entries" key is shown in fig-example-custom-with-uri. Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer key; the same example but using a registered unsigned int as "custom- problem-detail-entries" key is shown in fig-example-custom-with-uint. In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom Problem Detail entry, the documentation of which defines these internal entries, typically chosen to address a given application domain.  Consumers of a Concise Problem Details instance MUST ignore any Custom Problem Detail entries, or keys inside the Custom Problem Detail entries, that they do not recognize; this allows Custom Problem Detail entries to evolve and include additional information in the future. </ins> 4.  <ins> The security and privacy considerations outlined in Section 5 of RFC7807 apply in full. </ins>  <ins> 5. </ins>  <ins> 5.1. </ins>  <ins> This specification defines a new sub-registry for Standard Problem Detail Keys in the CoRE Parameters registry IANA.core-parameters, with the policy "specification required" RFC8126. </ins>  <ins> Each entry in the registry must include: </ins>  <ins> Initial entries in this sub-registry are as follows: </ins>  <ins> 5.2. </ins>  <ins> This specification defines a new sub-registry for Custom Problem Detail Keys in the CoRE Parameters registry IANA.core-parameters, with the policy "first come first served" RFC8126. </ins>  <ins> Each entry in the registry must include: </ins>  <ins> Initial entries in this sub-registry are as follows: </ins>  <ins> 5.3. </ins>  <ins> IANA is requested to add the following Media-Type to the "Media Types" registry IANA.media-types. </ins>  <ins> 5.4. </ins>  <ins> IANA is requested to register a Content-Format number in the IANA.core-parameters sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry IANA.core-parameters, as follows: </ins>  <ins> TBD1 is to be assigned from the space 256..999. </ins>  <ins> In the registry as defined by RFC7252 at the time of writing, the column "Content-Type" is called "Media type" and the column "Content Coding" is called "Encoding". </ins>  <ins> 5.5. </ins>  <ins> In the registry "IANA.cbor-tags" IANA.cbor-tags, IANA has registered CBOR Tag 38.  IANA is requested to replace the reference for this registration with tag38, RFC XXXX. </ins>


2. A Concise Problem Details data item is a CBOR data item with the <del> following structure: </del>  A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38 <del> for the definition of the latter. </del>  The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.

Capture the discussion in the 2022-06-08 interim and .
Comment by NAME : I have a hard time motivating why this can be unadorned CBOR text string, given that these two fields are always human-readable text. Maybe we need to add a default, i.e. that when text used, that is to be interpreted as English language is used.
(w/ TF:) making "foo" a shorthand for 38(["en", "foo", false]) makes sense in the Anglo-American dominated world we live in. Details (en? en-US?) need to be discussed though.
I wouldn't go down the rabbit hole of also picking the locale. Too much stress I'm happy with the minimum required to satisfy the rule, i.e., "en".
In we decided to go with the following: use context if available fall back to english Now, similar to , should we have a (and ) keys for when the CPD is stored/forwarded and therefore the context is lost?
LGTM

2. A Concise Problem Details data item is a CBOR data item with the  <ins> following structure (rules named starting with "tag38" are defined in tag38): </ins> A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38  <ins> for the definition of the latter.  Language tag and writing direction information for unadorned text strings are intended to be obtained from context; if that context needs to be saved or forwarded with a Concise Problem Details data item, "base-lang" and "base-rtl" can be used for that.  If no such (explicitly saved or implicit) context information is available, unadorned text is interpreted with language-tag "en" and writing-direction "false" (ltr). </ins> The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.