draft-ietf-rescap-proto-main-00.txt   draft-ietf-rescap-proto-main-01.txt 
Internet Draft Paul Hoffman Internet Draft Paul Hoffman
draft-ietf-rescap-proto-main-00.txt Internet Mail Consortium draft-ietf-rescap-proto-main-01.txt Internet Mail Consortium
January 30, 2000 August 8, 2000
Expires in six months Expires in six months
The rescap Resolution Protocol The rescap Resolution Protocol
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at line 51 skipping to change at line 51
the resource. For example, a mail user might want to know whether the resource. For example, a mail user might want to know whether
another mail user is able to natively display TIFF files before 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 creating a message with a TIFF file in it. The rescap protocol is a
simple, extensible client-server protocol that allows a client to simple, extensible client-server protocol that allows a client to
easily find the correct rescap server for a particular resource and easily find the correct rescap server for a particular resource and
find the attributes for that resource. find the attributes for that resource.
This document specifies: This document specifies:
- How to find the rescap server for a particular resource - How to find the rescap server for a particular resource
- The recap protocol - The recap protocol
- Registration of the "rescap" scheme name for URLs
A different document, [RESCAP-FORMAT], specifies: A different document, [RESCAP-FORMAT], specifies:
- The format for rescap requests and responses - The format for rescap requests and responses
- Required rescap items that must be supported - Required rescap items that must be supported
The protocol in this document attempts to meet the requirements The protocol in this document attempts to meet the requirements
described in the rescap requirements document [RESCAP-REQUIRE]. It described in the rescap requirements document [RESCAP-REQUIRE]. It
should be noted that rescap is explicitly not to be used as a service- 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 discovery protocol; users that want such a capability should use the
Service Location Protocol [SLP]. Service Location Protocol [SLP].
skipping to change at line 78 skipping to change at line 77
list. To subscribe, send a message to rescap-request@cs.utk.edu. An list. To subscribe, send a message to rescap-request@cs.utk.edu. An
archive of the mailing list is available at archive of the mailing list is available at
<ftp://cs.utk.edu/pub/rescap>. <ftp://cs.utk.edu/pub/rescap>.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
2. Finding a rescap Server 2. Protocol
A rescap client that wants to find the attributes for a particular
Internet resource needs to find the rescap server for that resource.
The client MUST look up the A record associated with the rescap server
for the host name in the resource. When SRV records (described in
[SRV]) become widely deployed, the client MAY instead use the SRV
protocol to locate the rescap server.
To find the A record of the rescap server, the client prepends two
special domain names to the host name in the resource. The first name
prepended (just to the left of the host name) is "_rescap."; the second
name prepended (just to the left of "_rescap." is an underscore followed
by the URL scheme name.
For example, to find the rescap server that is authoritative for the
URI "mailto:someone@example.com", the rescap client would resolve the A
record of the name "_mailto._rescap.example.com" and use that value as
the location of the rescap server.
2.1 Optional use of SRV Records
SRV records MAY be used for locating rescap servers. The request sent
to the DNS server is somewhat different than is specified in [SRV]
because the rescap client must indicate the type of resource 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 of the DNS name to be
resolved. The URI scheme name has an underscore character (_) prepended
to it, just as the service and prototype names do.
As described in section 3 of this specification, the rescap protocol
runs over both the UDP and TCP protocols, and all compliant servers
must run the rescap service on both protocols on the same host. It is
inefficient to force the rescap client to look up SRV records for both
protocols, and doubling the number of SRV records for the rescap
protocol can have an adverse effect on the domain name system. Thus,
rescap clients MUST only resolve rescap SRV records for the UDP
protocol, and MUST assume that the same host that was resolved for the
UDP protocol will support rescap over the TCP protocol as well. rescap
clients MUST NOT attempt to resolve rescap SRV records for the TCP
protocol.
For example, to use SRV records to find the rescap server that is
authoritative for the URI "mailto:someone@example.com", the rescap
client would resolve the SRV record for the name
"_mailto._rescap._udp.example.com".
3. Protocol
The rescap protocol uses a single request-response model. That is, a The rescap protocol uses a single request-response model. That is, a
rescap client connects to the rescap server, sends a single request, rescap client connects to the rescap server, sends a single request,
and waits for the response. The server sends a single response and and waits for the response. The server sends a single response and
closes the connection. closes the connection.
The rescap protocol has two forms: basic and secure. The basic form The rescap protocol has two forms: basic and secure. The basic form
offers only authentication by IP address, and gives no privacy for the offers only authentication by IP address, and gives no privacy for the
requests or the responses. The secure form offers client and server requests or the responses. The secure form offers client and server
authentication, and privacy. Conforming rescap servers MUST support authentication, and privacy. Conforming rescap servers MUST support
the basic form and MAY also support the secure form. the basic form and MAY also support the secure form.
Note that many of the main motivations for rescap do not require any Note that many of the main motivations for rescap do not require any
security services: the information returned by the rescap server is security services: the information returned by the rescap server is
openly available to anyone. The basic form of rescap works just fine openly available to anyone. The basic form of rescap works just fine
for this situation. If the client needs to authenticate the server, of for this situation. If the client needs to authenticate the server, or
if the server needs to authenticate the client by something other than if the server needs to authenticate the client by something other than
the client's IP address (such as for mobile users), or if privacy is the client's IP address (such as for mobile users), or if privacy is
needed, the secure form MUST be used. needed, the secure form MUST be used.
3.1 Basic form 2.1 Basic form
The requirement that the rescap protocol be light-weight and fast leads The requirement that the rescap protocol be light-weight and fast leads
to the conclusion that it should run on UDP instead of TCP because UDP to the conclusion that it should run on UDP instead of TCP because UDP
takes less system and network resources for short exchanges. However, takes less system and network resources for short exchanges. However,
UDP has many problems, including that long datagrams may get split up UDP has many problems, including that long datagrams may get split up or
or lost. Thus, to make rescap reliable, basic form rescap servers run lost. Thus, to make rescap reliable, basic form rescap servers run on
on both UDP and TCP. Implementations of basic form rescap SHOULD use both UDP and TCP. Implementations of basic form rescap SHOULD use UDP
UDP checksums to help detect fragmentation. checksums to help detect fragmentation.
A basic form rescap server MUST run the same service on both the UDP A basic form rescap server MUST run the same service on both the UDP and
and TCP protocols, and MUST use the same port number for both services. TCP protocols. The port number 283 has been reserved by IANA for basic
The port number 283 has been reserved by IANA for basic form rescap, form rescap, and basic form rescap servers SHOULD run on that port
and basic form rescap servers SHOULD run on that port number. However, number. However, because the client MUST find the port number using SRV
because the client is allowed to find the port number using SRV
records, the basic form rescap server can run on any UDP and TCP port. records, the basic form rescap server can run on any UDP and TCP port.
A rescap client using the basic form SHOULD make its initial request to A rescap client using the basic form SHOULD make its initial request to
the basic form rescap server using UDP. However, if the rescap client the basic form rescap server using UDP. However, if the rescap client
using the basic form expects that the response from the server to be using the basic form expects that the response from the server to be
longer than 512 octets (such as if it is asking for an attribute whose longer than 512 octets (such as if it is asking for an attribute whose
value is always longer than 512 octets), the client MAY choose to make value is always longer than 512 octets), the client MAY choose to make
the initial connection using TCP. the initial connection using TCP.
If a client using the basic form sends a UDP request to the server If a client using the basic form sends a UDP request to the server named
named in an SRV record but does not receive a response, the client in an SRV record but does not receive a response, the client SHOULD send
SHOULD send the same request using TCP. If a client sends a UDP request the same request using TCP. If a client sends a UDP request to a server
to a server and receives an incomplete response, the client MUST send and receives an incomplete response, the client MUST send the same
the same request using TCP. This is due to the fact that a later part request using TCP. This is due to the fact that a later part of a
of a response might modify or negate the meaning of an earlier part of response might modify or negate the meaning of an earlier part of a
a response. response.
3.2 Secure form 2.2 Secure form
The secure form of rescap is quite similar to the basic form, but the The secure form of rescap is quite similar to the basic form, but the
connection is made using TCP under TLS [TLS]. The port <TBD> has been connection MUST be made using TCP under TLS [TLS]. No port has been
reserved by IANA for secure form rescap, and secure form rescap servers reserved by IANA for secure form rescap, so secure form rescap servers
SHOULD run on that port number. However, because the client is allowed MAY run on any port number. Because the client MUST find the port number
to find the port number using SRV records, the secure form rescap using SRV records, the secure form rescap server can run on any UDP and
server can run on any TCP port. TCP port.
rescap clients and servers MUST support the Secure form rescap clients and servers MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The client and TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The client and
the server MUST NOT support any cipher suites that do not contain both the server MUST NOT support any cipher suites that do not contain both
encryption and authentication. encryption and authentication.
3. Finding a rescap Server
SRV records [SRV] MUST be used for locating rescap servers. The request
sent to the DNS server is somewhat different than is specified in [SRV]
because the rescap client must indicate the type of resource 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 of the DNS name to be
resolved. The URI scheme name has an underscore character (_) prepended
to it, just as the service and prototype names do.
As described in section 2 of this specification, the basic form 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 only run
on TCP). It is inefficient to force the rescap client
to look up SRV records for both protocols, and doubling the number of
SRV records for the rescap protocol can have an adverse effect on the
domain name system. Thus, rescap clients MUST only resolve rescap SRV
records for the TCP protocol, and MUST assume that the same host that
was resolved for the TCP protocol will support rescap over the UDP
protocol as well. rescap clients MUST NOT attempt to resolve
rescap SRV records for the UDP protocol.
The two forms of rescap have different service names for the SRV
records. The basic form has the service name "rescap-basic" and the
secure form has the service name "rescap-secure".
For example, to find the basic server that is authoritative for the URI
"mailto:someone@example.com", the rescap client would resolve the SRV
record for the name:
_mailto._rescap-basic._tcp.example.com
To find the secure server that is authoritative for the URI
"mailto:someone@example.com", the rescap client would resolve the SRV
record for the name:
_mailto._rescap-secure._tcp.example.com
4. Security Considerations 4. Security Considerations
rescap users rely on the DNS for finding a rescap server. Unless the 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 DNS is secure, an attacker can cause a rescap user to get information
from the wrong server. from the wrong server.
Basic form rescap offers no authentication of the client, no Basic form rescap offers no authentication of the client, no
authentication of the server, and no privacy of the requests or authentication of the server, and no privacy of the requests or
responses. The secure form gives privacy of the request and the responses. The secure form gives privacy of the request and the
response, and allows the client to authenticate the server and the response, and allows the client to authenticate the server and the
skipping to change at line 220 skipping to change at line 210
[RESCAP-FORMAT] "The rescap Request and Response Format", [RESCAP-FORMAT] "The rescap Request and Response Format",
draft-hoffman-rescap-proto-format. draft-hoffman-rescap-proto-format.
[RESCAP-REQUIRE] "ResCap Requirements", draft-ietf-rescap-req. [RESCAP-REQUIRE] "ResCap Requirements", draft-ietf-rescap-req.
[SLP] "Service Location Protocol, Version 2.", RFC 2608, and "Service [SLP] "Service Location Protocol, Version 2.", RFC 2608, and "Service
Templates and Service: Schemes", RFC 2609. Templates and Service: Schemes", RFC 2609.
[SRV] "A DNS RR for specifying the location of services (DNS SRV)", RFC [SRV] "A DNS RR for specifying the location of services (DNS SRV)", RFC
2052. NOTE: RFC 2052 is being updated by 2782.
draft-ietf-dnsind-rfc2052bis. The examples in this document are
based on the Internet Draft, not on RFC 2052.
[TLS] "TLS Protocol", RFC 2246. [TLS] "TLS Protocol", RFC 2246.
A. IANA Considerations A. IANA Considerations
A.1 Registration for rescap URL Scheme A.1 Registration for rescap-basic URL Scheme
URL scheme name: rescap URL scheme name: rescap-basic
URL scheme syntax: <scheme-name>://<hostport>?<base64-of-request> URL scheme syntax: rescap-basic://<hostport>?<base64-of-request>
<scheme-name> is either the string "rescap" for basic form or
"rescap-secure" for secure form. <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 <hostport> is exactly as defined in RFC 2396. <base64-of-request>
on the host "an.example.com" at the default port of 283, the URL is the Base64 encoding of a rescap request.
would be rescap://an.example.com/SK398cske002CcksleEEx
For example, to indicate a query to the secure form rescap server For example, to indicate a query to the basic form rescap server on
on the host at 10.20.30.40 at port 1234, the URL would be 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 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 Registration for rescap-secure URL Scheme
URL scheme name: rescap-secure
URL scheme syntax: 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 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 rescap-secure://10.20.30.40:1234/SK398cske002CcksleEEx
Character encoding considerations: None. All three parts are expressed Character encoding considerations: None. All three parts are expressed
in US-ASCII. in US-ASCII.
Intended usage: To identify queries rescap servers. The resolution of a Intended usage: To identify redirected queries to rescap servers. The
rescap URL will normally cause a query to be sent to the named resolution of a rescap URL will cause a query to be sent to the
server. The resolver would decode the Base64 of the third part of named server. The resolver would decode the Base64 of the third
the URL and send it to the specified port (or the default port of part of the URL and send it to the specified port (or the default
283 if no port is specified in the URL) using the TCP protocol. 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: Applications and/or protocols which use this URL scheme name:
This document describes the rescap protocol. This document describes the rescap protocol.
Interoperability considerations: None known. Interoperability considerations: None known.
Security considerations: Same as in this document. Security considerations: Same as in this document.
Relevant publications: This document. Relevant publications: This document.
Person & email address to contact for further information: Person & email address to contact for further information:
Paul Hoffman <phoffman@imc.org> Paul Hoffman <phoffman@imc.org>
Author/Change controller: Author/Change controller:
Paul Hoffman <phoffman@imc.org> Paul Hoffman <phoffman@imc.org>
A.2 Port reservation A.3 Port reservation
IANA has reserved port 283 for basic form rescap. A port has been IANA has reserved port 283 for basic form rescap. A port has been
requested for secure form rescap. requested for secure form rescap.
B. Acknowledgments B. Acknowledgments
Graham Klyne provided suggestions for early versions of the first draft. Graham Klyne provided suggestions for early versions of the first draft.
C. Changes Between Versions of This Document C. Changes Between the -00 and -01 Versions of This Document
This document began as a single document that included the material Reversed the order of sections 2 and 3 because the new document needs to
in [RESCAP-FORMAT]. It was split into two so that people could think describe the basic and secure forms before describing how to find them.
about each part separately. Thus, a great deal has been cut out and
moved to the other draft.
The biggest change in this document is that the protocol now has two Made SRV records mandatory and dropped the previous kludge.
forms: basic and secure. Made many changes based on this.
Noted that the mailing list is now for the WG. Made using the port number from the SRV record mandatory.
Updated the references. Changed the SRV lookup to use TCP to reduce confusion between the basic
and secure forms.
Updated the URL registration for secure form. Updated the reference for SRV records.
Significantly updated the URL registration.
D. Author Contact Information D. Author Contact Information
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 USA Santa Cruz, CA 95060 USA
phoffman@imc.org phoffman@imc.org
 End of changes. 26 change blocks. 
107 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/