Network Working Group                                        Keith Moore
Internet-Draft                                   University of Tennessee
Expires: 28 August 2002                                 28 February 2002

                          The Resource Catalog


This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

Comments regarding this internet-draft should be sent to the mailing
list of the IETF rescap working group.  Refer to the IETF web site at for current contact information for IETF working
groups.  Please include the document identifier
"draft-moore-rescap-rc-01.txt" in any comments regarding this document.


This memo describes version 3 of the Resource Catalog.  The Resource
Catalog (RC) is a service for storing and obtaining metadata that
describes network-accessible resources.  This service is primarily
intended for use by clients prior to accessing, or attempting to access,
a particular resource.  The RC service may thus be used (for example) to
inform a client as to which of a variety of features are supported by
the resource, or which methods may be used to access the resource, or
which of a small set of locations may be used to access the resource.

1. Introduction

This memo describes version 3 of the Resource Catalog.  The Resource
Catalog is a service for storing and obtaining metadata that describes

Moore                    Expires 28 August 2002                 [Page 1]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

network-accessible resources.   This service is primarily intended for
use by clients prior to accessing, or attempting to access, a particular
resource.  The RC service may thus be used (for example) to inform a
client as to which of a variety of features are supported by the
resource, or which methods may be used to access the resource, or which
of a small set of locations may be used to access the resource.

A 'network-accessible resource' is potentially any resource which is
accessible on the network and which has a distinguished name (probably a
URI) by which the metadata can be queried.  Such resources could
potentially include downloadable files, web pages, electronic mailboxes
(including voice and fax mailboxes), instant messaging mailboxes, real-
time text, voice, and/or video conferencing terminals, hosts, routers,
etc.  'Metadata' are represented as name-value pairs, each of which
describes some aspect of the resource.

NB:  The above examples of resources are intended only as illustration
of the flexibility of this approach. It is not expected that RC would,
if adopted, be used in all of these contexts (or for that matter, in any
particular context.)  Each application or service using RC as a
component would need to have an explicit definition for the metadata and
specific use of RC within that application or service, prior to
deployment of code.

Earlier versions of the Resource Catalog were designed for use in
research projects dealing with replicating network-accessible content
and distributed software repositories.  This version of the Resource
Catalog builds on experience with those earlier efforts, and is intended
to be suitable for standardization and widespread deployment.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document are to be interpreted as described in [1].

2. Design Goals and Implications

Given the overall intended purpose of the service as described above
(and in the charter of the rescap working group) RC version 3 was
designed with several specific goals in mind.  These are reflected in
the protocol design as follows:

2.1. Federation

Ideally, the owner of a resource being described should be able to
control the metadata used to describe that resource within RC.  Such
control would be hampered if RC were a centralized service; this would
also impact RC's scalability.  It is therefore desirable for the owner
to be able to control both the cost and the quality of the RC service

Moore                    Expires 28 August 2002                 [Page 2]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

which describes his/her/its resources.

The RC service is therefore federated according to resource name; it is
assumed that the network addresses of the servers that provide
authoritative metadata describing a particular named resource are
somehow obtainable from that name.  RC uses NAPTR [2] and SRV [3]
records to locate the RC servers for URIs which contain embedded DNS
names.  Similar mechanisms would need to be defined for other kinds of
resource names (as for instance the URN working group is defining
resolution mechanisms for URNs, and the ENUM working group is currently
defining a means of finding metadata associated with telephone numbers).

This approach further allows the maintainer of a DNS zone to specify the
locations of RC services for resource names for which the SRV records
are located in that zone; thus, the RC servers corresponding to a
particular resource name can be provided locally, outsourced, or some of
each.  This further implies that "RC service provider" and "resource
owner" are different roles, and that the capability to manipulate
resource attributes must therefore be delegated to the resource owner
through a standard interface.

The need to be able to outsource RC services also implies that an RC
query must self-contained, i.e. that no part of the question being asked
is implicit in the choice of a server to which the question is being

It is of course likely that the owner of a resource does not control all
of the DNS zones which are traversed in the process of finding the RC
servers for a resource name.  And while it is hoped that DNS names will
continue to be easily obtainable and inexpensive, some kinds of resource
names (such as URNs) inevitably lessen owner control of the resource
name in order to obtain increased stability of those names.  For this
reason, and because the RC service provider may be independent of the
resource owner, RC provides the capability for resource owners to
digitally sign any of the metadata associated with a resource.

2.2. Fast response to client queries

As RC is intended for use prior to accessing a resource, RC queries will
tend to increase the overall time required to access that resource.  It
is therefore essential that RC provide fast response.  This implies that
server operations should be cheap in terms of CPU cycles.  It further
implies (in the case of low bandwidth links) that payloads and protocol
overhead are small and (in the case of long delay links) that
unnecessary round-trips are avoided.

To this end, RC queries are designed to run over UDP and to require a
single UDP datagram in each direction.  Servers MAY also support TCP as

Moore                    Expires 28 August 2002                 [Page 3]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

a transport.  RC is also optimized for small payloads, and it attempts
to impose minimal protocol overhead.  RC also provides a number of
features designed to minimize the transmission of unnecessary response
data, including the ability to query several named attributes in a
single transaction, and the ability to specify whether signatures (and
which types of signatures) should be returned with the response.

2.3. Scalability to large numbers of reading clients

If RC is used to provide essential metadata for heavily-used resources
it potentially imposes a barrier to access of those resources.  The
scalability of access to those resources would thus be limited by the
scalability of RC.  It is therefore necessary that RC be scalable to
handle large numbers of reading clients.   RC attempts to achieve this
by being implementable with minimal server overhead, and by allowing RC
queries to be distributed over several replicated RC servers, with a
well-defined model for consistency between servers.

2.4. Ease of implementation

In order to allow for quick deployment, the RC protocol is designed to
be simple and easy to implement, and for simple implementations to
perform acceptably on modern CPUs with moderate workloads.  However it
is naturally expected that high performance implementations will be more
complex and more difficult to implement.

2.5. Security

RC is designed with consideration of the following security threats:

-    Attempts by unauthorized parties to write metadata to servers.

     RC servers require writers (and optionally readers) to authenticate
     themselves via secure means; such requests will not be processed
     unless the authentication credentials can be verified.

-    Attempts to obtain authentication credentials via the network, via
     active or passive attacks.

     The RC protocol allows for multiple authentication methods in order
     to accommodate the needs of different environments, and to
     accommodate additional authentication methods which might be
     defined in the future.

-    Attempts to replay a previously successful write request for the
     purpose of modifying metadata in unauthorized ways.

