jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-httpapi-idempotency-key-header

Commentary: let me know if this fixes the issue 
 You 'll want to link or close it , but yes , this is good . 
 This is a problem for our format . Please try to keep examples to 69 columns ( or 72 in a pinch ) . These examples are free - form strings in JSON , so they can probably just be wrapped . 
 take a look at PR and let me know if ok now .
Error scenarios above describe the status of failed idempotent
requests after the resource server prcocesses them.  Clients MUST
correct the requests (with the execption of 409 where no correction
is required) before performing a retry operation, or the the resource
server MUST fail the request and return one of the above errors.
Error scenarios above describe the status of failed idempotent
requests after the resource server prcocesses them.  Clients MUST
correct the requests (with the exception of 409 where no correction
is required) before performing a retry operation, or the the resource
server MUST fail the request and return one of the above errors.
Draft: draft-ietf-httpapi-idempotency-key-header

Commentary: Issue 
 pl review re issue 
 Looks good 
 the examples of errors use a pattern of using a link in a header , and then ( supposedly ) using a human - readable error message . what about using RFC 7807 instead and using examples that use problem reports to indicate failure semantics in addition to the status code ? 
 I agree . coming up in the next draft . 
 should we close this issue if it is resolved ? 
 closing this issue . Let me know if not addressed with my latest PR .
If the "Idempotency-Key" request header is missing for a documented
idempotent operation requiring this header, the resource server
SHOULD reply with an HTTP "400" status code with body containing a
link pointing to relevant documentation.  Alternately, using the HTTP
header "Link", the client can be informed about the error as shown
below.
If there is an attempt to reuse an idempotency key with a different
request payload, the resource server SHOULD reply with a HTTP "422"
status code with body containing a link pointing to relevant
documentation.  The status code "422" is defined in Section 11.2 of
RFC4918.  The server can also inform the client by using the HTTP
header "Link" as shown below.
If the request is retried, while the original request is still being
processed, the resource server SHOULD reply with an HTTP "409" status
code with body containing a link or the HTTP header "Link" pointing
to the relevant documentation.
If the "Idempotency-Key" request header is missing for a documented
idempotent operation requiring this header, the resource server
SHOULD reply with an HTTP "400" status code with body containing a
link pointing to relevant documentation.  Following examples shows an
error response describing the problem using RFC7807.
Alternately, using the HTTP header "Link", the client can be informed
about the error as shown below.
If there is an attempt to reuse an idempotency key with a different
request payload, the resource server SHOULD reply with a HTTP "422"
status code with body containing a link pointing to relevant
documentation.  The status code "422" is defined in Section 11.2 of
RFC4918.
The server can also inform the client by using the HTTP header "Link"
as shown below.
If the request is retried, while the original request is still being
processed, the resource server SHOULD reply with an HTTP "409" status
code with body containing problem description.
Draft: draft-ietf-httpapi-idempotency-key-header

Commentary: update my organization association & email i d 
 pls review and merge this PR . We can publish the  after that . 
 looks like this one was merged already .
If the "Idempotency-Key" request header is missing for a documented
idempotent operation requiring this header, the resource server MUST
reply with an HTTP "400" status code with body containing a link
pointing to relevant documentation.  Alternately, using the HTTP
header "Link", the client can be informed about the error as shown
below.
If there is an attempt to reuse an idempotency key with a different
request payload, the resource server MUST reply with a HTTP "422"
status code with body containing a link pointing to relevant
documentation.  The status code "422" is defined in Section 11.2 of
RFC4918.  The server can also inform the client by using the HTTP
header "Link" as shown below.
If the request is retried, while the original request is still being
processed, the resource server MUST reply with an HTTP "409" status
code with body containing a link or the HTTP header "Link" pointing
to the relevant documentation.
Error scenarios above describe the status of failed idempotent
requests, after the resource server prcocesses them.  Clients MUST
correct the requests before performing a retry operation, or the the
resource server MUST fail the request and return one of the above
errors.
If the "Idempotency-Key" request header is missing for a documented
idempotent operation requiring this header, the resource server
SHOULD reply with an HTTP "400" status code with body containing a
link pointing to relevant documentation.  Alternately, using the HTTP
header "Link", the client can be informed about the error as shown
below.
If there is an attempt to reuse an idempotency key with a different
request payload, the resource server SHOULD reply with a HTTP "422"
status code with body containing a link pointing to relevant
documentation.  The status code "422" is defined in Section 11.2 of
RFC4918.  The server can also inform the client by using the HTTP
header "Link" as shown below.
If the request is retried, while the original request is still being
processed, the resource server SHOULD reply with an HTTP "409" status
code with body containing a link or the HTTP header "Link" pointing
to the relevant documentation.
Error scenarios above describe the status of failed idempotent
requests after the resource server prcocesses them.  Clients MUST
correct the requests (with the execption of 409 where no correction
is required) before performing a retry operation, or the the resource
server MUST fail the request and return one of the above errors.
Draft: draft-ietf-httpapi-idempotency-key-header

Commentary: This : Gets the editors ' draft generated by the template using GitHub actions ( was never set up )  up some document metadata Updates the IANA considerations section to fit current practice 
 looks like this one did n't work as expected , 
 Fixed .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here, and without quotes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
The "Idempotency-Key" request header should be added to the permanent
registry of message header fields (see RFC3864), taking into account
the guidelines given by HTTP/1.1 RFC7231.
The Idempotency-Key field name should be added to the "Hypertext
Transfer Protocol (HTTP) Field Name Registry".
Draft: draft-ietf-httpapi-idempotency-key-header

Commentary: 1- Addressed comments wrt 5XX codes being retriable 2- Elaborated the security section to describe security issues relating to the idempotency key
The request was retried after the original request completed.  The
resource server MUST respond with the result of the previously
completed operation, success or an error.
The request was retried after the original request completed.  The
resource server SHOULD respond with the result of the previously
completed operation, success or an error.  See Error Scenarios for
details on errors.
For other errors, the resource MUST return the appropriate status
code and error message.
Error scenarios above describe the status of failed idempotent
requests, after the resource server prcocesses them.  Clients MUST
correct the requests before performing a retry operation, or the the
resource server MUST fail the request and return one of the above
errors.
For other 4xx/5xx errors, such as 401, 403, 500, 502, 503, 504, 429,
or any other HTTP error code that is not listed here, the client
SHOULD act appropriately by following the resource server's
documentation.
For idempotent request handling, the resources MAY make use of the
value in the idempotency key to look up a cache or a persistent store
for duplicate requests matching the key.  If the resource does not
validate the value of the idempotency key prior to performing such a
lookup, it MAY lead to various forms of security attacks and
compromise.  To avoid such situations, the resource SHOULD publish
the expected format of the idempotency key, algorithm used to
generate it and always validate the key value as per the published
specification before processing any request.
Injection attacks-When the resource server does not validate the
idempotency key in the client request and performs a idempotent
cache lookup, there can be security attacks (primarily in the form
of injection), compromising the server.
Data leaks-When an idempotency implementation allows low entropy
keys, attackers MAY determine other keys and use them to fetch
existing idempotent cache entries, belonging to other clients.
To prevent such situations, the specification recommends the
following best practices for idempotency key implementation in the
resource server.
Establish a fixed format for the idempotency key and publish the
key's specification.
Always validate the key as per its published specification before
processing any request.
On the resource server, implement a unique composite key as the
idempotent cache lookup key.  For example, a composite key MAY be
implemented by combining the idempotency key sent by the client
with other client specific attributes known only to the resource
server.