[core] New Version Notification for draft-amsuess-core-pd-body-error-position-00.txt

[Christian Amsüss <[e-mail]>]

Hi Standard Problem Detail Keys experts, hello group,

implementing RFC9290 for the Rust coap-handler-implementations, I found
that many error paths are due to parsing errors (which, the way things
are set up, are not distinguished between CBOR format errors or just
unexpected elements). The problem detail might lend itself to
generalization, which I've written up with the intention to apply for a
standard problem detail number.

While no WG or even IETF action is required for this, I'd appreciate a
few eyes and/or comments before sending this to IANA and eventually the
experts, Thomas and Carsten.

Below the "new document" template, I've copied down the two most
relevant sections for your convenience.

Name:		draft-amsuess-core-pd-body-error-position
Revision:	00
Title:		Concise Problem Details: Body Error Position
Document date:	2023-02-04
Group:		Individual Submission
Pages:		5
Status:         https://datatracker.ietf.org/doc/draft-amsuess-core-pd-body-error-position/
Html:           https://www.ietf.org/archive/id/draft-amsuess-core-pd-body-error-position-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-amsuess-core-pd-body-error-position

Abstract:
   This defines a single standard problem detail for use with the
   Concise Problem Details format: Request Body Error Position.  Using
   this detail, the server can point at the position inside the client's
   request body that induced the error.


1.2.  Document lifecycle

   Registering a standard problem detail merely requires a
   specification, not an RFC (let alone of a particular track).

   It is the author's opinion that an Interned Draft can provide
   sufficient specification, and is more suitable than an informal note
   published at some arbitrary website due to its archival through the
   draft submission process.

   It is not expected that this draft will proceed all the way to an
   RFC; instead, once sufficiently mature, it will be used as a
   reference in a request to IANA, and updated with the assigned number.

   This document will eventually expire as an Internet Draft, but
   nonetheless be usable as the permanent reference for the assigned
   problem detail.

2.  Request Body Error Position

   The Request Body Error Position problem detail indicates that the
   error described by the Concise Problem Details response resulted from
   processing the request body.  The numeric value indicates a byte
   position inside that body that corresponds to the error.  The precise
   error position for invalid data may vary by implementation -- for
   example, if a numeric value inside a CBOR ([STD94]) item exceeds the
   expected range, it may indicate the number's initial byte (typically
   if the implementation doesn't even implement the indicated argument
   size) or the argument (if it implements it).

   When the request's content format indicated a non-identity content
   coding, the offset points into the uncompressed body.  Consequently,
   this error detail is not suitable for pointing out errors that occur
   during uncompressing.

   The main envisioned use of this option is for the client to highlight
   or back-annotate (eg. to counteract minification, or to display it on
   some diagnostic notation) the erroneous item in the request body for
   a human author.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom