Internet Draft                                 Paul Hoffman
draft-ietf-rescap-proto-main-00.txt
draft-ietf-rescap-proto-main-01.txt            Internet Mail Consortium
January 30,
August 8, 2000
Expires in six months

                     The rescap Resolution Protocol

Status of this memo

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
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The rescap protocol is a general client-server resolution protocol that
translates resource identifiers to a list of attributes. For instance,
a rescap client can ask a rescap server for the attributes of a
particular mail user. rescap is very light-weight and acts only as a
resolution protocol, not a directory service. This document describes
the main features of the protocol.

1. Introduction

When an Internet client is accessing a resource, it is often valuable
for the client to know the attributes of the resource before contacting
the resource. For example, a mail user might want to know whether
another mail user is able to natively display TIFF files before
creating a message with a TIFF file in it. The rescap protocol is a
simple, extensible client-server protocol that allows a client to
easily find the correct rescap server for a particular resource and
find the attributes for that resource.

This document specifies:
  - How to find the rescap server for a particular resource
  - The recap protocol
 - Registration of the "rescap" scheme name for URLs

A different document, [RESCAP-FORMAT], specifies:
  - The format for rescap requests and responses
  - Required rescap items that must be supported

The protocol in this document attempts to meet the requirements
described in the rescap requirements document [RESCAP-REQUIRE]. It
should be noted that rescap is explicitly not to be used as a service-
discovery protocol; users that want such a capability should use the
Service Location Protocol [SLP].

Future documents may specify the administrative protocol described
in [RESCAP-REQUIRE].

This document and others relating to the rescap protocol are being
discussed in the recap WG of the IETF on the rescap@cs.utk.edu mailing
list. To subscribe, send a message to rescap-request@cs.utk.edu. An
archive of the mailing list is available at
<ftp://cs.utk.edu/pub/rescap>.

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD].

2. Finding a Protocol

The rescap Server

A protocol uses a single request-response model. That is, a
rescap client that wants to find the attributes for a particular
Internet resource needs connects to find the rescap server server, sends a single request,
and waits for that resource.
The client MUST look up the A record associated with response. The server sends a single response and
closes the connection.

The rescap server protocol has two forms: basic and secure. The basic form
offers only authentication by IP address, and gives no privacy for the host name in the resource. When SRV records (described in
[SRV]) become widely deployed,
requests or the responses. The secure form offers client and server
authentication, and privacy. Conforming rescap servers MUST support
the basic form and MAY instead use also support the SRV
protocol to locate secure form.

Note that many of the main motivations for rescap server.

