Draft: draft-ietf-ppm-dap

Commentary: 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 do n't have a query parameter with an error , and in that scenario I do n'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 wo n'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 do n'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  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 do n't think this field should be required . MAY or SHOULD would be sufficient .
Paragraph (version A):
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
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.
Paragraph (version B):
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
urn-space).  The "detail" member of the Problem Details document
includes additional diagnostic information.
Paragraph (version B):
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.