Murray Kucherawy is the document shepherd. Barry Leiba is the
responsible Area Director.
This document defines a "problem detail" as a way to carry machine-
readable details of errors in a HTTP response, to avoid the need to
invent new error response formats for HTTP APIs.
The working group requests Proposed Standard status, as it qualifies for
such per RFC 2026 Section 4.1.1. In particular, the proposal is thought
to be useful enough that there are several implementations (see
https://github.com/mnot/I-D/wiki/http-problem), it has review from both
the HTTP community at the IETF and the W3C (the TAG), and its
advancement has the support of APPSAWG.
WGLC finished almost a year ago, and there has been a small amount of
activity since then which has been incorporated into the document. Much
of the delay since then has been caused by waiting for TAG feedback
(which never came), and the remainder of the blame falls on the WG
chairs. It's ready for formal processing.
2. Review and Consensus
The document originally appeared as an individual submission in July of
2012 and went through some evolution resulting in several revisions
before being adopted by APPSAWG about a year ago. It has been largely
stable since then. There has been cross-development between APPSAWG
participants and W3C TAG. Development has stabilized since its WGLC,
and implementations have matured with little change to the document.
Perhaps noteworthy with respect to consensus is that the participants of
APPSAWG cover a broad area of applications, and only some focus on HTTP
work. However, that smaller group does tend to be active and thorough
when they take up a work item in their specific interest area. With
that in mind, consensus on the current content appears to be solid
rather than rough.
One of the document authors is both HTTPBIS chair and also the IETF
liaison to the W3C, so I'm satisfied that there has been ample airing of
this proposal on both sides of that particular fence.
3. Intellectual Property
Both authors have affirmed that they have already disclosed all direct,
personal knowledge of any IPR related to this document, in conformance
with BCPs 78 and 79.
4. Other Points
IANA Considerations appears to be properly formed. To the eyes of this
media type reviewer-in-training, the registrations appear to be sound,
especially in the areas for which we usually send registrations back to
the authors.
There are no downward normative references.
Nothing else of note.