This is a draft specification for the 'ftss' URI scheme.
The 'ftss' URI scheme is intended to identify resources that exist in a 4Suite repository. The use of a consistent, unique URI space for these resources allows them to be referenced and accessed easily, deliberately, and without ambiguity.
The ftss URI scheme is a hierarchical URL scheme. As such, it works much like other hierarchical schemes and supports relative references.
The format of an ftss URI is defined as follows:
"ftss" ":" "//" server abs_path
Refer to RFC 2396 for the definition of server and abs_path. A minimal ftss URI, identifying the root container of a repository, is simply "ftss:///".
The server component represents the repository in which the resource resides. This representation is achieved indirectly by representing the information needed to establish a 4Suite RPC (FtRPC) protocol connection to the repository in order to access a representation of the resource.
If provided, the server component's userinfo, host, and port subcomponents correspond to the username, password, host, and port used for the FtRPC connection. Omitting any of these subcomponents implies an implementation-specific default; much like with a 'file' URI, the identified resource is unique to a specific but unmentioned server.
Characters in each part of the server component map directly to characters in the protocol elements represented. UTF-8-based percent-encoded equivalents may be used, but as of 4Suite 1.0, equivalence is not checked, and such characters are not adequately decoded in all situations, so percent-encoding of any kind is currently inadvisable.
The abs_path component represents the path of the resource in the repository. Characters in the resource's repository path map directly to characters in the abs_path component. UTF-8-based percent-encoded equivalents may be used, but as of 4Suite 1.0, equivalence is not checked, and such characters are not adequately decoded in all situations, so percent-encoding of any kind is currently inadvisable.
The generic syntax may allow for other components in an ftss URI. The semantics of such components (e.g. a query component) are undefined.
In order to obtain a new representation of the resource identified by an ftss URI, a resolver should use 4Suite's own RPC protocol for repository access, or should use whatever means are at its disposal in order to produce a representation that would have been obtained via that protocol.
abs_path maps directly to the absolute path to the resource in the repository. Container resources may be identified with or without a trailing slash, but the trailing slash is recommended, in practice, so that resolution of relative references (for example, those that appear in the resource itself) will work as expected.
It should be noted that the implementation of ftss URIs in 4Suite 1.0 and earlier is fragile and does not fully support this specification. The principal defect is that characters outside of the narrow set of A-Z, a-z, 0-9, "-", and "_" and percent-encoded octets are not handled consistently. Therefore it is advisable, for now, to only use characters from that set in repository paths and their corresponding ftss URIs.