Moore                    Expires 28 August 2002                 [Page 4]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     Requests to update metadata include a serial number which must
     always be larger than the serial number of the previous request to
     update the metadata for that resource.  This serial number is
     authenticated and checked for integrity along with the rest of the
     request.  Attempts to replay write requests can therefore be
     detected, and unauthorized changes to the metadata avoided.

-    Attempts to add, delete, or alter data in a response

     RC allows (but does not require) writers to cryptographically sign
     metadata that are stored in a server.  Reading clients may (but are
     not required to) request such signatures, attempt to verify them,
     and determine whether the party signing the metadata is authorized
     to make such assertions about the resource.  However such
     signatures are opaque to RC servers; the RC protocol does not
     attempt to verify signatures that are stored with a resource.

     When TLS [4] is used, the integrity protection provided by TLS will
     allow a client to detect responses altered in transit.  However
     there is no requirement that TLS be used; furthermore, the protocol
     setup and server CPU overhead associated with TLS serve as
     disincentives to use of TLS.

-    Removal of signatures from responses

     When TLS is used, the integrity protection provided by TLS will
     allow a client to detect responses altered in transit.  However
     there is no requirement that TLS be used and there are
     disincentives to use TLS.

     NOTE: The protocol described in this document, could, with a very
     small modification, allow clients to request server-provided
     signatures on responses.  Such signatures would not authenticate
     the response as coming from an authoritative source, but would
     serve to thwart this and other attacks that alter responses.  If
     used frequently, such a facility would greatly increase server
     load, but probably no worse than if TLS were used frequently.  On
     the other hand, to be effective this would also require that the
     client have a secure means of knowing that a server signature on
     the response should be expected, and a means of verifying that

Moore                    Expires 28 August 2002                 [Page 5]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

RC does not attempt to ameliorate the following threats:

-    Attempts to direct clients to send queries to unauthorized servers

     Even if unauthorized servers contain data which are signed by
     authoritative sources, the data provided by unauthorized servers
     may be stale or obsolete.

     When DNS SRV and address records are used to direct queries to RC
     servers, DNSSEC may be useful in authenticating such records to

     NOTE: TLS server certificates could be used by the client to
     determine whether the server can authentically claim to operate on
     behalf of a particular DNS name.  However, authority to operate on
     behalf of a DNS name does not necessarily imply authority to supply
     information about a resource name, particularly when the server
     operator may not be authoritative to make assertions about a
     particular resource, even if the server is the correct one to
     consult for information about that resource.  (e.g. the RC service
     might be outsourced)

-    Repudiation of unsigned assertions

-    Alteration of unsigned responses

-    Threats which require physical access to server hardware

-    Attempts to interfere with service by interfering with the
     transmission of requests or responses over the network

-    Attempts to interfere with service by flooding the server with

2.6. Provision for proxies

Due to the large number of environments which separate local users from
the public Internet with firewalls, and the anticipated use of this
protocol to describe public Internet resources, it is essential that RC
be usable through intermediaries.

2.7. Flexibility

RC is intended as a framework which can be used by a wide variety of
applications and services, to store information about many different
kinds of resources.  The protocol therefore needs to be flexible enough
to accommodate different applications' needs regarding (for instance)
metadata size, rates of change, and security.

Moore                    Expires 28 August 2002                 [Page 6]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

The feature-set included in RCv3 was selected based on observations from
other information query protocols which have been in use for many years,
as well as experience with earlier versions of RC.

DNS  Though the resemblance may not be obvious, in many ways RC is
     heavily influenced by DNS [5].  Like DNS, RC is federated, handles
     multiple query types, and provides the ability to return
     "additional information" in response to a query.  In addition, both
     RC and DNS provide signatures and the capability to support
     multiple signature types. RC and DNS have similar models for
     replication, with the RC replication granularity being that of a
     resource name and the DNS replication granularity being that of a

     However, RC attempts to generalize a number of DNS features.  In
     particular, RC servers have no knowledge of the characteristics of
     attribute names (corresponding to DNS resource record types and
     query types).  RC servers determine whether to perform "additional
     information" lookups based on explicit instructions in the query,
     rather than based on knowledge of the attribute name.  Neither do
     RC servers have knowledge of signature types; signatures are opaque
     to the servers. Server processing of signatures in RC is limited to
     storing signatures that are supplied by writers and returning
     signatures to readers who ask for them.  Finally, RC decouples the
     notion of "server ownership" from "resource name ownership" - the
     owner of the server is not inherently considered an authoritative
     source of information about any particular resource.

SNMP In some ways the service provided by RC is similar to that of an
     SNMP [6] agent.  In particular, RC borrows from SNMP the capability
     to query aggregates of individually addressable resource
     attributes, where the aggregates are based on the structure of the
     names.  However whereas SNMP uses ASN.1 object-identifiers (OIDs)
     for attribute names, RC uses human-readable ASCII strings.  RC also
     separates resource names from attribute names rather than combining
     the two into a single name.  Finally, RC lacks an analog to SNMP's
     trap mechanism, RC's information model is simpler than SNMP's SMI,
     and RC uses a simple presentation layer and RPC mechanism in
     contrast to SNMP's ASN.1 PDUs.

LDAP RC is heavily influenced by LDAP [7] in that RC avoids many of the
     design choices in LDAP which impose a barrier to the use of LDAP in
     applications for which RC is designed.  In particular,

     -    RC allows the use of UDP to avoid the delay and bandwidth
          consumption associated with TCP connection setup

Moore                    Expires 28 August 2002                 [Page 7]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     -    RC uses a simpler data model than ASN.1, and a simpler
          presentation encoding than BER, for ease of implementation and
          improved processing efficiency

     -    RC provides lookup by resource name, but not searching of
          contents, for server efficiency and scalability

     -    RC provides the ability to query for and return "additional
          information" based on results of the initial query, thus
          avoiding multiple round-trips

     -    RC has support for caching of data returned from queries

     -    RC defines a model for consistency between replicas which is
          usable by applications

3. Data Model

3.1 Format of resource descriptions

RC models the description of a resource (its "metadata") as a set of
(name, value) pairs called assertions.  Each assertion consists of:

-    an attribute name, which is a human-readable character string;

-    a value, which is often human-readable, but can potentially be any
     sequence of octets;

-    an optional time-to-live; and

-    an optional expiration-date.

The time-to-live is some number of seconds from the present time during
which the assertion is expected to remain valid.  The expiration-date is
an absolute time at which the assertion will no longer be valid.  Both
time-to-live and expiration-date may be supplied, in which case both
limitations to the validity of the assertion apply.  This allows an
assertion to expire "gracefully" at a particular time without the server
having to explicitly decrease times-to-live as the expiration time
approaches; it also allows the expiration time to meaningful in a signed

