RFC relevance of structure

As per Relevance of the word structure, we have this rfc below:

Network Working Group L.
Request for Comments: 2016 P.
Category: Experimental B.
C.
M.
Bunyip Information Systems, Inc
October 1996

Uniform Resource Agents (URAs

Status of this

This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited

This paper presents an experimental architecture for an agent
that provides sophisticated Internet information access
management. Not a generalized architecture for active objects
roam the Internet, these agents are modeled as extensions of
pieces of the Internet information infrastructure. This
agent technology focuses on the necessary information structures
encapsulate Internet activities into objects that can be activated
transformed, and combined into larger structured activities

Several people have shared thoughts and viewpoints that have
shape the thinking behind this work over the past few years. We'
like to thank, in particular, Chris Weider, Patrik Faltstrom,
Mealling, Alan Emtage, and the participants in the IETF URI
Group for many thought-provoking discussions

Sima Newell provided insightful comments on the document -- thanks
her it is much more readable

This document outlines an experimental agent system architecture
was designed for the purpose of addressing high-level
activities through encapsulation of protocol-specific actions
Originally presented to the Uniform Resource Identifier (URI)
group at the IETF, this technology was seen as taking a step
resource location and resource naming. By providing a
mechanism for abstracting characteristics of desired information

Daigle, et. al. Experimental [Page 1]

RFC 2016 Uniform Resource Agents October 1996

distancing the necessary access incantations from the client,
notion of a Uniform Resource Agent (URA) was created

The evolution of Internet information systems has been
by building upon successive layers of encapsulated technologies
Machine address numbers were devised, and then encapsulated
advertised machine names, which has allowed the evolution of
Domain Name System (DNS) [RFC1034, RFC1035]. Protocols
developed for accessing Internet resources of various descriptions
and then uniform mechanisms for specifying resource locations
standardized across protocol types, were developed (URLs) [RFC1738].
Each layer of Internet information primitives has served as
building blocks for the next level of abstraction and
of information access, location, discovery and management

The work described in this paper is an experimental system
to take another step in encapsulation. While TCP/IP protocols
routing, addressing, etc, have permitted the connection
accessibility of a plethora of information services on the Internet
these must yet be considered a diverse collection of
resources. The World Wide Web effort is the most successful to
in attempting to knit these resources into a cohesive whole
However, the activity best-supported by this structure is (human
browsing of these resources as documents. The URA
explores the possibility of specifying an activity with the same
of precision accorded to resource naming and identification.
focusing on activities, and not actions, URAs encapsulate
access mechanisms based on commonality of information content,
protocol similarity

An invoker -- human or otherwise -- may delegate an entire set
tasks to a fully-instantiated URA. The nature of the tasks
completely specified by the agent, because it encapsulates
about relevant Internet resources and the information required
order to access them. In this way, URAs insulate invokers from
details of Internet protocols while allowing them to carry out high
level Internet activities (such as searching a set of web pages
news groups relevant to a given topic). Also, by formally
a high-level Internet activity in an agent, the same activity can
repeated at a later date by the same invoker, someone else or
another agent. Moreover, the agent object may easily be modified
carry out another related task

More detail describing the underlying philosophy of this
approach can be found in [IIAW95].

Daigle, et. al. Experimental [Page 2]

RFC 2016 Uniform Resource Agents October 1996

As a very simple example, consider the client task of subscribing
a mailing list. There are many mechanisms for providing users
information necessary to complete a subscription. Currently,
applications which provide the ability to subscribe to mailing
must contain protocol-aware code to carry out the task once
requisite personal data has been solicited from the user
Furthermore, any application program that embeds the ability
subscribe in its code necessarily limits the set of mailing lists
which a client can subscribe (i.e, to those types foreseen by
software's creators). If, instead, there is an agent to which
task can be delegated, all applications can make use of the agent
and that agent becomes responsible for carrying out the
interactions to complete the subscription. Furthermore, that
may be a client to other agents which can supply
information about how to subscribe to new types of mail servers, etc
URAs have been explored as an agent technology to address just
types of issues

Relationship to Other Internet

A number of Internet-aware agent and transportable code systems
become popular -- Java [JAVA], TCL [TCL] and Safe-TCL,
[TELE], and the TACOMA system [TACOMA], to name a few of them.
understand the scope of the problem that URAs tackle, it is
to understand how these systems differ from the URA approach.
of these agent systems, like Java, focus on providing mechanisms
creating and distributing (inter)active documents in the World
Web. Others, like TACOMA, have more general intentions of
environments for mobile, interacting processes

While each of these systems makes its individual contribution
solving the transportation, communication, and security
normally associated with agent systems, they yield more objects
exist within the Internet information space. That is, while they
permit individual users to have a more sophisticated interaction
a particular information resource, they do not address the
general Internet problems of naming, identifying, locating resources
and locating the same or similar resources again at a later date.
is this set of problems that URAs specifically set out to address

In order to create these URA objects that encapsulate a set
Internet activities, it is necessary to specify their
environment and design structure. Together, these form
experimental architecture for URAs, which can be evaluated in
preliminary way through a prototype implementation. The remainder
this paper describes such an experimental architecture, and

Daigle, et. al. Experimental [Page 3]

RFC 2016 Uniform Resource Agents October 1996

a prototype application built to test the concepts involved in
creation and execution of URAs

The Experimental

The main goal in designing the URA architecture was to provide
mechanism for separating client need descriptions from
specifications of mechanisms for satisfying those needs.
example, from the client's perspective, the need to find MIDI
files is quite distinct from the particular Internet resource
that might be necessary to find them at a given point in time.
one need might be best met by integrating information from
very different sources. Also, the client may have the same need on
different day, but there may be new or different resources to call
to satisfy it

A further goal was to provide very structured specifications of
Internet actions carried out by a particular URA. By making
structure of an action explicit, it becomes possible to operate
portions of an agent structure without requiring an understanding
the complete semantics of its activity

At the centre of the URA architecture is the concept of
(persistent) specification of an activity. For purposes that
become clear as the expected usage of URAs is described in
detail, we choose to support this concept with the
requirements of the architecture

- there is a formalized environment in which these
are examined and executed and otherwise manipulated. This
referred to as a URAgency

- the activity specifications are modular, and independent of
given URAgency environment. Thus, they exist as object
that can be shared amongst URAgencies. There is a
_virtual_ structure of these URA objects, although
types may exist, with different underlying implementations

Basic URAgency

In the most abstract sense, a URAgency is a software system
manipulates URA objects. In the terminology of objects, a
identifies the types of URAs it handles, and is responsible
applying methods to objects of those types. For the purposes of
experimental work, the only methods it is required to support
those to get information about a given URA, and to execute a URA

Daigle, et. al. Experimental [Page 4]

RFC 2016 Uniform Resource Agents October 1996

The expected result of applying the "get information" method to a
is a description of some or all of the URA following the
virtual structure of a URA object, outlined below

The appropriate way to "execute" a URA is to supply information
the individual URA data segments (in effect, to permit the
of an instance of a virtual object), or to identify a URA instance
Again, the information is to be supplied in accordance with
virtual structure below

A URAgency claiming to handle a particular type of URA must have
ability to map the implementation structure of that type of URA
and out of the standard virtual URA structure. The URAgency must
know how to activate the URA, and it must satisfy any
dependencies for that type of URA

For example, a URA type may consist of a Pascal program binary which
when run with particular command line arguments, yields
in the standard URA object structure. Activating this type of
might consist of executing the Pascal binary with an input
containing all the necessary data segments. A URAgency claiming
handle this sort of URA type must first be able to provide
environment to execute the Pascal binary (for whatever platform
was compiled), and also be able to interact with the Pascal
according to these conventions to get information about the URA,
execute it

As an alternative example, a URA type may consist of a script in
interpreted language, with the URA object structure embedded as
structures within the script. A URAgency handling this type of
might have to be able to parse the script to pull out the
URA object structure, and provide the script language interpreter
the purposes of executing the URA

URA Object

In order to capture the necessary information for carrying out
type of Internet activity described in the introductory paragraphs
this document, six basic (virtual) components of a URA object
been identified. Any implementation of a URA type is expected to
able to conform to this structure within the context of a URAgency

The six basic components of a URA object are

URA HEADER
Identification of the URA object, including a URA name,
and abstract, creator name, and the resources required by
URA

Daigle, et. al. Experimental [Page 5]

RFC 2016 Uniform Resource Agents October 1996

ACTIVATION DATA
Specification of the data elements required to carry out
URA activity. For example, in the case of an Internet
for "people", this could include specification of fields
person name, organization, e-mail address

TARGETS
Specification of the URL/URN's to be accessed to carry out
activity. Note that, until URN's are in common use,
ability to adjust URLs will be necessary. A key issue
URAs is the ability to transport them and activate them
from the creator's originating site. This may
implications in terms of accessibility of resource sites.
example, a software search created in Canada will
access a Canadian Archie server, and North American ftp sites
However, an invoker in Australia should not be obliged to
the URA object in order to render it relevant in Australia
The creator, then, can use this section to specify
expected type of service, with variables for the
that can be modified in context (e.g., the host name for
Archie server, or a mirror ftp site).

EXPERIENCE INFORMATION
Specification of data elements that are not strictly
in conversing with the targets in order to carry out
agent's activity. This space can be used to store
from one invocation of a URA instance to the next
This kind of information could include date of
execution, or URLs of resources located on a
invocation of the agent

ACTIVITY
If URAs were strictly data objects, specifying required
and URL/URN's would suffice to capture the essence of
composite net interaction. However, the variability
Internet resource accesses and the scope of what URAs
accomplish in the net environment seem to suggest the need
give the creator some means of organizing the instantiation
the component URL/URN's. Thus, the body of the URA
contain a scripting mechanism that minimally
conditional instantiation of individual URL/URN's.
conditions could be based on which (content) data elements
user provided, or accessibility of one URL/URN, etc. It
provides a mechanism for suggesting scheduling of URL/
instantiation

Daigle, et. al. Experimental [Page 6]

RFC 2016 Uniform Resource Agents October 1996

The activity is specified by a script or program in a
specified by the URA type, or by the URA header information
All the required activation data, targets, and
information are referenced by their specification names

RESPONSE FILTER
The main purpose of the ACTIVITY module is to specify
steps necessary to take the ACTIVATION DATA, contact
TARGETS, and collect responses from those services.
purpose of the RESPONSE FILTER module is to transform
responses into the result of the URA invocation.
transformation may be along the lines of
some text, or it may be a more elaborate
such as a relevance rating for a retrieved HTML page

The response filter is specified by a script or program in
language specified by the URA type, or by the URA
information. All the required activation data, targets,
experience information are referenced by their
names

See Appendix 1 for a more detailed description of the components of
URA. Appendix 2 contains a sample virtual URA structure

The Architecture in

Having introduced the required capabilities of the URAgency
virtual structure of URA objects, it is now time to elaborate on
tasks and interactions that are best supported by URAs

URAs are constructed by identifying net-based resources of
(targets) to carry out a particular task. The activation
component of a URA is the author's mechanism for specifying (to
invoker) the elements of information that are required for
execution . An invoker creates an instance of a URA object
providing data that is consistent with, or fills in, this template
Such an instance encapsulates everything that the agent "needs
know" in order to contact the specified target(s), make a request
the resource ("get", "search", etc.) and return a result to
invoker. This encapsulation is a sophisticated identification of
task results

For example, in the case of a mailing list subscription URA,
creator will identify the target URL for a resource that handles
subscription (e.g., an HTML form), and specify the data required
that resource (such as user name, user mail address, and mailing
identifier). When an invoker provides that information
instantiates the URA, the resulting object completely

Daigle, et. al. Experimental [Page 7]

RFC 2016 Uniform Resource Agents October 1996

all that is needed in order to subscribe the user -- the
result is identified

URAs are manipulated through the application of methods. This,
turn , is governed by the URAgency with which the invoker
interacting. However, because the virtual structure of URAs
represented consistently across URA types and URAgencies, a
can act as one of the targets of a URA. Since methods can be
to URAs remotely, URAs can act as invokers of URAs. This can yield
complex structure of task modules

For example, a URA designed to carry out a generalized search
book-selling resources might make use of individual URAs tailored
each resource. Thus, the top-level URA becomes the orchestrating
for access to a number of disparate resources, while being
from the minute details of accessing those resources

A Prototype

The experimental work with URAs includes a prototype
of URA objects. These are written in the Tcl scripting language.
sample prototype Tcl URA can be found in Appendix 3.

The URAgency that was created to handle these URAs is part of
Silk Desktop Internet Resource Discovery tool. Silk provides
graphical user interface environment that allows the user to
and search for Internet information without having to know where
look or how to look. Silk presents a list of the available URAs
carry out these activities (e.g., "search for tech reports"
"hotlist"). For each activity, the user is prompted for
activation data, and Silk's URAgency executes the URA. The
software also supports the creation and maintenance of URA
instances. Users can add new URAs by creating new Tcl scripts (
the guidelines in the "URA Writer's Guide", available with the
software. See [SILK]). The Silk graphical interface hides some
the mechanics of the underlying URAgency. A more directly-
version of this URAgency will become available

This work was originally conceived as an extension to the family
Uniform Resource Identifiers (URIs): Uniform Resource
(URLs), Uniform Resource Characteristics (URCs), and the
Uniform Resource Names (URNs). The approach of formalizing
characteristics of an information task in a standardized
structure is seen as a means of identifying a class of resources,
contributes to the level of abstraction with which users can refer
Internet resources

Daigle, et. al. Experimental [Page 8]

RFC 2016 Uniform Resource Agents October 1996

Although still in its experimental stages, this work has
evoked interest and shown promise in the area of providing
for building more advanced tools to interact with the Internet at
more sophisticated level than just browsing web pages

One of the major difficulties that has been faced in developing
collection of URAs is the brittleness induced by interacting
services that are primarily geared towards human-users.
changes in output formats that are easily discernible by the
eye can be entirely disruptive to a software client that must apply
parsing and interpretation mechanism based on placement of cues
the text. This problem is certainly not unique to URAs --
software acting upon results from such a service is affected
Perhaps there is the need for an evolution of "service entrances"
information servers on the Internet -- mechanisms for getting "
the facts" from an information server. Of course, one way to
such access is for the service provider to develop and distribute
URA that interacts with the service. When the service's
changes, the service provider will be moved to update the URA
was built to access it reliably

Work will continue to develop new types of URAs, as well as
URAgencies. This will necessitate the creation of
interaction standards -- the "common virtual URA object structure"
the first step towards defining a lingua franca among URAs
disparate types and intention

Daigle, et. al. Experimental [Page 9]

RFC 2016 Uniform Resource Agents October 1996

[IIAW95] Leslie L. Daigle, Peter Deutsch, "Agents for
Information Clients", CIKM'95 Intelligent Information
Workshop, December 1995.
Available

[JAVA] "The Java Language: A White Paper" Available
overview/java/index.html

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.

[RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform
Locators (URL)", RFC 1738, December 1994.

[SILK] Bunyip's Silk project homepage

[SILKURA] Silk URA information

[TACOMA] Johansen, D. van Renesse, R. Schneider, F. B., "
Introduction to the TACOMA Distributed System", Technical
95-23, Department of Computer Science, University of Tromso
Norway, June 1995.

[TCL] Ousterhout, J. K. "Tcl and the Tk Toolkit", Addison Wesley
1994.

[TELE] White, J. E., "Telescript Technology: The Foundation for
Electronic Marketplace", General Magic White Paper, General
Inc., 1994.

Daigle, et. al. Experimental [Page 10]

RFC 2016 Uniform Resource Agents October 1996

Authors'

Leslie
Peter
Bill
Chris
Mary

Bunyip Information Systems, Inc
310 St. Catherine St.
Suite 300
Montreal, Quebec,
H2X 2A

Phone: (514) 875-8611
EMail: ura-bunyip@bunyip.

Daigle, et. al. Experimental [Page 11]

RFC 2016 Uniform Resource Agents October 1996

Appendix 1 -- Virtual URA

This appendix contains a BNF-style description of the
virtual structure of a URA object. This "virtual structure" acts
the canonical representation of the information encapsulated in
given URA. It is expected that more information may optionally
contained in the elements of the components -- the elements
here are offered as the "minimum" or "standard" set

N.B.:
[]-delimited items are
%% denotes a
\0 represents the empty
| is "or
{} are literal

This form is used for convenience and clarity of expression --
whitespace and ordering of individual elements are not
significant

:= {structure>}

structure> := { URAHDR }
{ ACTDATA <activation-data> }
{ TARG }
{ EXPINFO <experience information> }
{ ACTSPEC <activity> }
{ RESPFILT <response filter> }

:= { name }
{ author }
{ version }
[ { lang } ]
[ { parent instance> } ]

<activation-data> := <activation-data> | \0

:= {
{ name }
{ response }
{ prompt }
[ { required } ]
[ { default } ]
}

:= | \0

Daigle, et. al. Experimental [Page 12]

RFC 2016 Uniform Resource Agents October 1996

:= {
{ name }
{ protocol protocol> }
{ url }
[ { specific-data> } ]
}

:= <complete-url> |
<complete-url> := %% a complete, valid URL
(e.g., http://www.bunyip.com/)

:= {
{ scheme }
{ host }
[ { port } ]
{ selector selector-spec> }
}

:= {
{ name }
{ response }
{ prompt }
}
:= {
{ name }
{ response }
{ prompt }
}
:= {
{ name }
{ response }
{ prompt }
}
selector-spec> := {
{ name <selector-name> }
{ response <selector-value> }
{ prompt <selector-prompt> }
}

<experience information> := {
{ name }
{ response }
}

<activity> :=

Daigle, et. al. Experimental [Page 13]

RFC 2016 Uniform Resource Agents October 1996

<response filter> :=

%% Without requiring more detail...

:= \n | \0
:= 0 | 1
:= := := := instance> := := := := := := := protocol> := http-get | http-post | ...
specific-data> := := := := := := := := := := selector-name> := selector-value> := selector-prompt> :=
Appendix 2 -- Sample Virtual

A valid virtual representation of a Silk Tcl URA is presented below
The actual URA from which it was drawn is given in Appendix 3.

{
{name {DejaNews Search}}
{author {Leslie Daigle}}
{version {1.0}}
}

{
{name {Topic Keywords}}

Daigle, et. al. Experimental [Page 14]

RFC 2016 Uniform Resource Agents October 1996

{prompt {Topic Keywords}}
{response {}}
}

{
{name {Comments}}
{prompt {Comments}}
{response {}}
}

{
{proc mapResponsesToDejanews {} {
set resp ""
if {[uraAreResponsesSet {Topic Keywords}]} {
lappend resp [list query [uraGetSpecResponse {
Topic Keywords}]]
}

return $

}
proc uraRun {} {
global

foreach serv [uraListOfServices] {
set u [uraGetServiceURL $serv

switch -- $serv {
dejanews {
if [catch {
set query [mapResponsesToDejanews
if {$query != {}} {
set result [uraHTTPPostSearch $u $query
if {$result != ""} {
set list [dejanews_
$result
puts $
}
}
}] {
puts stderr $
}
}

default {
# can't handle other searches, yet
} } } }
}

Daigle, et. al. Experimental [Page 15]

RFC 2016 Uniform Resource Agents October 1996

}

{
{
proc dejanews_uraHTTPPostCanonicalize {htmlRes} {

set result {}
set lines {}
set clause {}
set garb1 ""
set garb2 ""

# Get the body of the result page -- throw away leading
# trailing

regexp {([^
]*)
(.*)
.*}
$htmlRes garb1 garb2

set lines [split $mainres "\n"]

foreach clause $lines {

if [
{
.*(..\/..).*([^<]*).*([^<]*).*}
$clause garb1 dt relurl desc grp] {

lappend r [list HEADLINE [format "%s (%s, %s)"
[string trim $desc] \
[string trim $grp] $dt]]
lappend r [list URL [
"http://www.dejanews.com/cgi-bin/%s" $relurl]]
lappend r [list TYPE "text/plain"]

lappend result $
}
}
return $
}
}

}

Daigle, et. al. Experimental [Page 16]

RFC 2016 Uniform Resource Agents October 1996

Appendix 3 -- Sample Silk Tcl

The following is a valid Silk Tcl URA. For more information on
implementation and structure of Silk-specific URAs, see the "
Writers Guide" that accompanies the distribution of the Silk
(available from ).

# ----------------------------------------------------------------------

# URA

# ----------------------------------------------------------------------

# Initialize the URA, its search specs and searchable services

# URA init

set uraDebug 1

uraInit {
{name {DejaNews Search}}
{author {Leslie Daigle}}
{version {1.0}}
{description "This URA will search for UseNet News articles."}
{help "This is help on UseNet News search script."}

# bug: handling of choices/labels is kind of gross

# Search spec. init

foreach item {
{
{name {Topic Keywords}}
{field Topic
{tag STRING
{description {Keywords to search for in news articles}}
{prompt {Topic Keywords}}
{help {Symbols to look up, separated by spaces.}}
{type STRING
{subtype {}}
{allowed .*}
{numvals 1}
{required 0}

Daigle, et. al. Experimental [Page 17]

RFC 2016 Uniform Resource Agents October 1996

{response {}}
{respset 0}
}
} {
uraSearchSpecInit $

uraAnnotationInit {
{help {Enter comments to store with an instance}}
{numvals 1}
{subtype {}}
{response {}}
{name Comments
{required 0}
{class ANNOTATION
{type TEXT
{description {General comments about this URA.}}
{respset 1}
{prompt Comments
{field {}}
{allowed .*}

uraResultInit {
{name {Related Pages}}
{contents { {
{HEADLINE {The DejaNews UseNet search service}}
{TYPE text/plain
{URL http://www.dejanews.com
} }}

foreach item {
{
{name dejanews
{protocol http-post
{url http://marge.dejanews.com/cgi-bin/nph-dnquery
}
} {
uraServicesInit $

proc dejanews_uraHTTPPostCanonicalize {htmlRes} {

set result {}
set lines {}

Daigle, et. al. Experimental [Page 18]

RFC 2016 Uniform Resource Agents October 1996

set clause {}
set garb1 ""
set garb2 ""

# Get the body of the result
# -- throw away leading and trailing
regexp {([^]*)
(.*)
.*} $htmlRes garb1 garb2

set lines [split $mainres "\n"]

foreach clause $lines {

uraDebugPuts stderr [format "Line: %s" $clause

if [
{
.*(..\/..).*([^<]*).*([^<]*).*} \
$clause garb1 dt relurl desc grp] {
uraDebugPuts stderr [
"Date: %s Rel URL: %s Desc: %s Group: %s
$dt $relurl $desc $grp

lappend r [list HEADLINE [format "%s (%s, %s)"
[string trim $desc] \
[string trim $grp] $dt]]
lappend r [list URL [
"http://www.dejanews.com/cgi-bin/%s" $relurl]]
lappend r [list TYPE "text/plain"]

lappend result $
}
}
return $

# ----------------------------------------------------------------------

# Mapping

# ----------------------------------------------------------------------

# There is one procedure, for each searchable service, to map the
# spec responses to a form suitable for inclusion into a search URL (
# whatever form the particular query procedure accepts).

Daigle, et. al. Experimental [Page 19]

RFC 2016 Uniform Resource Agents October 1996

proc mapResponsesToDejanews {} {
set resp ""
if {[uraAreResponsesSet {Topic Keywords}]} {
lappend resp [list query [uraGetSpecResponse {Topic Keywords}]]
}

return $

# bug: need better error
# (i.e. which searches didn't work and why, etc.)

proc uraRun {} {
global

foreach serv [uraListOfServices] {
set u [uraGetServiceURL $serv

switch -- $serv {
dejanews {
if [catch {
set query [mapResponsesToDejanews
uraDebugPuts stderr [format "%s: query is `%s'."
$serv $query
if {$query != {}} {
set result [uraHTTPPostSearch $u $query
if {$result != ""} {
uraDebugPuts stderr [format "%s: result is `%s'."
$serv $result
set list [dejanews_uraHTTPPostCanonicalize $result
uraDebugPuts stderr [format "%s: list is `%s'."
$serv $list
puts $
}
}
}] {
puts stderr $
}
}

default {
# can't handle other searches, yet
}

Daigle, et. al. Experimental [Page 20]

RFC 2016 Uniform Resource Agents October 1996

}
}

Daigle, et. al. Experimental [Page 21]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX