consistent targets is not well defined with regards to TARGETPATH

When the specification talks about consistent targets, it always refers to filenames. Here is 6.2.1. Writing consistent snapshots:

consistent target files should be written to non-volatile storage as digest.filename.ext

Here is 5.7.3 talking about building the download URL in client:

the filename is of the form HASH.FILENAME.EXT

The issue is that in both cases what we are really interested in is the target path (which is really part of a target URL) and how the hash is used produce the target URL (on client) or how it is parsed from a target URL (on repository). The spec should define how to do URL construction instead of defining filename construction.

https://theupdateframework.github.io/specification/latest/#targetpath does limit target path to just URL path segments (so according to that query and fragment parts would not be allowed in target path).

So:

• Injecting hash into and parsing the hash from target URL should be defined instead of talking about filenames
• if the valid target paths are restricted by spec, those restrictions should be stated (e.g. must a filename part be non-empty?)
• Preferably examples should be given

Some potential target path examples:

a
a/b
a%2Fb
a\b
a/
?a=b        # query, so not allowed according to strictest targetpath definition
#a          # fragment, so not allowed according to strictest targetpath definition

In all of these cases we can figure out a "filename like component" (in last 3 the filename is an empty string) and we can of course prefix that with {HASH}.. Alternatively the spec could require the target path to contain a non-empty filename element ("filename" is not a thing that really exists in URLs but I assume we could).

Start with specification sections 5.7.3, 6.2.1, and the targetpath definition referenced in the issue. Compare their filename and target-path language, then update the specification to define hash handling, valid target-path restrictions, and representative examples consistently.