3.1 Caching

Intermediaries (e.g. proxies) MAY cache assertions and return cached
assertions in response to queries for specific resource_names during the
expected lifetime of the assertions.  However, all cached assertions
about a resource_name which are returned in a query response MUST have

Moore                    Expires 28 August 2002                 [Page 8]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

been obtained from the same version of the description of that resource.
Intermediaries MUST NOT return cached responses to wildcard queries
unless those responses were returned from an earlier wildcard query of
greater or equal scope (i.e. a shorter prefix of the resource name) than
the current query.

3.2 Consistency between replicas

RC services for a particular portion of URI-space MAY be replicated so
that queries, updates, or other operations within that portion of URI-
space can be issued to any of the replicas.  A standard mechanism for
replication between servers is not yet defined, but individual
implementations MAY define their own mechanisms for doing so.

When the description of a resource is replicated between RC servers, the
servers MUST maintain the appearance of a linear change history for the
entire resource description across all of the servers.  In other words,
it is not acceptable for separate changes to be made to different
replicas of the resource description.  Servers MAY impose requirements
on writers in order to facilitate this (e.g. they may require that all
updates be sent to a single master server).

Replicated RC servers SHOULD make reasonable efforts to be synchronized
with one another.

3.3 Permission model

RC is intended for the dissemination of public information.  It is
possible for servers to refuse to answer queries sent by non-
authenticated parties or to specific parties who authenticate
themselves, and it is possible for servers to omit information from the
responses of queries sent by unauthorized parties.  Until the effect of
such restrictions on caching is understood, servers SHOULD NOT restrict
the ability of parties to query information.

RC servers which support the Update operation MUST be able to prevent
unauthorized parties from updating information about a particular
resource; however, the granularity with which this is done is not
currently defined.  Servers MAY restrict the ability to update
particular resource names, as well as particular attribute names.
However, perhaps unfortunately, the currently defined status reporting
mechanism provides little information about why an update attempt

4. Protocol

The protocol is defined in terms of RPC operations.  Each operation is
defined in terms of an request structure, result structure, and side-

Moore                    Expires 28 August 2002                 [Page 9]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

effects that take place when a valid request is received.  The
structures are defined using the example abstract syntax from the Binary
Low-Overhead Block (BLOB) protocol (see [8], Appendix B), and BLOB is
used as a presentation format.

The first scalar integer of each request is used as a request_type. This
allows different types of requests to be distinguished from one another.
The first string of each request is a request_id which is used to
associate responses with requests.

The first scalar string of each response is the request_id from the
request.  The first scalar integer of each response is the status of the

4.1 Protocol Evolution and Version Negotiation

For most purposes, RC is designed to be used in a stateless manner,
without the need for an explicit "connection setup".  Explicit
negotiation of the RC protocol version or features between client and
server would increase the time required to perform RC operations.  To
the extent feasible, new versions of RC should continue to support
request_types from previous versions of the protocol.  If it is
important to make clients aware of new server features, it might be
preferable to advertise such information to clients via SRV or NAPTR DNS
records rather than to force the client to negotiate a protocol version
on each interaction with an RC server.

However, the request_type field of each request can be considered to
contain an implicit version number.  If it becomes necessary for future
versions of RC to deprecate existing request_types, servers can return a
RC_PROTO_MISMATCH response to any unsupported request_type.  This
response contains both protocol version information and a list of
supported request_types.

Request_type 0 is reserved and can be used by a client to force an
Unsupported Request response to be returned.

4.1.1 Unsupported request response structure

The Unsupported Request response structure is as follows:

     BEGIN unsupported_request_response
     string request_id
     int status
     int protocol_version
     int<> supported_requests

Moore                    Expires 28 August 2002                [Page 10]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

This structure is returned in response to any request with an unsup-
ported request_type.

     This is the request_id from the request.

     This will normally be RC_UNSUPP_REQUEST.

     This is the highest version of the RC protocol supported by the
     server.  This document describes version 3.

     This is an array of integers indicating the range of request_types
     supported.  The integers are in pairs indicating higher and lower
     bounds of a range of supported request_types.  For instance, an
     integer array [ 1 4 6 6 10 12 ] would indicate that request_types
     1-4 inclusive, 6, and 10-12 inclusive were the only ones supported.

     Note on caching of supported request_types: In principle servers
     can be up- or downgraded at any time and with no notice.  It is
     therefore not safe for a client to assume that the set of
     request_types supported by a server will remain constant.  Clients
     MUST therefore be prepared to handle a RC_UNSUPP_REQUEST in
     response to any request which is not required by this specifica-
     tion.  For a client which can utilize additional request_types if
     they are supported by the server, a cached list of request_types
     may prove to be a useful performance optimization.  In order to
     allow clients to discover new server request_types in a timely
     fashion, clients which can utilize additional request_types (beyond
     those which are required of servers) SHOULD discard cached
     request_types after a suitable interval, say a few hours.

4.2 Operations

The following operations are defined:

4.2.1 Query operation

The Query operation returns information describing the named resource. Query request structure

The Query request structure is defined as follows:

Moore                    Expires 28 August 2002                [Page 11]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     BEGIN query_request
     int request_type               # QUERY=1
     string request_id
     string resource_name
     string<> attribute_names
     int<> attribute_flags
     # QUERY_RECURSE = 01
     int<> signature_types

The meanings of the individual fields are outlined below.

     A request_type of 1 indicates a Query request.

     The request_id is used to associate the response with the request.
     This is a string which is chosen to be unique for the client's IP
     address and port pair, for any amount of time during which any
     request from that host and port pair is likely to be pending or
     during which a response may be traveling through the network. It is
     RECOMMENDED that request_ids not be reused within at least an hour.

     The contents of the request_id are otherwise undefined; client
     implementations MAY generate them however they wish.  (however see
     the Security Considerations section).

     The name of the resource for which information is being requested;
     for instance, a URI.  This field MUST be present.

attribute_names, attribute_flags
     These fields are parallel arrays.  attribute_names specifies the
     names of the attributes which are being requested for the resource,
     while attribute_flags specifies optional query features desired for
     each attribute_name.  attribute_flags[i] thus specifies the
     optional query features for attribute_names[i].  These two arrays
     MUST have the same number of elements, and servers MUST return an
     RC_DATA_FMT error in response to a Query operation for which the
     number of elements in these two arrays is different.

     Currently defined attribute_flags are as follows:

     -    The QUERY_RECURSE bit controls searching for additional
          information; see section below.

