Change:
This list is not exhaustive.  The server MAY return errors set to a URI other than those defined above.  Servers MUST NOT use the DAP URN namespace for errors not listed in the appropriate IANA registry (see <del> urn-space).  Clients SHOULD display the "detail" field of all errors. The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated DAP task ID (this value is always known, see task-configuration), encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of RFC4648. </del> <ins> urn-space).  The "detail" member of the Problem Details document includes additional diagnostic information. When the task ID is known (see task-configuration), the problem document SHOULD include an additional "taskid" member containing the ID encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of RFC4648. </ins> In the remainder of this document, the tokens in the table above are used to refer to error types, rather than the full URNs.  For

Discussion:
Section 3.2 discusses how to construct HTTP problem documents. In particular, states: >The problem document MUST also include a "taskid" member which contains the associated DAP task ID (this value is always known, see ), encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of ]. It's not true that the task ID is always known. allows implementations to respond to requests to that don't have a query parameter with an error, and in that scenario I don't think there is any sensible task ID value for the server to use. We should change this MUST to allow some problem documents to omit .
We might also consider making the key for consistency with the query parameter on .
I think this is text-ready.
Thinking about this further, I think this is actually a dupe of . Currently, we require that problem documents contain the and an value that "MUST be the endpoint to which the request was targeted". The examples of values in RFC 7807 look like this: Here, the value of is a relative path pointing to the resource that caused the error. Our requirement that be the "endpoint" seems unhelpful. If I hit some API like , and it fails, and I get back a problem document with , then that's not very helpful, because I already knew what URI I accessed when I made the request. It's also kinda annoying for implementations to have to know what public domain they're serving traffic from. For this reason, Janus always sets since RFC 7807 allows relative URLs in . Once we do , then I think we won't need a dedicated (or ) field in problem documents anymore, because if the task ID is relevant to the request, then it'll appear in the relative path that we can put in . For example, a failed upload request might yield a problem document with , and a client can parse the task ID out of that. So my plan here is to address , and in doing so, update the problem document text. If I don't get around to that for draft-03 for some reason, then the smaller change described here will suffice.
Since we're punting past draft-03, I'm going to update the tag.

Some of the requirements and recommendations in section 3.1 conflict with the spirit of RFC 7807, which it references. There is presently a requirement that: The "instance" key is defined as one of the standard members in RFC 7807, and it says: As a consequence of the current text, PPM aggregators would always provide the same URI in the "instance" field. I would recommend that we remove the MUST requirement here. Alternately, we could define a new extension member (say, "endpoint") and put the aggregator's endpoint in that member, if we still wish to have it as part of the problem details. (For what it's worth, RFC 7807 allows the "type" and "instance" members to be relative URIs, so there is already a baked-in assumption that problem detail consumers retain the request URL associated with a JSON document) Second, there's a SHOULD recommendation that the "detail" field be populated, and no mention of the "title" field. These are both standard members, defined as follows: I think we should add a recommendation that, when one of the error types from Table 1 is used, the accompanying description from the table (or a localization thereof) should be provided in the "title" member. The "detail" member could then provide more particularized information, for example, a message mentioning the old and new configuration IDs involved in an error. Third, there is currently the following requirement for a PPM-specific extension member: Assuming that an aggregator services multiple PPM tasks at one HTTP endpoint, there are edge cases where we may want to use , but not know the task ID, for example, if a request body is too short to encode a task ID. With the present text, I think aggregators would have to respond with a non-PPM error type, or just a 400 Bad Request response with an empty body. As "taskid" is the only extension member we define on our problem types, I think we should clarify the MUST requirement here, and only require it when the "type" is one of the error types in the PPM URN namespace. For the edge cases where "taskid" is not known we could relax the MUST requirement, and only require a "taskid" member when the PPM Task ID is known.

Alternately, we could suggest that the error in such error cases be of type (the default type, indicating no additional semantics beyond that of the HTTP status code) and with an appropriate status line, like "400 Bad Request".
+1, I think this should be MAY. This sound fine. +1 to clarifying the edge case you point out, however I don't think this field should be required. MAY or SHOULD would be sufficient.