jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-problem-details

Commentary: This is a minimal change to address the observation in the IANA comments .
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.
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).
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.
This specification defines a new sub-registry for Custom Problem
Detail Keys in the CoRE Parameters registry IANA.core-parameters,
with the policy "expert review" (RFC8126).
Draft: draft-ietf-core-problem-details

Commentary: LGTM , thank you !
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 shapes of these data items 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 the vocabulary defined here).  This pattern of
communication is illustrated in fig-problem-details.
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 "shapes" of these data items 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 the vocabulary defined here).  This pattern of
communication is illustrated in fig-problem-details.
Draft: draft-ietf-core-problem-details

Commentary: ... section and  's observations about privacy considerations . 
 it !
Problem details may unintentionally disclose information.  This can
lead to both privacy and security problems.  See seccons for more
details that apply to both domains; particular attention needs to be
given to unintentionally disclosing Personally Identifiable
Information (PII).
The security and privacy considerations outlined in Section 5 of
RFC7807 apply in full.
The security and privacy considerations outlined in Section 5 of
RFC7807 apply in full.  While these are phrased in terms of security
considerations for new RFC 7807 problem types, they equally apply to
the problem detail entry definitions used here sec-new-attributes; in
summary: both when defining new detail entries, and when actually
generating a Concise Problem Details data item, care needs to be
taken that they do not leak sensitive information.  Entities storing
or forwarding Concise Problem Details data items need to consider
whether this leads to information being transferred out of the
context within which access to sensitive information was acceptable.
See also ignore-unknown (the last paragraph of the introduction to
that section).  Privacy-sensitive information in the problem details
SHOULD NOT be obscured in ways that might lead to misclassification
as non-sensitive (e.g., by base64-encoding).
Draft: draft-ietf-core-problem-details

Commentary: Capture the discussion in the 2022 - 06 - 08 interim and . 
 Comment by : 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 would n'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 : context if available 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
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.
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.  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).
Draft: draft-ietf-core-problem-details

Commentary: Start collecting changes from AD review 
 Comment by : 
 See : The danger that people are just blindly copying an example is just too high . So we would prefer to keep this redundant comment in . We could improve the wording of the comment . 
 Comment by : Please explicitly state that the example ( or examples if you add one in ) uses CBOR diagnostic notation . 
 Fixed in . 
 Closed by
The terminology from RFC7252 and STD94 applies.  Readers are also
expected to be familiar with the terminology from RFC7807.
The terminology from RFC7252, STD94, and RFC8610 applies; in
particular CBOR diagnostic notation is defined in STD94 and RFC8610.
Readers are also expected to be familiar with the terminology from
RFC7807.
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.
fig-example-custom-with-uri shows an example (in CBOR diagnostic
notation) of a custom extension using a (made-up) URI as "custom-
problem-detail-entries" key.
Draft: draft-ietf-core-problem-details

Commentary: Couple of editorial suggestions based on WGLC review
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 shapes of these data items 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.
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 shapes of these data items 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 the vocabulary defined here), as shown in fig-problem-
details.
Note that, unlike RFC7807, Concise Problem Details data items have no
explicit "problem type".  Instead, the category (or, one could say,
Gestalt) of the problem can be understood from the shape of the
problem details offered, we talk of a "problem shape" for short.
Note that, unlike RFC7807, Concise Problem Details data items have no
explicit "problem type".  Instead, the category (or, one could say,
Gestalt) of the problem can be understood from the shape of the
problem details offered.  We talk of a "problem shape" for short.
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).
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 (under control of the entity
defining this extension), or an unsigned integer.  Only the latter
needs to be registered (iana-cpdk).