Support "file" not just "directory" paths

[jernst]

Consider https://foo.example/bar/baz.html.

• Applying the algorithm, this leads to did:web:foo.example.com:bar:baz.html. Is that intended? If so, add an example to the doc. If not, be clear it shouldn't be. (I believe the entire URL path namespace should be mappable, perhaps even including parameters).
• Applying the reverse algorithm, the DID document is supposed to be at http://foo.example/bar/baz.html/did.json. Is that intended, turning "file" baz.html into a "directory" all of a sudden? If so, please be clear about it. If not, document an alternative.

[gribneau]

(I believe the entire URL path namespace should be mappable, perhaps even including parameters).

There hasn't been consensus in support of direct mapping as described.

What would baz.html contain?

If you intend to encode DID information within the HTML, perhaps as a JSON object definition in javascript, would it be easier to simply use the https URL?

[jernst]

The way I understand the intent of the path namespace in URLs is that no structure is assumed. The "file" vs "directory" distinction that we tend to make is entirely a convention that comes from many web servers directly mapping the path into a filesystem hierarchy. Ergo, the DID web spec should make no distinction between paths that end with slash or with .html. So I'm in favor of one of the alternatives that I'm outlining. It's just that the spec is silent about it and that lets people hallucinate what they thought the intent was, and that's usually not a good plan for specs ...

[gribneau]

the DID web spec should make no distinction between paths that end with slash or with .html

The spec makes no distinction in that respect. The method specific identifier is colon delimited because people were uncomfortable with the use of the URI path. You can find the reason for this concern in DID core.

Do you have a specific use case in mind?