Thanks for taking the time to provide feedback on WSD v0!
omz13 As WSD was based on WKD, it would really help if it was similarly structured (and that will also mean the missing IANA considerations will be apparent).
I tried to make the structure as similar as possible. This is my first foray in specs so if there's something obvious I'm doing wrong, do let me know.
As for IANA considerations, I wanted to include that as soon as the WSD seems mature enough to publish it on IETF. Again, I do not know the IETF procedures yet, but I imagine IANA won't just accept any request, right? Wouldn't they prefer an IETF-published spec?
If you think IANA considerations can be made outside IETF or more "official" spec channels, I will add it right away.
omz13 I much prefer when examples are inline with the section that they apply to, instead of as an appendix... it makes it easier to see what's going on, especially with a new spec when things tend to be in flux.
I think I would prefer that too. Again, in my attempt of modelling it after the already-successful WKD, I copied their structure. Do you have an example RFC with good inline examples? I'll go look.
omz13 WSD. Does this operate like direct vs advanced mode? It seems to be only direct mode... but then in A.2 the concept of a WSD Service Provider appears (and I'd expect that to be more like advanced mode, which isn't supported).
Since the identifier is an URI, I figured direct/advanced mode doesn't apply here. In WKD, it's necessary because the key-hosting domain may not be the same as the email-hosting domain. Here, the URI contains the key-hosting domain, so it will always be "direct mode".
In my reasoning, WSD Service Providers can still work with "direct" mode, the URI follows the same pattern: wsd:domain:arbitrary_identifier
omz13 2.1.1. "To allow the mapping of incoming HTTP requests directly to the file system" ... that is a big assumption (mapping requests to storage in a file system)
The spec doesn't per se recommend it, but this way of doing it does allow the hoster to just map to a directory in the file system. I think that's a good solution for people with static sites and simple reverse proxy configurations. What would be the issue in your opinion?
omz13 2.1.1. what are the limits (minima and maxima) for size (length) of "local-part"?
Very good point that I had not yet considered! To me, 1 char can be the minimum. We could set a maximum of 40 chars to allow the identifier to be the fingerprint of an OpenPGP key, not sure if there are longer strings we would like to support. UUIDs perhaps? They are 36 chars.
That makes sense!
omz13 3.1. "newline-separate value" ... all header: value things are newline separated, so that is superfluous.
That is not entirely what I meant, so: 1) my explanation was bad and 2) it would be great to find a simpler solution to this issue.
Here's the body of one of the example requests (separated over multiple lines to make it easier to read):
I need to sign the request with a timestamp to create a pseudo-TOTP to prevent resubmission at a later moment of an intercepted request. I took inspiration from the ActivityPub HTTP signatures.
I did not want to use actual HTTP headers because I tried to make the whole process compatible with JS-less HTML forms. Thus, I created two fields:
header (by lack of a better term) and
header-signature in the body. I now think this needlessly complicates the story. It would be sad not to support JS-less forms but using the
Date header makes more sense than putting the date inside a
header field inside the body of the request.
omz13 3.1 why does you need a "timestamp" header? what purpose does it serve? (if you do need it, better named as "wsd-timestamp" than just "timestamp"
See response above.
omz13 3.1 "the upload MUST be aborted and return" => "the upload MUST return" (2 instances)
omz13 "WSD servers SHOULD NOT index the WSD well-known directory." there is better phrasing in §5 of WKD for this.