Moore                    Expires 28 August 2002                [Page 12]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     -    The WANT_SIGNATURES bit requests signatures for this
          attribute; see section for a discussion of signatures.

     These flag bits can be ORed together to request both features.

     Note: as hinted in section 2.5, a WANT_SERVER_SIGNATURE bit could
     be added here to request that the server sign the response.  This
     would provide some protection against attacks that modify the
     response but would not by itself guarantee that the response came
     from an authoritative party.

     An attribute_name that ends in "*" is a wildcard; see section

     The list of signature_types which are understood by the caller.
     Values for individual signature_types are to be defined. Query result structure

The Query result structure is as follows:

     BEGIN query_response
     string request_id
     struct<> answers

     This is the request_id from the Query structure, used to associate
     the response with the request.

     The list of answers.  Each answer contains the results of the query
     for a particular resource_name.  The first answer is the one for
     the resource_name which was explicitly part of the Query structure.
     Any additional answers are the result of additional queries
     requested via the QUERY_RECURSE flag.

Moore                    Expires 28 August 2002                [Page 13]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002 Answer structure

Each Answer is formatted as a blob using the following structure:

     BEGIN answer
     string resource_name
     int query_status
     int version_hi
     int version_lo
     struct<> assertions
     struct<> signatures

Within an answer are the following fields:

     The resource_name for which the following assertions are made.

     A code describing the result of the attempt to query this
     resource_name.  See section 3.5.

version_hi, version_lo
     An 8-byte version number (treated as a single 8-byte integer, but
     represented for the purpose of presentation as two 4-byte integers)
     for the resource information.  The version number increases (not
     necessarily by 1) each time the resource is modified.

     This is an array of blobs, each of which contains information about
     the named resource.  The structure of an assertion is defined

     This is an array of blobs, each of which contains a signature over
     some set of assertions.  The structure of signatures is defined

Moore                    Expires 28 August 2002                [Page 14]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002 Assertion structure

An assertion has the following structure:

     BEGIN assertion
     string name
     string value
     int ttl
     int expire_date_lo
     int expire_date_hi
     int flags

name This is the name of the attribute.

     This is the value associated with the attribute name.

ttl, expire_date_*
     The ttl and expire_date describe the lifetime during which the
     information is expected to be valid (and during which it may be
     cached by intermediaries).

     The ttl field is the number of seconds during which the assertion
     is expected to be valid; if the ttl field is 0x7fffffff (2**31 - 1)
     then no TTL is assumed.

     The expire_date_* fields contain an absolute expiration date.
     expire_date_hi contains the day of expiration, expressed as the
     number of whole days (60*60*24 second periods) since Jan 1, 1970
     UTC.  expire_date_lo contains the number of seconds within the day
     following the number of days in expire_date_hi.  Any leap days
     which have occurred or will occur prior to the expiration date are
     included in expire_date_hi. Any leap seconds which have occurred or
     will occur prior to the expiration date are included in
     expire_date_lo.  Note that expire_date_lo can therefore be greater
     than 86400 seconds.  However most applications will not need that
     degree of precision, and most applications cannot count on having
     their clocks synchronized to that degree of precision.  An
     application supplying expiration dates to RC MAY fail to consider
     leap seconds in its calculations if the loss of precision is not
     considered significant for that application. If expire_date_hi and
     expire_date_lo are both zero, no expiration date is assumed.

     These are single-bit characteristics of the attribute. They are for
     future use.

Moore                    Expires 28 August 2002                [Page 15]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002 Signature structure

Signatures which can be used to verify authenticity and integrity of the
assertions.  Each signature is a blob formatted according to the
following structure:

     BEGIN signature
     int<> component_list
     int algorithm
     struct bits

     This is an ordered list of the indices, relative to the start of
     the assertions array from the answer, of the assertions that are
     signed by this signature.  The first assertion of the answer is
     always index 0, even even if the implementation language uses one-
     based arrays.

     Note that the contents of the assertions are signed, and the
     indices are NOT signed.  The indices have no significance outside
     of a particular Answer to a Query.

     This is an integer which specifies both the method for translating
     a resource_name, version_hi, version_lo, and an ordered list of
     assertions into a single linear octet string, and the digital
     signature algorithm used to create and verify the signature.

bits This is the actual signature, formatted according to the algorithm
     defined by the signature algorithm.

A signature is verified by concatenating the names and values of the
assertions in a manner specified by the signature algorithm, and then
verifying the result of that concatenation against the bits field, again
according to the manner specified by the signature algorithm.  NOTE: ttl
fields of assertions are NOT considered in signature calculations. Recursive Processing

If the QUERY_RECURSE bit of attribute_flags[i] is set, it signifies that
if any attribute_values matching attribute_names[i] are found, they are
to be interpreted as resource_names, and additional queries (using the
same set of attribute_names and attribute_flags as the original query)
are performed for those resource names.  The server may decline to
service such "additional information" requests for any reason, including
for example that the server does not have authoritative information for

Moore                    Expires 28 August 2002                [Page 16]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

the resource name, or the query is being made by UDP and the result does
not fit within a reasonable UDP packet size, or processing of the
additional query would likely cause the caller's retransmission timer to

It is possible that an attribute_value of some answer will contain a
resource_name for which results have already been obtained while
processing this request (either because the resource_name was explicitly
listed in the query or because it appeared in the result of a field for
which QUERY_RECURSE was set).  Servers MUST NOT return multiple sets of
answers for the same resource_name in the response to a single Query
operation. Signature Processing

When any of the attributes in a Query operation has an attribute_flags
field with the WANT_SIGNATURES bit set, the server will return, along
with the attribute information, any signatures which cover the attribute
and which are included in the list of signature_types that the client
understands.  If those signatures include other attributes which are not
requested, those attributes are also included in the response.  Thus a
response may include more attributes than requested.

If the list of signature_types is empty but WANT_SIGNATURES is set for
any attribute, the server will return all available signatures for that

A server MAY omit signatures (and the attributes needed to verify those
signatures) if including them would make the result too large for
transmission over UDP; however, inclusion of signatures takes precedence
over QUERY_RECURSE processing. Wildcard attribute names

For the purposes of a query, an attribute_name ending in the character
'*' (ASCII 2A hex) causes information to be returned for each of the
attribute_names in the resource which begin with the portion of the
attribute_name prior to the '*'.  The character '*' MUST NOT appear in
an attribute_name parameter of a Query operation except as the last
character.  Issuing a query for an attribute_name of "*" causes all
attributes to be returned.

4.2.2 Update operation