To find do not require any
security services: the A record of information returned by the rescap server, the client prepends two
special domain names server is
openly available to the host name in the resource. anyone. The first name
prepended (just to the left basic form of rescap works just fine
for this situation. If the host name) is "_rescap."; the second
name prepended (just client needs to authenticate the left of "_rescap." is an underscore followed
by the URL scheme name.

For example, to find server, or
if the rescap server that is authoritative for the
URI "mailto:someone@example.com", needs to authenticate the rescap client would resolve the A
record of by something other than
the name "_mailto._rescap.example.com" and use that value client's IP address (such as for mobile users), or if privacy is
needed, the location of secure form MUST be used.

2.1 Basic form

The requirement that the rescap server.

2.1 Optional use of SRV Records

SRV records MAY protocol be used for locating rescap servers. The request sent light-weight and fast leads
to the DNS server is somewhat different than is specified in [SRV]
because the rescap client must indicate the type of resource conclusion that will
be resolved by the rescap server. The resource name is given as the URI
scheme name, and it appears in the left-most part should run on UDP instead of the DNS name to be
resolved. The URI scheme name TCP because UDP
takes less system and network resources for short exchanges. However,
UDP has an underscore character (_) prepended many problems, including that long datagrams may get split up or
lost. Thus, to it, just as the service make rescap reliable, basic form rescap servers run on
both UDP and prototype names do.

As described in section 3 TCP. Implementations of this specification, the basic form rescap protocol
runs over SHOULD use UDP
checksums to help detect fragmentation.

A basic form rescap server MUST run the same service on both the UDP and
TCP protocols, protocols. The port number 283 has been reserved by IANA for basic
form rescap, and all compliant basic form rescap servers
must SHOULD run the rescap service on both protocols on that port
number. However, because the same host. It is
inefficient to force the rescap client to look up SRV records for both
protocols, and doubling MUST find the port number of using SRV records for
records, the basic form rescap
protocol server can have an adverse effect run on the domain name system. Thus,
rescap clients MUST only resolve rescap SRV records for the any UDP
protocol, and MUST assume that TCP port.

A rescap client using the same host that was resolved for basic form SHOULD make its initial request to
the
UDP protocol will support basic form rescap over server using UDP. However, if the TCP protocol as well. rescap
clients MUST NOT attempt to resolve rescap SRV records for client
using the TCP
protocol.

For example, to use SRV records to find basic form expects that the response from the rescap server that to be
longer than 512 octets (such as if it is
authoritative asking for an attribute whose
value is always longer than 512 octets), the URI "mailto:someone@example.com", the rescap client would resolve the SRV record for MAY choose to make
the name
"_mailto._rescap._udp.example.com".

3. Protocol

The rescap protocol uses a single request-response model. That is, initial connection using TCP.

If a
rescap client connects to using the rescap server, basic form sends a single request,
and waits for UDP request to the response. The server named
in an SRV record but does not receive a response, the client SHOULD send
the same request using TCP. If a client sends a single response UDP request to a server
and
closes receives an incomplete response, the connection.

The rescap protocol has two forms: basic and secure. The basic form
offers only authentication by IP address, and gives no privacy for client MUST send the
requests same
request using TCP. This is due to the fact that a later part of a
response might modify or negate the responses. meaning of an earlier part of a
response.

2.2 Secure form

The secure form offers client and server
authentication, and privacy. Conforming of rescap servers MUST support is quite similar to the basic form and MAY also support form, but the secure form.

Note that many of the main motivations
connection MUST be made using TCP under TLS [TLS]. No port has been
reserved by IANA for secure form rescap, so secure form rescap do not require servers
MAY run on any
security services: port number. Because the information returned by client MUST find the port number
using SRV records, the secure form rescap server is
openly available to anyone. The basic can run on any UDP and
TCP port.

Secure form of rescap works just fine
for this situation. If clients and servers MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The client needs to authenticate the server, of
if and
the server needs MUST NOT support any cipher suites that do not contain both
encryption and authentication.

3. Finding a rescap Server

SRV records [SRV] MUST be used for locating rescap servers. The request
sent to authenticate the client by something other DNS server is somewhat different than
the client's IP address (such as for mobile users), or if privacy is
needed, the secure form MUST be used.

3.1 Basic form

The requirement that specified in [SRV]
because the rescap protocol be light-weight and fast leads
to client must indicate the conclusion that it should run on UDP instead type of TCP because UDP
takes less system and network resources for short exchanges. However,
UDP has many problems, including resource that long datagrams may get split up
or lost. Thus, to make rescap reliable, basic form will
be resolved by the rescap servers run
on both UDP server. The resource name is given as the URI
scheme name, and TCP. Implementations it appears in the left-most part of basic form rescap SHOULD use
UDP checksums the DNS name to help detect fragmentation.

A basic form rescap server MUST run be
resolved. The URI scheme name has an underscore character (_) prepended
to it, just as the same service on both the UDP
and TCP protocols, and MUST use prototype names do.

As described in section 2 of this specification, the same port number for both services.
The port number 283 has been reserved by IANA for basic form rescap, of the
rescap protocol runs over both the UDP and TCP protocols, and all
compliant basic form servers MUST run the rescap service on both
protocols on the same host (secure form servers SHOULD only run
on that port number. However,
because TCP). It is inefficient to force the rescap client is allowed
to find look up SRV records for both protocols, and doubling the port number using of
SRV
records, records for the basic form rescap server protocol can run have an adverse effect on any UDP and TCP port.

A rescap client using the basic form SHOULD make its initial request to the basic form
domain name system. Thus, rescap server using UDP. However, if the clients MUST only resolve rescap client
using SRV
records for the basic form expects TCP protocol, and MUST assume that the response from the server to be
longer than 512 octets (such as if it is asking same host that
was resolved for an attribute whose
value is always longer than 512 octets), the client MAY choose to make
the initial connection using TCP.

If a client using TCP protocol will support rescap over the basic form sends a UDP request
protocol as well. rescap clients MUST NOT attempt to the server
named in an resolve
rescap SRV record but does not receive a response, the client
SHOULD send records for the same request using TCP. If a client sends a UDP request
to a server and receives an incomplete response, the client MUST send
the same request using TCP. This is due to the fact that a later part
of a response might modify or negate the meaning of an earlier part of
a response.

3.2 Secure form protocol.

The secure form two forms of rescap is quite similar to the basic form, but have different service names for the
connection is made using TCP under TLS [TLS]. SRV
records. The port <TBD> has been
reserved by IANA for secure basic form rescap, has the service name "rescap-basic" and the
secure form rescap servers
SHOULD run on that port number. However, because has the client is allowed service name "rescap-secure".

For example, to find the port number using basic server that is authoritative for the URI
"mailto:someone@example.com", the rescap client would resolve the SRV records,
record for the name:

_mailto._rescap-basic._tcp.example.com

To find the secure form rescap server can run on any TCP port.

rescap clients and servers MUST support that is authoritative for the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The URI
"mailto:someone@example.com", the rescap client and would resolve the server MUST NOT support any cipher suites that do not contain both
encryption and authentication. SRV
record for the name:

_mailto._rescap-secure._tcp.example.com

4. Security Considerations

rescap users rely on the DNS for finding a rescap server. Unless the
DNS is secure, an attacker can cause a rescap user to get information
from the wrong server.

Basic form rescap offers no authentication of the client, no
authentication of the server, and no privacy of the requests or
responses. The secure form gives privacy of the request and the
response, and allows the client to authenticate the server and the
server to authenticate the client. Note, however, that few TLS
implementations use client authentication. The rescap format has
features for client authentication in both basic form and secure form.

5. References

[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119.

[RESCAP-FORMAT] "The rescap Request and Response Format",
draft-hoffman-rescap-proto-format.

[RESCAP-REQUIRE] "ResCap Requirements", draft-ietf-rescap-req.

[SLP] "Service Location Protocol, Version 2.", RFC 2608, and "Service
Templates and Service: Schemes", RFC 2609.

[SRV] "A DNS RR for specifying the location of services (DNS SRV)", RFC
2052. NOTE: RFC 2052 services (DNS SRV)", RFC
2782.

[TLS] "TLS Protocol", RFC 2246.

A. IANA Considerations

A.1 Registration for rescap-basic URL Scheme

URL scheme name: rescap-basic

URL scheme syntax: rescap-basic://<hostport>?<base64-of-request>

      <hostport> is exactly as defined in RFC 2396. <base64-of-request>
      is the Base64 encoding of a rescap request.

      For example, to indicate a query to the basic form rescap server on
      the host "an.example.com" at the default port of 283, the URL would
      be rescap://an.example.com/SK398cske002CcksleEEx

Character encoding considerations: None. All three parts are expressed
	 in US-ASCII.

Intended usage: To identify redirected queries to rescap servers. The
      resolution of a rescap URL will cause a query to be sent to the
      named server. The resolver would decode the Base64 of the third
      part of the URL and send it to the specified port (or the default
      port of 283 if no port is being updated by
draft-ietf-dnsind-rfc2052bis. The examples specified in the URL) using the TCP
      protocol. It is *not* expected that recap-basic URLs will be
      entered manually by users or be given by anything other than a
      referring rescap server.

Applications and/or protocols which use this URL scheme name:
      This document are
based on describes the Internet Draft, not on RFC 2052.

[TLS] "TLS Protocol", RFC 2246.

A. IANA Considerations

A.1 rescap protocol.

Interoperability considerations: None known.

Security considerations: Same as in this document.

Relevant publications: This document.

Person & email address to contact for further information:
      Paul Hoffman <phoffman@imc.org>

Author/Change controller:
      Paul Hoffman <phoffman@imc.org>

A.2 Registration for rescap rescap-secure URL Scheme

URL scheme name: rescap rescap-secure

URL scheme syntax: <scheme-name>://<hostport>?<base64-of-request>
	 <scheme-name> is either the string "rescap" for basic form or
	 "rescap-secure" for secure form. rescap-secure://<hostport>?<base64-of-request>

      <hostport> is exactly as defined in RFC 2396. Note that, because
      there is no default port for secure form server, the port number
      MUST be included in the <hostport>. <base64-of-request> is the
      Base64 encoding of a rescap request.

      For example, to indicate a query to the basic form rescap server
	 on the host "an.example.com" at the default port of 283, the URL
	 would be rescap://an.example.com/SK398cske002CcksleEEx

     For example, to indicate a query to the secure form rescap server on the
      host at 10.20.30.40 at port 1234, the URL would be
      rescap-secure://10.20.30.40:1234/SK398cske002CcksleEEx

Character encoding considerations: None. All three parts are expressed
	 in US-ASCII.

Intended usage: To identify redirected queries to rescap servers. The
      resolution of a rescap URL will normally cause a query to be sent to the
      named server. The resolver would decode the Base64 of the third
      part of the URL and send it to the specified port (or the default
      port of 283 if no port is specified in the URL) using the TCP
      protocol.  It is *not* expected that recap-basic URLs will be
      entered manually by users or be given by anything other than a
      referring rescap server.

Applications and/or protocols which use this URL scheme name:
      This document describes the rescap protocol.

Interoperability considerations: None known.

Security considerations: Same as in this document.

Relevant publications: This document.

Person & email address to contact for further information:
      Paul Hoffman <phoffman@imc.org>

Author/Change controller:
      Paul Hoffman <phoffman@imc.org>

A.2

A.3 Port reservation

IANA has reserved port 283 for basic form rescap. A port has been
requested for secure form rescap.

B. Acknowledgments

Graham Klyne provided suggestions for early versions of the first draft.

C. Changes Between the -00 and -01 Versions of This Document

This document began as a single document that included

Reversed the material
in [RESCAP-FORMAT]. It was split into two so that people could think
about each part separately. Thus, a great deal has been cut out order of sections 2 and
moved to 3 because the other draft.

The biggest change in this new document is that needs to
describe the protocol now has two
forms: basic and secure. secure forms before describing how to find them.

Made many changes based on this.

Noted that SRV records mandatory and dropped the mailing list is now for previous kludge.

Made using the WG.

Updated port number from the SRV record mandatory.

Changed the SRV lookup to use TCP to reduce confusion between the references. basic
and secure forms.

Updated the URL registration reference for secure form. SRV records.

Significantly updated the URL registration.

D. Author Contact Information

Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA  95060 USA
phoffman@imc.org