Resource Locator String specification
Version 0.9


Enzo-Adrian Reyes(

With contributions by:

Barry Fitzgerald(
Daniel W. Connolly(
Matthias Rosenkranz(
Sean B. Palmer(

  1. Introduction

  2. Format

  3. Conclusion

  4. References


        The idea behind a RLS (Resource Locator String) is the easy identification, and passing of information from peer to peer. It can also be used by end users to locate remote services provided by DotGNU. A RLS can be used to point to any DotGNU, this forces the RLS to be generic in format and also extendable for the individual service. Hence each service may expect a different RLS input, it is up to the individual service to interpret it's RLS tokens and data.


        The format of an RLS contains two non-optional fields, these fields are separated using the '/' character. As an extension to these non-optional fields, RLS's have two extra fields which are optional. The format of an RLS is as follows:

rls://[User name@]<DotGNU Server>[:port]/<DotGNU Service>[?Meta-Token]

The optional fields are in square brackets, while the non-optional fields are in nested in "<>" brackets.

Note: Please do note that the RLS specification is trying to conform to IETF RFC 2396 regarding Universal Resource Identifiers. If you find conflicts against the RFC please inform one of the Authors of the breach.

Non-optional Fields:

        The first non-optional field is the "<DotGNU server>" field. This field tells a machine the IP/DNS of the server to locate the service. The second field is the "<DotGNU Service>" field and contains a string which is passed to the server, contained in the server field, to open the named service. Some examples:

(1) rls://
(2) rls://
(3) rls://

        The first example opens the server and asks for it's cvs service. The second example also opens the same server and ask's to use the mail-list service. The third opens and asks for the tbbs service.

Optional fields:

        The optional fields contain information which is of no use to the DotGNU server, but rather to the service it provides.

        The first optional field is the user-name field. Now this field is used for the authentication mechanism in DotGNU. Examples include:

(1) rls://
(2) rls://
(3) rls://
(4) rls://

        So, here in these examples, all use the authentication service (different names can be used but convention should be followed). So it tells us, that user myrddian is seeking authentication from server Another less obvious example is that of self authentication. In number four, user myrddian wants to use the CVS service but CVS may ask for authentication, however the authentication data is on the local server, so it will self verify.

Meta-Token examples:

(1) rls://,%20speeling

        An RLS contains a Meta-Token this token contains a series of embeded tokens. The Meta-token is a RFC-2396 compliant string, this means it must contain escape characters in the format %hh, for seperators or any reserved characters. Tokens are embedded in this string. When a server receives a Meta-Token string it must convert it to the Standard Token format descrived below. This also works the other way around, Tokens must be converted and nested inside this Meta-Token.


        The tokens string, can contain data, be it a pointer back to another object or a string. The format of tokens on how their data is represented is not enforced, the DotGNU server will not enforce token data. The only exception to this rule is separation of Token data, and or nesting of token data. These are the only two rules enforced by the primary DotGNU server, everything else and the data the tokens contains has to be enforced by the individual service.

        Tokens are separated using the ',' character, so <token 1>,<token2> can be recognized separately. If a string may contain the comma separator it is recommended that it be nested within " " as this prevents premature separation.

Nested tokens:

        Nested tokens have two ways to separate the data, one way is to have the entire nested data within square brackets, the other is to have an identifier before the square brackets. Now, the first format might be useful to encase other RLS on to the same string, an example of this the first would contain the where the service the second where authentication can be found for the user requesting the service. Tokens with an identifier may contain other data other than nested RLS's. Examples include:

(3)[rls://],cmd[checkout[.], checkin]

Number 1 uses another RLS to check authentication for the CVS service.
Number 2 uses a named nested token and it has two extra fields inside.
Number 3 has both separation and nesting examples.

Heirarchical Services

         Conformance to RFC 2396 has solved another problem for us. Now, the RLS spec includes support for Heirarchical Services. In other words, services can have services within them. For example:

(1) rls://

In this example, I'm using the service "checkin" under "cvs" to check the module "dotgnu" into the cvs tree at With the inclusion of Heirarchical Services, the ultimate flexible interface to the dotGNU API can be achieved.


         Because a DotGNU server may not be in a standard port, a referring port must be passed along with the RLS. For Example:

  1. ) rls://


        With the optional nesting fields, RLS's can point to any data. Their simplification has lead to better versatility. Because the tokens can point to any data, the data pointed to can be encrypted. While the RLS string it self may be transported over a secure encrypted protocol to provide better security. Tokens can also contain nested encryption keys, thus allowing even better security.