Note: the rescap charter states that the update protocol is part of the
"second task" of the group's activity which has not yet begun. A sample
update protocol is included here only for the purpose of illustrating
how Query and Update might work together.  This part of the

Moore                    Expires 28 August 2002                [Page 17]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

specification is therefore, for the time being, incomplete.

The Update operation may be used to add attributes, change the values
associated with attributes, or delete attributes from the set of
attributes associated with a URI.  The Update protocol may also be used
to add or delete signatures to sets of attributes.  Servers SHOULD
support the Update protocol, but MAY provide alternate means to perform
these operations than via the Update protocol. Update request structure

The Update request structure is as follows:

     BEGIN update_request
     int request_type         # UPDATE = 2
     string request_id
     int version_hi
     int version_lo
     string resource_name
     int flags
     struct<> assertions
     struct<> signatures

     For an Update operation, the request_type is 2.

     This is used to associate the response with the request.  See the
     definition of request_id for the Query operation.

version_hi, version_lo
     These is the version number which the client expects corresponds to
     the server's current version number for that resource.  If the
     UPDATE_VERSION_MATCH flag is set, this version number is compared
     with the server's version number.  Otherwise, version_hi and
     version_lo are ignored.

     The server will increase the version number (as represented by
     version_hi and version_lo), with each successful Update operation,
     by a small positive integer, using addition modulo 2**64.  The
     amount added to the version number need not be a constant, but MUST
     be sufficiently small that no version number will be reused (due to
     wrap-around) within ten years.

Moore                    Expires 28 August 2002                [Page 18]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     Clients MUST NOT use UPDATE_VERSION_MATCH to update portions of a
     resource's metadata if the version of the record they have
     previously obtained is more than than a year old or is of uncertain
     age.  In such cases it is necessary to first perform a Query
     operation and compare the actual data (not merely the version
     fields) to determine whether the data has been changed.

     The resource name for which attributes will be updated.

     If the UPDATE_CREATE_NEW flag is set, and no record for
     resource_name exists, this requests that a new record be created.

     If the UPDATE_VERSION_MATCH flag is set, the update fails with
     status VERSION_MISMATCH unless the version_hi and version_lo field
     of the Update request match the version_hi and version_lo fields of
     the existing record.  A nonexistent record (before it is created)
     is treated as if version_hi and version_lo were set to zero.

     If the UPDATE_CLOBBER_SIGS flag is not set, and the update would
     modify some attributes covered by a signature without modifying all
     of those attributes, the operation fails with status
     WOULD_CLOBBER_SIGS.  Setting the UPDATE_CLOBBER_SIGS flag causes
     the signature to be deleted if the update would otherwise be

     This is the list of assertions about resource_name to be added to,
     changed, or deleted, formatted according to the "assertions"
     structure defined above.  The assertions are updated as follows:

     -    If there is no assertion matching the attribute_name, the
          assertion from the Update request is added

     -    If there is already an assertion matching the attribute_name,
          the assertion from the Update request replaces the previous
          one from that principal.  however, if the ttl field in the
          Update request is 0, the previous assertion is deleted.

     -    If the attribute_name ends in '*', the Update operation
          applies to all attributes beginning with the prefix of the
          attribute_name.  However, this can only be used to delete old
          assertions (by setting ttl=0) or to update their ttls (by set-
          ting ttl to something other than 0) and expiration dates (by
          setting these to something other than 0).  Thus it is possible
          to update the ttl and/or expiration date of all assertions
          associated with a resource_name in a single Update operation.

Moore                    Expires 28 August 2002                [Page 19]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     The signatures included in the update.  Each of the components of
     the signature (in component_list) is an index into the assertions
     array.  Signatures can only be provide for assertions included in
     the Update operation; if it is needed to sign assertions that are
     already included in the record, they must first be obtained using a
     Query option and then the signatures supplied using an Update
     operation (probably with the MATCH_VERSION option set). Update response structure

The Update response structure is as follows:

     BEGIN update_response
     string request_id
     int status

The update response is a single status code.  The entire Update
operation either succeeds or fails atomically.  Keeping this structure
simple makes it easier to handle retransmitted Update requests without
performing multiple Updates - the server only has to remember the status
of the most recently transmitted request, for that resource_name, from
any party authorized to Update that resource.

4.2.3 One-Shot Authenticate operation

The One-Shot Authenticate operation is used to authenticate another
request via a lightweight mechanism.  It is intended for use with
requests (such as Update) which require authentication, when the
enclosing transport does not provide sufficient authentication.
However, it MAY be used over any transport, including bare TCP or UDP.

The One-Shot Authenticate operation only authenticates a single
operation; it DOES NOT establish authentication for subsequent
operations between those parties.

Moore                    Expires 28 August 2002                [Page 20]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002 One-Shot Authenticate request structure

The Authenticate request structure is as follows:

     BEGIN one_shot_authenticate_request
     int request_type    # ONE_SHOT_AUTHENTICATE = 3
     string request_id
     string authentication_type
     struct authentication_credentials
     int serial_number_hi
     int serial_number_lo
     struct inner_request

     For One-Shot Authenticate, the request number is 3.

     See request_id as described for the Query operation.

     The type of one-shot authentication used.  These are to be
     determined.  Possible authentication types would include digital
     signature formats based on public key cryptography and keyed-hash
     functions using shared secrets.

     This is an opaque data structure, specific to authentication_type,
     which is intended to assure the server of the client's identity and
     to provide integrity protection for the serial_number and the

serial_number_hi, serial_number_lo
     This is a serial number, represented as two 4-byte integers.  It is
     used to thwart replay attacks.  Each request from a particular
     principal must have a greater serial number than the previous one.
     If a serial number is repeated, and the request is otherwise valid,
     the request will be processed in such a manner as to neither alter
     information on the server nor to return potentially sensitive
     information in the result.  However, for an Update request sent
     over UDP, it is appropriate to return the status of the previous
     operation, in case the duplicate request was caused by a legitimate

Moore                    Expires 28 August 2002                [Page 21]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002 One-Shot Authenticate response structure

The One-Shot Authenticate response structure is as follows:

     BEGIN one_shot_authenticate_response
     string request_id
     int status
     struct inner_response

     See request_id as described for the Query operation.

     A code giving the result of the One-Shot Authenticate operation,
     not that of the inner request.  If the status code for the One-Shot
     Authenticate operation indicates failure, the inner_response field
     will be zero length.  If the status code for the One-Shot
     Authenticate operation indicates success, the inner_response field
     will have a status code indicating the status of the authenticated

     This is a BLOB-encoded field containing the server's response to
     the authenticated request, if the authentication was successful.

