RDEX - Redirects Extended rev. 3

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. It also attempts to make the concept of redirects more unambiguous and less implementation defined. The two new types of redirects added are a multiple choice redirect and so-called permanent redirect as outlined below. These new redirect types are not necessarily mutually exclusive.

Redirect Security

Hubs should always aim to include an ID field, as defined by BASE, in redirect requests when possible to resolve any ambiguity about the origin of the request.

Clients should not attempt to connect to an unreachable or otherwise invalid destination resources indefinitely or in otherwise abusive manner when responding to redirects. Whether clients respond to redirects using default user information or the same information as used on the hub that initiated the redirect is implementation defined, however, in the case that the same information is used careful consideration should be taken when it comes to automatically sending sensitive information such as passwords to other hubs especially if it provides less security to the user than the original hub.

For permanent redirects in NORMAL clients may, for example, opt to use the user information referenced by the ID field to decide whether they should 'trust' the PT declaration or treat the redirect as a regular one and as such hubs should take extra care to include as much information permanent redirect requests as possible.

Accepted Redirect Protocols

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. Additional compatible values may be defined by other extensions.

	Protocol			URI Syntax					Flag
	User action (exclusive)		any supported, as defined below			 0
	ADC (BASE)			adc://adress:port				 1
	ADCS Extension			adcs://address:port				 2
	NeoModus Direct Connect		dchub://address[:port]				 4

Hubs 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 extension retains full backwards compatibility with BASE. If a hub defines an RP field for itself it should prevent its users from redirecting others to protocols it did not define, including redirects to destinations without an explicit protocol handler. Hubs should always aim to use fully qualified resource identifiers for all redirects, regardless of whether an RP field is defined or not, to avoid ambiguous destinations due to implementation defined default handling.

Clients should refrain from removing support of a previously signalled redirect protocol from their RP field. It is up to the hub to decide a corresponding course of action should the client do so. Additionally a special case is defined for clients as an RP field with the value of zero to indicate that the client may not react to redirects as defined by BASE or this extension at all or may do so only as a result of user action. As such clients defining a non-zero RP field should follow redirects to accepted protocols automatically and conversely any attempts to redirect clients that define RP as zero should result in normal disconnection as per BASE.

Multiple Choice Redirect

Multiple choice redirect is defined as a redirect where instead of a single destination resource a set of resource identifiers is provided. The methodology that is used to select the final destination resource for a 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 signalled 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 add its value to the list of identifiers defined in RX when selecting the final destination resource.

Permanent Redirect

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 signalled 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.

Example Commands

	Multiple Choice Redirect (BASE compliant)
		IQUI <own_sid> IDAAAA RDadc://example.com:1001 RXadcs://example.com:1002,adc://example.org:1020 TL30

	Multiple Choice Redirect (RDEX only, not compatible with old clients thus not recommended)
		IQUI <own_sid> IDAAAA RXadc://example.com:1001,adcs://example.com:1002,adc://example.org:1020 TL30

	Permanent Redirect
		IQUI <own_sid> IDAAAA RDadc://example.com:1001 PT1 TL30

	Permanent Multiple Choice Redirect
		IQUI <own_sid> IDAAAA RDadc://example.com:1001 RXadcs://example.com:1002 PT1 TL30