jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: Thanks .
If an extension member (see extension) occurs in the Problem field,
its name MUST be compatible with the syntax of Dictionary keys (see
{Section 3.2 of STRUCTURED-FIELDS}}) and the defining problem type
MUST specify a Structured Type to serialize the value into.
If an extension member (see extension) occurs in the Problem field,
its name MUST be compatible with the syntax of Dictionary keys (see
Section 3.2 of STRUCTURED-FIELDS) and the defining problem type MUST
specify a Structured Type to serialize the value into.
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: Thanks !
This document obsoletes RF7807.
This document obsoletes RFC7807.
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: It seems that saying could be read as identifying the problem instance rather than identifying the problem type . Here 's a minor edit to make this more explicit : It 's not quite clear to me what other identifiers could be ( patterns of extension members , maybe ? ) , but that 's a different question .
The "type" member is a JSON string containing a URI reference URI
that identifies the problem type.  Consumers MUST use the "type" URI
(after resolution, if necessary) as the problem's primary identifier.
The "type" member is a JSON string containing a URI reference URI
that identifies the problem type.  Consumers MUST use the "type" URI
(after resolution, if necessary) as the problem type's primary
identifier.
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: Currently : That does n't seem like a recipe for good interop . While it does n't need to be an RFC , some sort of reference is necessary ... 
 I 'm sorry , but I do n't quite understand what is being referred to here . Is the quoted paragraph from RFC7807 ? Because I ca n't find it . Without more context I also do n't quote understand what it is referring to . 
 https://ietf - wg-
A Designated Expert reviews and approves registration requests, as
per RFC8126, Section 4.5.  A specification document is appreciated,
but not required.
When evaluating requests, the Expert(s) should consider community
feedback, how well-defined the problem type is, and this
specification's requirements.  Vendor-specific, application-specific,
and deployment-specific values are not registrable.
Registrations MAY use the prefix "https://iana.org/assignments/http-
problem-types#", and are encouraged to do so when a stable, neutral
URI is desirable.
The policy for this registry is Specification Required, per RFC8126,
Section 4.5.
When evaluating requests, the Expert(s) should consider community
feedback, how well-defined the problem type is, and this
specification's requirements.  Vendor-specific, application-specific,
and deployment-specific values are not registrable.  Specification
documents should be published in a stable, freely available manner
(ideally located with a URL), but need not be standards.
Registrations MAY use the prefix "https://iana.org/assignments/http-
problem-types#" for the type URI.
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: As discussed in , this PR expands on the dereferenceability of to clarify what the URI is expected to return , which hopefully also clarify the intended use of . 
 Merging , might tweak a bit further in situ . Thanks !
When the "instance" URI is dereferenceable it can return the same
problem response that was returned to the client which generated the
problem originally.  It might also return more information about the
problem occurrence in other formats (e.g., using proactive content
negotiation; see HTTP, Section 12.5.1).
When the "instance" URI is not dereferenceable, it serves as a unique
identifier for the problem occurrence that may be of significance to
the server, but is opaque to the client.
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: From : JSON objects with a null " type " are syntactically correct , but there is no information on how it should be handled . { " type " : null , " status " : 404 , " title " : " Not Found " } It makes sense to treat null as an alias of " about : blank " and that 's how I think it should be documented . 
 Note that the errata above is only . My .02 -- if is , it 's invalid , not " syntactically correct " ; it 's specified to be a string , and if someone assumes that has semantics , that 's not currently specified behaviour . So the real question here is whether the default of is assumed when the value is invalid , or whether some other error handling comes into play . I think the safest thing to do would not be to assume that implies -- i.e. , no change to the spec . 
 Since this is a specification of a format for error messages , I believe it is important that the processing of the error message is clear and lenient so the processing itself does not cause errors , possibly shrouding the initial error that caused the response in the first place . I therefore think the specification should be explicit that all erroneous values ( such as , , , etc . ) should be ignored and treated as the default value of each member , which for equals to , but for other members equal to an empty string ( ? ) . 
 I think I agree ; changing issue title .
Problem detail objects can have the following members.  If the type
of a member's value does not match the specified type, the member
MUST be ignored - i.e., processing will continue as if the member had
not been present.
Draft: draft-ietf-httpapi-rfc7807bis

Commentary: Thank you .
Problem type definitions MAY specify the use of the Retry-After
response header (I-D.ietf-httpbis-semantics, Section 10.2.4) in
appropriate circumstances.
Problem type definitions MAY specify the use of the Retry-After
response header (I-D.ietf-httpbis-semantics, Section 10.2.3) in
appropriate circumstances.