4.2.4 SASL Authenticate operation

The SASL Authenticate operation is used to authenticate the connection
using SASL [9] mechanisms.  Unlike the One-Shot Authenticate operation,
the SASL Authenticate operation establishes authentication credentials
for subsequent operations over the same TCP or TLS connection; and
unlike the One-Shot Authenticate operation, the SASL Authenticate
operation does NOT provide integrity protection for subsequent requests
or responses.  The SASL Authenticate operation MUST NOT be supported
over UDP.

Moore                    Expires 28 August 2002                [Page 22]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002 SASL Authenticate request structure

The SASL Authenticate request structure is as follows:

     BEGIN sasl_authenticate_request
     int request_type    # SASL_AUTHENTICATE = 5
     string request_id
     string mechanism
     int client_state
     string response

     For SASL Authenticate, the request type is 5.

     See request_id as described for the Query operation.  Each SASL
     Authenticate request gets a new request_id, even if the request is
     to respond to a challenge resulting from a previous SASL
     Authenticate request.

     An ASCII string giving the registered name of the SASL mechanism.

     An integer giving the type of SASL request:

     0.   Initial SASL Request.  This state code is used to indicate an
          initial SASL request.  In this case the client_response field
          MAY be used to indicate the first SASL authentication message
          for SASL methods where the client is the first party to send
          authentication data.

     1.   Response to SASL Challenge.  This state code is used when the
          client wishes to respond to a challenge that was issued by the
          server in the immediately previous SASL Authenticate Response

     2.   Abort SASL Request.  This state code is used when the client
          wishes to abandon an attempt to authenticate using SASL, or
          when the client wishes to revoke SASL authentication that is
          currently in effect.  (note that the server MAY be unable to
          accept a subsequent SASL authentication on the same TCP

     An octet string giving the client's response to a challenge (if

Moore                    Expires 28 August 2002                [Page 23]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     state == 1), or the client's initial response (if state == 0) for
     SASL methods which are defined to have the client be the first
     party to send authentication data. SASL Authenticate response structure

The SASL Authenticate response structure is as follows:

     BEGIN sasl_authenticate_response
     string request_id
     int status
     int server_state
     string challenge

     The request_id of the request.

     The status code resulting from the attempted operation:

          Authentication completed successfully.  server_state will be
          set to 2.

          Authentication failed because the SASL mechanism requested by
          the client is not supported by the server.  server_state will
          be set to 0.

          Authentication failed because the client attempted to use a
          SASL mechanism that requires strong encryption, without having
          strong encryption in place.  server_state will be set to 0.

          Authentication requires a response to a challenge issued by
          the server.  server_state will be set to 1.

          Authentication failed for temporary reasons.  server_state
          will be set to 0.

     other code
          Authentication failed.  server_state will be set to either 0
          or 3.

Moore                    Expires 28 August 2002                [Page 24]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     One of the following:

     0.   No SASL authentication is in effect or in progress.

     1.   SASL authentication is in progress; a response to a challenge
          is expected.

     2.   SASL authentication is in effect.

     3.   No SASL authentication is in effect or in progress, but the
          server is unable to accept further SASL authentication
          requests during this session.  The client must close the cur-
          rent TCP or TLS connection and reopen a new connection to the
          server before a SASL authentication can be successful. SASL Profile

The following profile is specified per [9]:

     1.   The SASL service name is {TBA IANA, presumably "rc"}.

     2.   The command to initiate the protocol exchange is the SASL
          Authenticate request with a client_state value of 0.

     3.   The authentication protocol exchange is carried out by having
          the client issue a series of SASL Authenticate requests.  The
          first request (the one used to initiate the exchange) has a
          client_state value of 0.  The server issues a response to each
          request.  Depending on the value of the server_state field of
          the response, the client may need to issue additional SASL
          Authenticate requests in order to supply responses to server
          challenges.  This repeats until the server either signals a
          success status code (with server_state set to 2) or a failure
          status code (with server_state set to 0).  The challenges and
          responses are supplied in appropriate fields of the SASL
          Authenticate response and request structures, respectively,
          and are NOT encoded except for the BLOB encapsulation speci-
          fied by the RC protocol.

     4.   The negotiated security layer takes effect immediately follow-
          ing the client's transmission of a SASL Authenticate Request
          structure, and the server's transmission of a SASL Authenti-
          cate Response structure for which (status = RC_SUCCESS) AND
          (server_state = 2).  Once the client has sent a SASL Authenti-
          cate Request, the client MUST NOT transmit additional requests
          other than SASL Authenticate over that connection until the
          server has returned a SASL Authenticate response for which

Moore                    Expires 28 August 2002                [Page 25]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

          server_state is not equal to 1.  A SASL Authenticate request
          with a client_state of 2 may be used to abort a SASL exchange
          and cause the server to reset its server_state to 0.

     5.   The authorization identity that is passed to the server is
          used by the server, along with other configuration and permis-
          sions information, to determine whether the client is autho-
          rized to perform a particular operation.  For now, the method
          by which the server makes such a determination is undefined by
          the RC protocol. Notes on use of SASL

Due to implementation constraints, some servers may be unable to accept
more than one SASL authentication per TCP or TLS connection, even if the
original authentication is revoked.

Attempts to use SASL mechanisms which transmit shared secrets (e.g.
passwords) MUST be rejected by the server unless there is an established
TLS connection using a ciphersuite which provides encryption with an
effective key strength (for the symmetric encryption key) of at least
112 bits.

4.3 Transport

4.3.1 Use over TCP and UDP

An RC server listens for requests on UDP port {TBD-IANA}.  When used
over UDP, each request or response is entirely contained within a single
UDP datagram.  The response is sent to the same address and port number
that appeared in the IP header of the request.  The request or response
datagrams MAY be fragmented into multiple IP packets; so support for
reassembly is required.  The maximum possible request or response is
constrained by the maximum UDP datagram size.  Clients SHOULD NOT use
UDP for a request when the response is expected to contain a large
amount of data.  Servers SHOULD have code to limit the amount of
additional information returned in a UDP response to some reasonable
figure.  Servers MUST detect when a response would be too large (either
larger than the maximum UDP datagram size or larger than some smaller
administrative limit) and return an appropriate error indication.

UDP clients MUST implement a retransmission timer to keep from swamping
the network - details are to be determined.

An RC server that supports TCP listens for requests on port {TBD-IANA}.
The responses are returned over the same connection.  Multiple requests
and responses may be sent over a single TCP connection.  The requests
and responses are self-delimiting, each beginning with a 4-octet integer

