Is the TUF target path separator always "/"?

I noticed that in 4.4.5 spec defines as TARGETPATH:

Each key of the TARGETS object is a TARGETPATH. A TARGETPATH is a path to a file that is relative to a mirror’s base URL of targets. It should not have a leading path separator to avoid surprising behavior when constructing paths on disk.

Presumably this should be /, it says it’s a file relative to the URL, and URLs use that as the path separator, but it’d be helpful if this was explicit.

This is relevant because in rust-tuf, we have a PathTranslator in order to use alternative path separators to support converting / to \ on windows, but I’m pretty sure this logic really should be moved to our FileSystemRepository.

[erickt]

I personally vote for us standardizing on the target path to be the URL spec’s path relative url string, since presumably all OSs should have some mechanism for resolving a file:// path.

Otherwise, if we allow different path separators, then we run into ambiguity with a target path foo\bar. If we try to naively open that on linux, it will try to open a file named "foo\bar". On Windows though, it’d open the file "bar" in the directory "foo". Things would get even more confusing if someone tries to store a target path using some of the other Windows path formats, like "\\.\UNC\LOCALHOST\c$\foo\bar".

[lukpueh]

I think you’re right, @trishankatdatadog, it may not be necessary to make this mandatory. But it’s probably still a good idea for an implementation to normalize paths to unix style for the reason that @erickt has mentioned, and also to behave unsurprisingly when expanding unix shell-style wildcards as the we do in delegation path patterns (see spec#L877-L878).

The metadata examples exclusively use forward-slashes. Is it worth adding a recommendation?