Section 12.1: no status code or Content-Type rule for a complete DID resolution result #365

Section 12.1, step 8 ("For the DID resolution function:") has two sub-steps, matching the two request modes in step 2: Accept: application/did-resolution for a complete result, or a DID document media type such as application/did (the accept resolution option) for the bare didDocument.

Step 8.1 specifies only the body:

If the value of the Content-Type HTTP response header is application/did-resolution:

• The HTTP body MUST contain a DID resolution result ... that is the result of the DID resolution function.

It gives no status code and does not require a Content-Type header. Steps 6 (errors) and 7 (deactivated) cover their own cases, so no normative text in Section 12.1 says a successful complete result is a 200. The example in Section 12.2.1 shows one: 200, Content-Type: application/did-resolution, and "contentType": "application/did" in the body.

Both requirements appear only in step 8.2. Its condition, "If the function is successful and returns a didDocument", is written on the return value rather than the negotiated mode, so it matches a complete result too. On that reading, its header rule (the value of contentType in didResolutionMetadata) contradicts step 8.1: the 12.2.1 response would have to carry Content-Type: application/did, and 8.2's body rule then asks for the didDocument "in the representation corresponding to the Content-Type".

The test suite reads it that way. tests/10-bindings.js requests with Accept: application/did-resolution, then tests step 8.2's header rule against that response. The test is named "MUST equal" but asserts a substring:

contentTypeHeader.should.include(
  resolutionResult.didResolutionMetadata.contentType);

It passes only because application/did-resolution contains application/did. As the equality check its name describes, it would fail every resolver that answers like the 12.2.1 example.

Step 9 (DID URL dereferencing) has the same gap and the same overlap. In step 9.3, "any other contentType" means other than text/uri-list, and contentType there is the media type of the contentStream, so 9.3 matches the complete result in the Section 12.3.1 example ("contentType": "application/did"). Step 9.2 would answer a complete result whose content is text/uri-list with a 303 and an empty body. This is moot if #306 drops the dereferencing binding, as #326 proposes.

Suggested fix: under step 8.1, require a 200 unless step 6 or 7 sets the status, and make step 8.2 an "Otherwise, if the function is successful and returns a didDocument" branch, so it covers only the bare-document response. Step 9 needs the same change if it stays. #303 would remove the accept option, and possibly contentType from didResolutionMetadata, which rewrites step 8.2 anyway; step 8.1's missing status code stands either way.