Moore                    Expires 28 August 2002                [Page 26]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

length field (in network byte order).  Multiple requests MAY be issued
before reading a response, but this introduces the possibility of
deadlock.  A client that issues multiple requests MUST be able to read
responses to earlier requests concurrently while issuing requests.  When
multiple outstanding requests are issued over a single TCP connection,
servers MAY service them out of order, so long as no request is
significantly delayed.  Servers MAY place a limit on the number of
outstanding requests from a single source, in which case they MUST
respond to requests in excess of that limit with a {TBD} error.

NB: the above needs work.  Since a response may be of arbitrary size, a
server might be unable to return "too many outstanding requests" because
a large response is blocking the return channel.

4.3.2 Use over TLS

Clients and servers MAY support TLS.  TLS is layered on top of TCP, and
an RC server which supports TLS uses the same port for RC-over-TLS-over-
TCP as for RC-over-TCP.  A client wishing to use TLS to communicate with
a server first opens up a TCP connection to that server, and then issues
a StartTLS request. StartTLS request structure

A StartTLS request structure is defined as follows:

     BEGIN starttls_request
     int request_type    # STARTTLS = 4
     string request_id
     END StartTLS response structure

The StartTLS response structure is:

     BEGIN starttls_response
     string request_id
     int status

Servers which support TLS MUST support ciphersuite {TBD}.  The
appropriate use of TLS server certificates by clients, and the use of
TLS client certificates by servers, is yet to be defined.

Moore                    Expires 28 August 2002                [Page 27]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

4.4 Mapping from URIs to RC server locations

The specifics of this are currently undefined, but are intended to be
similar to the procedures defined in [11], [2], and [12], and consistent
with any standards developed in this area.

4.5 Operation Through Proxies

RC clients MAY make queries via a proxy.  Such proxies MAY cache
successful results (up until their ttls and or expiration dates expire)
and return them in response to subsequent Queries.  Unsuccessful results
MUST NOT be cached.  Proxies MAY supply their own request_id fields of
requests passed to servers, in order to better facilitate demultiplexing
and routing of the responses to their clients, so long as they also
modify the request_id fields of responses returned to the clients to
match the request_id fields used by those clients.

4.6 Status Codes

     successful operation

     operation failed; no record for this resource_name was found on
     this server

     operation succeeded, but the answer returned is not authoritative

     operation succeeded, but signatures could not be included in the
     response due to space limitations

     operation failed because VERSION_MATCH was set in the request but
     the version numbers did not match.  (Note: This MUST NOT be used to
     signal a mismatch between versions of the RC protocol.)

     operation failed due to unspecified temporary conditions

     operation failed because the Update would result in invalidation of
     existing signatures, and the DONT_CLOBBER_SIGS flag was set

     operation failed; the syntax of the resource name was not valid

Moore                    Expires 28 August 2002                [Page 28]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

     operation failed, could not verify credentials

     operation failed, credentials have been revoked or have expired

     client does not have permission to perform the operation

     the request was not in the proper format or could not be parsed

     query refused

     The authentication method chosen by the client is not sufficiently
     secure for this operation; the actual operation was not attempted.

     The authentication method chosen by the client is not supported by
     the server.

     The request_type is not supported by this server, either because it
     is deprecated or because it is not yet defined.

     This is a response to a SASL Authenticate request, indicating that
     a response to a challenge is necessary before authentication can be

     The authentication failed because the client attempted to use an
     authentication method that requires strong encryption, without hav-
     ing strong encryption in place.

5. Conventions for attribute names

Attribute names are human-meaningful ASCII strings consisting of
printable characters.  They are chosen in such a way that wildcard
queries are useful.  Related attributes are grouped together by having a
common prefix.  Thus for example a set of attributes related to
electronic mail might be grouped together with the prefix "rc:email.",
and queries for "rc:email.*" might be issued to obtain all such

Moore                    Expires 28 August 2002                [Page 29]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

RC is designed to be mostly agnostic about the format of attribute
names.  Some existing data models use Uniform Resource Identifiers as
attribute names.  This seems unwise - not only do URIs tend to be more
verbose than necessary, but their use as attribute names seems likely to
encourage inappropriate semantic association between the URI components
(prefix/protocol, domain name, etc) and the attribute named by the URI.

However, for the sake of consistency with existing practice, URIs MAY be
used as attribute names in RC - subject only to the requirement that RC
performs exact (octet-by-octet) comparison of attribute names.  URIs
used as attribute names in RC MUST be canonicalized so that the URI
always has a consistent representation.  The algorithm by which this
canonicalization is done is not defined by the RC protocol; it MUST be
specified by the higher-level protocol.

It is intended that a registry of attribute names be maintained by IANA
in order to discourage conflicting uses of the same names.  Assignment
of registry names is via the IETF Consensus process or with IESG
approval.  Prefixes MAY be delegated to other parties via the IETF
Consensus process.

The prefix "rc:" is reserved for attributes used by RC itself.  The
prefix ":x:" is reserved for ad hoc user extensions.

5.1. Inheritance of attributes

The rescap charter specifies a requirement that it must be possible to
inherit attributes.  In RC this is accomplished as follows: the
attribute_name "rc:defaults" is defined.  The value associated with this
name should be a URI.  If an attribute named "rc:defaults" exists for a
particular resource_name, the default attributes for that resource_name
may be obtained by issuing a query for the same attribute_names to the
URI associated with "rc:defaults".

The defaults may thus easily be obtained by including the attribute_name
"rc:defaults" in the set of attributes requested, and by setting the
QUERY_RECURSE flag for that attribute_name.  Multiple levels of defaults
are possible, and each resource_name can have its own set of defaults.
(However, clients MUST take pains to detect circular references in
rc:defaults; any rc:defaults value which matches to either the
request_uri or a previous rc:defaults value obtained during the same
query, MUST be ignored.)

6. IANA Considerations

-    A new TCP port and a new UDP port are needed

Moore                    Expires 28 August 2002                [Page 30]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

-    A registry of attribute_names, and procedures for assigning and
     delegating attribute naming prefixes, are needed.

-    A registry of signature algorithms, and a procedure for registering
     new signature algorithms identifiers, are needed.

-    A service name (presumably "rc") for use with SASL (and therefore
     GSSAPI) needs to be defined.

7. Security Considerations

Many security considerations are discussed in section 2.5.  Here are
some others.

7.1 Privacy issues regarding choice of request_ids

