RDEX - Redirects Extended rev. 2

a guest Dec 7th, 2013 56 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. RDEX - Redirects Extended
  3. 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.
  5. 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.
  7.         Protocol                        URI Syntax                                                      Flag
  8.         ADC (BASE)                      adc://adress:port                                                1
  9.         ADCS Extension                  adcs://address:port                                              2
  10.         NeoModus Direct Connect         dchub://address[:port]                                           4
  12. 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 strive to use fully qualified resource identifiers for all redirects, regardless of whether they define an RP field for themselves or not, to avoid ambiguous destinations due to implementation defined default handling.
  14. 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 does not intend to react to redirects as defined by BASE or this extension. Any attempts to redirect such clients should result in normal disconnection as per BASE. When responding to any type of redirects clients should not attempt to connect to an unreachable or otherwise invalid destination resources indefinitely or in otherwise abusive manner.
  16. Multiple Choice Redirect
  18. Definition: a multiple choice redirect is 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.
  20. 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 to use in the selection of the final destination resource.
  22. Permanent Redirect
  24. 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.
  26. 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. If the permanent redirect is from a secure to an unsecure environment sensitive information such as user passwords should not be automatically sent.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand