RDEX - Redirects Extended

RDEX - Redirects Extended

The goal of this extension is to enhance the redirect capabilities provided by BASE by adding support for two new redirect operations and a way for hubs and clients to communicate accepted redirect protocols. The two new types of redirects added by this extension are multiple choice redirects and so-called permanent redirects as outlined below. These new redirect types are not necessarily mutually exclusive.

Support for this extension is indicated by the presence of an RP field in the INF, which defines the accepted redirect protocols for the hub or a client as a bitmask using any combination of following values.

	Protocol						    Flag (Hex)
	Advanced Direct Connect						0x01
	ADCS - Symmetrical Encryption in ADC				0x02
	NeoModus Direct Connect						0x04

Hubs implementing this extension should treat the absence of the RP field in clients INF as the equivalent of RP with the value of one, thus implying support for BASE. If the ADCS feature is included in the clients feature list this may also be amended to include ADCS. If a client does not define an RP field the hub may choose to omit the RDEX syntax from redirects, although this is entirely optional as the extension retains backwards compatibility. If a hub defines an RP field in its own INF it should prevent its users from redirecting others to protocols it did not define in its bitmask.

The value of an RP field should be considered immutable after its initial definition, for the duration of that session, because clients and hubs alike should be able to treat the presence of an RP field as a promise that a client supports particular protocols and that hub will not redirect users to an unknown protocol (a contract between a hub and its client).

Multiple Choice Redirect

Definition: a multiple choice redirect is a redirect where instead of a single destination resource a set of resource identifiers is provided instead. The methodology that is used to select the final destination resource for aa multiple choice redirect is implementation defined. However, only one final destination resource may be chosen. For example a particular implementation may prefer one protocol over another, encrypted connection over an unencrypted one or even simply choose one at random.

This type of redirect is signaled by the presence of an additional RX field in the QUI as defined for redirects by BASE. The value of the RX field is a comma separated list of resource identifiers to use in the redirect. The RD field should be defined for maximum compatibility and clients should prepend its value to the list of identifiers in RX to use in the selection of the destination resource.

Permanent Redirect

Definition: a permanent redirect is defined as a redirect with reference updating. In the case of a permanent redirect, if and only if a successful connection is made to the destination resource, the connecting party will then update all relevant references of the original resource to the destination resource. Examples of such references may be hublist records for pingers or favorite entries for clients.

This type of redirect is signaled by the presence of an additional PT field in the QUI, as defined for redirects by BASE, with the value of one. Upon receiving such redirect clients will proceed to update references as outlined above provided the conditions are met.