Since request_ids need to be unique, it is tempting to define them in
terms of some other convenient globally-unique number such as a GUID,
network interface hardware address, (non-private) IP address, etc.  This
may result in inadvertent disclosure of information about usage patterns
to unauthorized parties.  Request-ids SHOULD be chosen in such a way as
to minimize the potential for disclosure of information which could be
associated with a particular person or host.  The fact that similar
information could be disclosed by other means does not lessen the burden
for RC client implementations to minimize their own potential for
disclosure through the request_id field.

Similarly, RC proxies that multiplex several clients' requests over the
same TCP stream may need to map between clients' request_ids and their
own request_ids for proxied requests, in order to ensure that each
request_id transmitted over a TCP stream is unique.  Such proxies SHOULD
avoid disclosing identifying information about clients via the
request_id field.

8. Differences from RC version 2

Just to provide some background, this section details major differences
between RCv2 and RCv3:

-    RCv2 had typed attributes; RCv3 makes all attributes octet-strings.

-    RCv2 used ONC XDR and RPC [13]; RCv3 uses the BLOB encoding and
     defines its own RPC mechanism.  For a variety of reasons, most
     having little to do with protocol quality, RCv2's use of ONC RPC
     was the single most frequently cited objection to that protocol.
     However the mechanism intended for use with RCv3 is easier to
     implement and more efficient to process than XDR.

Moore                    Expires 28 August 2002                [Page 31]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

-    RCv2 maintained separate records for attributes of resources (like
     RCv3's assertions) and locations of resources, allowing the caller
     to choose the closest of several locations for that resource.  The
     latter also included cached DNS A records in order to speed up
     accesses to the resource.  RCv3 does not have this separation.

-    RCv2 supported the principle of multiple 'asserters' for
     information about a resource.  it kept track of who made each
     assertion, and if different asserters made conflicting assertions,
     it would return all of the assertions.  RCv3 assumes that a small
     number of trusted parties will be allowed to make assertions about
     any particular resource, and that these parties will cooperate to
     the degree necessary to avoid making conflicting assertions about a
     resource.  The QUERY_RECURSE feature of RCv3 is intended to provide
     similar functionality in a more general fashion.

-    RCv2 supported the notion of redirects - the ability to redirect
     queries for portions of URI-space - at the protocol level; this is
     omitted in RCv3 because they were too much trouble to use.
     Redirects could be implemented in RCv3 by making them ordinary
     attributes and by using the QUERY_RECURSE bit in queries for that
     attribute name.

9. Acknowledgements

The author wishes to thank Graham Klyne for extensive comments on an
earlier version of this document.

10. Author's Address

Keith Moore
University of Tennessee, Knoxville
1122 Volunteer Blvd, Suite 203
Knoxville TN, 37996-3450

11. References

[1]  Bradner, S.  Key words for use in RFCs to Indicate Requirement
     Levels.  RFC 2119, March 1997.

[2]  Mealling, M., Daniel, R.  The Naming Authority Pointer (NAPTR) DNS
     Resource Record.  RFC 2915, September 2000.

[3]  Gulbrandsen, A., Vixie, P., Esibow, L.  A DNS RR for specifying the
     location of services (DNS SRV).  RFC 2782, February 2000.

Moore                    Expires 28 August 2002                [Page 32]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

[4]  Dierks, T., Allen, C.  The TLS Protocol Version 1.0.  RFC 2246,
     January 1999.

[5]  Mockapetris, P.V.  Domain names - implementation and specification.
     RFC 1035, November 1987.

[6]  Case, J. Mundy, R., Partain, D., Stewart, B. Introduction to
     Version 3 of the Internet-standard Network Management Framework.
     RFC 2570, April 1999.

[7]  Wahl, M., Howes, T., Kille, S.  Lightweight Directory Access
     Protocol (v3).  RFC 2251, December 1997.

[8]  Moore, K.  The Binary Low-Overhead Block Presentation Protocol.
     Internet-Draft draft-ietf-rescap-blob-01.txt, March 1, 2002, work
     in progress.

[9]  Myers, J.  Simple Authentication and Security Layer (SASL).  RFC
     2222, October 1997.

[10] Linn, J.  Generic Security Service Application Program Interface
     Version 2, Update 1.  RFC 2743, January 2000.

[11] Daniel, R., Mealling, M.  Resolution of Uniform Resource
     Identifiers using the Domain Name System.  RFC 2168, June 1997.

[12] Mealling, M.  A DDDS Database Using the Domain Name System.
     Internet-Draft draft-ietf-urn-dns-ddds-database-08.txt, February
     2002.  work in progress.

[13] Srinivasan, R.  RPC: Remote Procedure Call Protocol Specification
     Version 2.  RFC 1831, August 1995.

Appendix A.  Substantive changes since version -00

-    section 2.5: removed what was essentially a duplicate description
     of the 'alteration of data' threat; also added some text explaining
     limitations of server-provided signatures.

-    section 3.1: explain why it's useful to have both a TTL and an
     expiration date.

-    section 4.1 et seq: renumber request types so that the "reserved"
     request is 0.

-    section 4.1.1: change example of supported_requests array to illus-
     trate a range consisting of a single request number.  also added a
     note about caching of supported request information.

Moore                    Expires 28 August 2002                [Page 33]

Resource Catalog (v3)        INTERNET-DRAFT             28 February 2002

-    various: updated section references to reflect current reality.

-    section clarify that a signature may be computed over
     resource_name and version_* in addition to the list of assertions.

-    section eliminate duplicate version_* fields in
     update_request.  also state explicitly how the server updates ver-
     sion_* fields on completion of successful requests, and limitations
     on using UPDATE_VERSION_MATCH due to wrap-around of version_

-    section 4.2.3: rename Authenticate operation to One-Shot Authenti-
     cate; add new SASL Authenticate operation.  The former is designed
     for use with UDP; the latter, with TCP or TLS.

-    section 4.3: remove text stating requirements for support of TCP
     and UDP; this needs re-thinking.

-    section 4.4: forbid caching of negative responses by proxies.

-    section 4.5: added new status codes

-    section 5.1: clarify handling of circular references to

Appendix B.  Open issues

-    There is no model for access control.  This can probably be

-    A mandatory-to-implement TLS ciphersuite for servers supporting
     StartTLS operation needs to be chosen.

-    Authentication methods for One-Shot authentication need to be

-    At least one signature algorithm needs to be defined.

-    Characteristics of UDP request retransmission timer need to be
     defined.  (borrow from SIP?)

-    Conformance requrements for clients and servers regarding TCP and
     UDP, TLS, and authentication mechanisms, need to be defined.

-    Rules for caches/proxies regarding use of authentication need to be

Moore                    Expires 28 August 2002                [Page 34]