`taskid` should be optional in problem documents

[tgeoghegan]

Section 3.2 discusses how to construct HTTP problem documents. In particular, this paragraph states:

The problem document MUST also include a "taskid" member which contains the associated DAP task ID (this value is always known, see Section 4.2), encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of [RFC4648].

It's not true that the task ID is always known. 4.3.1 allows implementations to respond to requests to /hpke_config that don't have a task_id 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 taskid.

[tgeoghegan]

We might also consider making the key task_id for consistency with the query parameter on /hpke_config.

[cjpatton]

I think this is text-ready.

[tgeoghegan]

Thinking about this further, I think this is actually a dupe of #278. Currently, we require that problem documents contain the taskid and an instance value that "MUST be the endpoint to which the request was targeted". The examples of instance values in RFC 7807 look like this:

{
             "type": "https://example.com/probs/out-of-credit",
             "title": "You do not have enough credit.",
             "detail": "Your current balance is 30, but that costs 50.",
             "instance": "/account/12345/msgs/abc",
             "balance": 30,
             "accounts": ["/account/12345",
                          "/account/67890"]
}

Here, the value of instance is a relative path pointing to the resource that caused the error. Our requirement that instance be the "endpoint" seems unhelpful. If I hit some API like https://aggregator.example/dap-api/upload, and it fails, and I get back a problem document with "instance": "https://aggregator.example/dap-api", 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 "instance": ".." since RFC 7807 allows relative URLs in instance.

Once we do #278, then I think we won't need a dedicated taskid (or task_id) 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 instance. For example, a failed upload request might yield a problem document with "instance": "/tasks/abcdefghijklmnopqrstuvwxyz/reports/01234567890abcdef", and a client can parse the task ID out of that.

So my plan here is to address #278, 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.

[cjpatton]

Since we're punting #278 past draft-03, I'm going to update the tag.

[cjpatton]

Closed by #389.