draft-ietf-rescap-req-00.txt   draft-ietf-rescap-req-01.txt 
Internet Draft John Beck
Document: draft-ietf-rescap-req-00.txt Sun Microsystems RESCAP J. Beck
December 9, 1999 Internet-Draft Sun Microsystems
Expires June 9, 2000 Expires: December 21, 2002 June 22, 2002
ResCap Requirements ResCap Requirements
draft-ietf-rescap-req-01.txt
Status of this memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see 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. http://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 21, 2002.
http://www.ietf.org/ietf/1id-abstracts.txt
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
A variety of resource identifiers have been widely deployed on the A variety of resource identifiers have been widely deployed on the
Internet as a means of identifying various resources, services, and Internet as a means of identifying various resources, services, and
destinations. However, a means of attaching a set of attributes or destinations. However, a means of attaching a set of attributes or
characteristics to a given resource identifier and subsequently characteristics to a given resource identifier and subsequently
assessing those attributes or characteristics has not been specified assessing those attributes or characteristics has not been specified
and deployed. and deployed.
Two tasks are envisioned. The first task will be to define a general Two tasks are envisioned. The first task will be to define a general
resolution protocol that will translate resource identifiers to a resolution protocol that will translate resource identifiers to a
list of attributes. The second task will be to define an list of attributes. The second task will be to define an
administrative model and update protocol that can be used to set administrative model and update protocol that can be used to set up
up and maintain the information the resolution protocol accesses. and maintain the information the resolution protocol accesses.
This document defines the requirements for these two protocols. This document defines the requirements for these two protocols.
0. Discussion Table of Contents
1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General requirements . . . . . . . . . . . . . . . . . . . . 3
3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Resolution protocol requirements . . . . . . . . . . . . . . 4
4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Reply data . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3 Granularity . . . . . . . . . . . . . . . . . . . . . . . . 4
4.4 Expiration . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5 Referral . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.7 Server location . . . . . . . . . . . . . . . . . . . . . . 6
4.8 Preferences . . . . . . . . . . . . . . . . . . . . . . . . 6
4.9 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.10 Replication and Synchronization . . . . . . . . . . . . . . 6
5. Administrative update protocol requirements . . . . . . . . 7
5.1 Access control . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5 Replication and Synchronization . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
A. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
B. Revision history . . . . . . . . . . . . . . . . . . . . . . 9
B.1 Initial revision (beck-00): April 15, 1999 . . . . . . . . . 9
B.2 beck-00 -> beck-01: May 14, 1999 . . . . . . . . . . . . . . 9
B.3 beck-01 -> beck-02: June 15, 1999 . . . . . . . . . . . . . 10
B.4 beck-02 -> beck-02a: November 23, 1999 . . . . . . . . . . . 10
B.5 beck-02a -> beck-03: December 1, 1999 . . . . . . . . . . . 10
B.6 beck-03 -> rescap-00: December 9, 1999 . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . 12
1. Discussion
This draft is being discussed on the ResCap mailing list at This draft is being discussed on the ResCap mailing list at
<rescap@cs.utk.edu>. Subscription requests can be sent to <rescap@cs.utk.edu>. Subscription requests can be sent to <rescap-
<rescap-request@cs.utk.edu> (send an email message with the request@cs.utk.edu> (send an email message with the word "subscribe"
word "subscribe" in the body). More information on the mailing in the body). More information on the mailing list along with an
list along with an archive of back messages is available at archive of back messages is available at <ftp://cs.utk.edu/pub/
<ftp://cs.utk.edu/pub/rescap>. rescap>.
1. Introduction 2. Introduction
An attribute is a named characteristic of a resource identifier with An attribute is a named characteristic of a resource identifier with
a value that is meaningful in the context in which it is used. An a value that is meaningful in the context in which it is used. An
attribute may be requested from a ResCap server. An example of an attribute may be requested from a ResCap server. An example of an
attribute might be a content type that an email address is capable attribute might be a content type that an email address is capable of
of receiving. receiving.
A capability is a named set of one or more attributes that is A capability is a named set of one or more attributes that is
meaningful in the context in which it is evaluated. A capability meaningful in the context in which it is evaluated. A capability may
may be requested from a ResCap server. An example of a capability be requested from a ResCap server. An example of a capability would
would be the complete set of content types that an email address be the complete set of content types that an email address could
could receive. receive.
A particularly important resolution service of the general type A particularly important resolution service of the general type
described in the Abstract is one which, when given a mail address described in the Abstract is one which, when given a mail address
identifying a particular mail recipient, will return a series of identifying a particular mail recipient, will return a series of
attributes describing the capabilities of that recipient. This attributes describing the capabilities of that recipient. This
differs from a directory service in that no searching or other differs from a directory service in that no searching or other
advanced query operations are involved. Likewise; this is not advanced query operations are involved. Likewise; this is not a
a discovery protocol. discovery protocol.
2. General requirements 3. General requirements
2.1 Security 3.1 Security
The protocols must include support for authenticated messages The protocols must include support for authenticated messages between
between clients and servers. Specifically, it must be possible clients and servers. Specifically, it must be possible for a rescap
for a rescap client requesting information to reliably identify client requesting information to reliably identify the server who is
the server who is the source of the response. The client should the source of the response. The client should be able to require a
be able to require a server to authenticate itself. The question server to authenticate itself. The question as to whether the server
as to whether the server is authorized to respond with the is authorized to respond with the information requested is outside
information requested is outside the scope of the protocols. the scope of the protocols. See the Security Considerations section
See the Security Considerations section for more information. for more information.
Similarly, it must be possible for a rescap server to reliably Similarly, it must be possible for a rescap server to reliably
identify the client who is making the request for information. identify the client who is making the request for information. The
The server should be able to require the client to authenticate server should be able to require the client to authenticate itself.
itself. The question as to whether the client is authorized to The question as to whether the client is authorized to request the
request the information is outside the scope of the protocols. information is outside the scope of the protocols. See the Security
See the Security Considerations section for more information.
Because the principal purpose of the protocols is the
dissemination of public information, support for confidentiality
services is explicitly not required from the protocols.
Nevertheless, specific attributes or capabilities may themselves
be encrypted, unbeknownst to the protocol. Also, local security
policies may require the use of a secure transport layer that
includes confidentiality services. See the Security
Considerations section for more information. Considerations section for more information.
3. Resolution protocol requirements Because the principal purpose of the protocols is the dissemination
of public information, support for confidentiality services is
explicitly not required from the protocols. Nevertheless, specific
attributes or capabilities may themselves be encrypted, unbeknownst
to the protocol. Also, local security policies may require the use
of a secure transport layer that includes confidentiality services.
See the Security Considerations section for more information.
4. Resolution protocol requirements
Throughout the rest of this section, "the protocol" refers to the Throughout the rest of this section, "the protocol" refers to the
resolution protocol. resolution protocol.
3.1 Scalability 4.1 Scalability
The protocol must be highly scalable both for number of entries The protocol must be highly scalable both for number of entries in
in the database and number of entries per second resolved. the database and number of entries per second resolved.
Example: Mail services with tens of millions of users could Example: Mail services with tens of millions of users could easily
easily expect tens of millions of requests per day for client expect tens of millions of requests per day for client attribute
attribute information. information.
3.2 Reply data 4.2 Reply data
The protocol must be able to support attributes and capabilities The protocol must be able to support attributes and capabilities that
that are arbitrarily long text or binary values. The protocol are arbitrarily long text or binary values. The protocol should be
should be optimized for the exchange of relatively short length optimized for the exchange of relatively short length resource
resource identifiers and attribute values. By way of example, the identifiers and attribute values. By way of example, the distinction
distinction between short and long could be determined by whether between short and long could be determined by whether or not the
or not the request and response fit in an ordinary UDP packet. request and response fit in an ordinary UDP packet.
Servers must either provide the information requested, provide a Servers must either provide the information requested, provide a
referral indicating from where the information may be requested, referral indicating from where the information may be requested, or
or indicate the information is not available. Servers may forward indicate the information is not available. Servers may forward
requests on behalf of clients, but the forward must be transparent requests on behalf of clients, but the forward must be transparent to
to the client. the client.
3.3 Granularity 4.3 Granularity
A mechanism needs to exist whereby a subset of capabilities for A mechanism needs to exist whereby a subset of capabilities for a
a resource can be fetched. I.e., the protocol request syntax resource can be fetched. I.e., the protocol request syntax should be
should be able ask for one or more features instead of all of able ask for one or more features instead of all of them at once.
them at once. However, the client also needs to be able to ask However, the client also needs to be able to ask for all capabilities
for all capabilities known to the server without naming all of known to the server without naming all of them.
them.
Example: A client might only want to know the S/MIME capabilities Example: A client might only want to know the S/MIME capabilities of
of a recipient, but not care about its media features. a recipient, but not care about its media features.
3.4 Expiration 4.4 Expiration
Some means to indicate the expected lifetime of a capability Some means to indicate the expected lifetime of a capability is
is required, so that a client application can judge whether, required, so that a client application can judge whether, or when,
or when, the information should be considered stale. the information should be considered stale.
The expectation is that data will be infrequently updated, and The expectation is that data will be infrequently updated, and that
that the granularity for time-stamps would be in seconds. the granularity for time-stamps would be in seconds.
The protocol should also support a mechanism for indicating the The protocol should also support a mechanism for indicating the "last
"last changed date" of a given attribute. changed date" of a given attribute.
Example: The ResCap server may believe that the recipient is only Example: The ResCap server may believe that the recipient is only
temporarily unable to receive large mail messages. temporarily unable to receive large mail messages.
3.5 Referral 4.5 Referral
Some sort of request referral mechanism is needed. In other Some sort of request referral mechanism is needed. In other words,
words, the protocol must support a mechanism whereby a response the protocol must support a mechanism whereby a response can indicate
can indicate "I don't know, but go ask the ResCap server at "I don't know, but go ask the ResCap server at address X." or "use
address X." or "use the following URL to retrieve the ResCap the following URL to retrieve the ResCap response you requested."
response you requested." That is, the response might be a simple That is, the response might be a simple DNS name, or it might be a
DNS name, or it might be a full ResCap URL. full ResCap URL.
Example: A server might delegate all requests for S/MIME Example: A server might delegate all requests for S/MIME certificate
certificate information to a different server that keeps track information to a different server that keeps track of that type of
of that type of information. information.
3.6 Security 4.6 Security
The protocol must be able to handle authenticated queries. The protocol must be able to handle authenticated queries. The
The protocol must also support transmission of signed and/or protocol must also support transmission of signed and/or encrypted
encrypted responses. The protocol should allow for a ResCap responses. The protocol should allow for a ResCap server to hold and
server to hold and return "pre-signed" responses. This would return "pre-signed" responses. This would allow it to hold
allow it to hold capability information signed by the controller capability information signed by the controller of the resource to
of the resource to which it refers, and also to sign responses which it refers, and also to sign responses off-line to avoid the
off-line to avoid the need to perform signature computations at need to perform signature computations at the time of responding to a
the time of responding to a query. This may imply a need to query. This may imply a need to apply a signature to just part of a
apply a signature to just part of a response. response.
Servers may require clients to use authenticated requests. Servers may require clients to use authenticated requests. Clients
Clients are not required to be able to create authenticated are not required to be able to create authenticated queries. Such
queries. Such clients will not be able to make requests of clients will not be able to make requests of servers requiring
servers requiring authenticated queries; such servers might authenticated queries; such servers might regard this as a feature.
regard this as a feature.
Clients may require servers to use authenticated responses. Clients may require servers to use authenticated responses. Servers
Servers must be able to create authenticated responses. must be able to create authenticated responses.
Controls on which attributes will be announced should exist. Controls on which attributes will be announced should exist.
Note that consideration of transport-level security is out of Note that consideration of transport-level security is out of scope
scope here; an appropriate mechanism such as TLS or IPSec should here; an appropriate mechanism such as TLS or IPSec should be used
be used instead. instead.
Example: A server might give less information to a client that Example: A server might give less information to a client that is
is unauthenticated than to one that is authenticated. Some unauthenticated than to one that is authenticated. Some information
information from the server may be important enough for the from the server may be important enough for the server to want to
server to want to prevent tampering, or even to prevent snoopers prevent tampering, or even to prevent snoopers from reading.
from reading.
3.7 Server location 4.7 Server location
DNS resource records should be used to determine a protocol DNS resource records should be used to determine a protocol server.
server.
Example: The ResCap server that provides responses for resources Example: The ResCap server that provides responses for resources at
at "example.com" might itself be running on a host other than "example.com" might itself be running on a host other than
"example.com", such as if the administrator of "example.com" has "example.com", such as if the administrator of "example.com" has
outsourced ResCap services to another company. outsourced ResCap services to another company.
3.8 Preference 4.8 Preferences
Preferences for a set of capabilities, if needed, are to be a Preferences for a set of capabilities, if needed, are to be a
supplied in a schema-specific fashion. supplied in a schema-specific fashion.
Example: A recipient might strongly prefer image/tiff files over Example: A recipient might strongly prefer image/tiff files over
image/jpeg because s/he can display image/tiff on his/her system image/jpeg because s/he can display image/tiff on his/her system
without launching an external application. without launching an external application.
3.9 Simplicity 4.9 Simplicity
The protocol should be sufficiently simple that it allows The protocol should be sufficiently simple that it allows
implementation of client and/or server functionality in very implementation of client and/or server functionality in very small,
small, low cost devices (e.g. telephones, modems, printers, low cost devices (e.g. telephones, modems, printers, smart-cards,
smart-cards, etc.). etc.).
3.10 Replication and Synchronization 4.10 Replication and Synchronization
We need to define the model for consistency between replicas - We need to define the model for consistency between replicas - e.g.
e.g. if a client is using one replica for queries and has if a client is using one replica for queries and has to fail over to
to fail over to another, what assumptions can the client make another, what assumptions can the client make about the consistency
about the consistency between the two replicas? between the two replicas?
We should consider whether to assume strict master-slave We should consider whether to assume strict master-slave as this
as this choice would severely limit scalability of the service. choice would severely limit scalability of the service. Multi-master
Multi-master seems preferable, but this impacts the protocol as seems preferable, but this impacts the protocol as hooks are needed
hooks are needed to allow clients to make sense of the data if to allow clients to make sense of the data if they need to get it
they need to get it from multiple servers. from multiple servers.
4. Administrative update protocol requirements 5. Administrative update protocol requirements
Throughout the rest of this section, "the protocol" refers to the Throughout the rest of this section, "the protocol" refers to the
administrative update protocol. administrative update protocol.
4.1 Access control 5.1 Access control
Authentication of anyone updating the database is required. Authentication of anyone updating the database is required.
Example: Individual mail users should be able to update some or Example: Individual mail users should be able to update some or all
all of the information about them in the database, but such of the information about them in the database, but such updates must
updates must be done with authentication to prevent others from be done with authentication to prevent others from maliciously
maliciously entering false information. entering false information.
4.2 Inheritance 5.2 Inheritance
The protocol must support inheritance. Specifically, mechanisms The protocol must support inheritance. Specifically, mechanisms must
must be provided by which administrators can set default values be provided by which administrators can set default values for
for members of their administrative domains. members of their administrative domains.
If a change is made to a default resource capability value that If a change is made to a default resource capability value that has
has previously been inherited by some other resource, then the previously been inherited by some other resource, then the inheritor
inheritor should receive the new value. should receive the new value.
Example: The media features for all addresses at a particular Example: The media features for all addresses at a particular mail
mail server might be the same because the mail server processes server might be the same because the mail server processes all
all messages at all addresses. messages at all addresses.
4.3 Scalability 5.3 Scalability
The protocol must support atomic processing of request messages. The protocol must support atomic processing of request messages.
This processing does not include updating any replicated sources This processing does not include updating any replicated sources for
for the information nor. The client should receive a completion the information nor. The client should receive a completion response
response from the server, but the underlying protocol (if used from the server, but the underlying protocol (if used over UDP) might
over UDP) might require the client to retransmit its request at require the client to retransmit its request at appropriate intervals
appropriate intervals until it receives such a response. until it receives such a response.
4.4 Security 5.4 Security
The protocol must include support for authenticated messages. The protocol must include support for authenticated messages.
Servers and clients must use authenticated requests and responses Servers and clients must use authenticated requests and responses to
to effect changes to attributes or capabilities. effect changes to attributes or capabilities.
4.5 Replication and Synchronization 5.5 Replication and Synchronization
SRV and/or NAPTR resource records may be used to determine a SRV and/or NAPTR resource records may be used to determine a protocol
protocol server. [SRV, NAPTR] server. [SRV, NAPTR]
5. Security Considerations 6. Security Considerations
Security issues are discussed in sections 2.1, 3.6, 4.1 and 4.4 of Security issues are discussed in sections 2.1, 3.6, 4.1 and 4.4 of
this memo. this memo.
It is also worth noting that the data which these protocols will be It is also worth noting that the data which these protocols will be
designed to deal with are meant to be public, not private. designed to deal with are meant to be public, not private.
However, support for authentication should be included in the However, support for authentication should be included in the
resolution protocol to permit administrators to restrict the resolution protocol to permit administrators to restrict the
attributes that are returned in response to a request according to a attributes that are returned in response to a request according to a
locally specified security policy. The security policy may require locally specified security policy. The security policy may require
the use of a transport security protocol, e.g., TLS [TLS], to provide the use of a transport security protocol, e.g., TLS [TLS], to provide
additional security services not supported by these protocols. additional security services not supported by these protocols.
6. Acknowledgements 7. Acknowledgements
The author would like to thank Paul Hoffman, Graham Klyne, Ned Freed, The author would like to thank Paul Hoffman, Graham Klyne, Ned Freed,
James Galvin and Keith Moore for their assistance. James Galvin and Keith Moore for their assistance.
7. References References
[CONNEG] "A Syntax for Describing Media Feature Sets", RFC 2533.
[CONNEG-MEDIA] "MIME content types in media feature expressions",
draft-ietf-conneg-feature-type.
[NAPTR] "Resolution of Uniform Resource Identifiers using the [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
Domain Name System", RFC 2168. location of services (DNS SRV)", RFC 2052, October 1996.
[SRV] "A DNS RR for specifying the location of services (DNS SRV)", [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform
RFC 2052. Resource Identifiers using the Domain Name System", RFC
2168, June 1997.
[TLS] "The TLS Protocol Version 1.0", RFC 2246 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[UDP] "User Datagram Protocol", RFC 768. [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
8. Author's Address Author's Address
John Beck John Beck
Sun Microsystems Sun Microsystems
901 San Antonio Road 901 San Antonio Road M/S U-MPK-17-202
M/S U-MPk-17-202
Palo Alto, CA 94303-4900 Palo Alto, CA 94303-4900
(650) 786-8078 US
jbeck+rescap@eng.sun.com
I. Issues Phone: +1-650-786-8078
EMail: john.beck+rescap@sun.com
Appendix A. Issues
1. Does section 3.6 need further clean-up, particularly the first 1. Does section 3.6 need further clean-up, particularly the first
paragraph? paragraph?
2. Are sections 4.1 and 4.4 redundant? 2. Are sections 4.1 and 4.4 redundant?
3. Section 3.10 currently lays out no requirements, but asks some 3. Section 3.10 currently lays out no requirements, but asks some
questions and raises some issues which need to be addressed in questions and raises some issues which need to be addressed in
order for the proper requirements to be determined. order for the proper requirements to be determined.
X. Revision history Appendix B. Revision history
X.0 Initial revision (beck-00): April 15, 1999 B.1 Initial revision (beck-00): April 15, 1999
X.1 beck-00 -> beck-01: May 14, 1999 B.2 beck-00 -> beck-01: May 14, 1999
* Added note to Abstract about this not being a discovery protocol. o Added note to Abstract about this not being a discovery protocol.
* Examples added throughout.
* Section 1.2 renamed from "Long replies" to "Reply data", and o Examples added throughout.
o Section 1.2 renamed from "Long replies" to "Reply data", and
clarified. clarified.
* Clarified section 1.4, and added note about support for a "last
o Clarified section 1.4, and added note about support for a "last
changed date". changed date".
* Section 1.6 renamed from "Privacy" to Security, and clarified,
o Section 1.6 renamed from "Privacy" to Security, and clarified,
largely by absorbing section 2.2 (Privacy). As a result, section largely by absorbing section 2.2 (Privacy). As a result, section
2.3 (Inheritance) renumbered to 2.2 . 2.3 (Inheritance) renumbered to 2.2 .
* New section 4 (Acknowledgements) added, and old sections 4
o New section 4 (Acknowledgements) added, and old sections 4
(References) and 5 (Author's Address) renumbered to 5 and 6. (References) and 5 (Author's Address) renumbered to 5 and 6.
X.2 beck-01 -> beck-02: June 15, 1999 B.3 beck-01 -> beck-02: June 15, 1999
* New section 1.9 (Simplicity) added. o New section 1.9 (Simplicity) added.
X.3 beck-02 -> beck-02a: November 23, 1999 B.4 beck-02 -> beck-02a: November 23, 1999
* Added notes about infrequent updates and granularity of seconds o Added notes about infrequent updates and granularity of seconds to
to section 1.4 (Expiration). section 1.4 (Expiration).
* Added note about transport-level security being out of scope to
o Added note about transport-level security being out of scope to
section 1.6 (Security), and did some word-smithing. section 1.6 (Security), and did some word-smithing.
* Section 1.7 (Server location): specific references to SRV and
NAPTR replaced by general reference to DNS. Deleted o Section 1.7 (Server location): specific references to SRV and
corresponding references from section 5 (References). Also NAPTR replaced by general reference to DNS. Deleted corresponding
rewrote example in section 1.7 . references from section 5 (References). Also rewrote example in
* Section 1.8 (Preference) changed to be schema-specific. section 1.7 .
* Added note about the effect of changing a default resource to
o Section 1.8 (Preference) changed to be schema-specific.
o Added note about the effect of changing a default resource to
section 2.2 (Inheritance). section 2.2 (Inheritance).
* Added note about public vs. private date to section 3 (Security
o Added note about public vs. private date to section 3 (Security
Considerations). Considerations).
* Added appendix X (Revision history).
beck-02a -> beck-03: December 1, 1999 o Added appendix X (Revision history).
* New section 1 (Introduction) and 2 (General requirements); old B.5 beck-02a -> beck-03: December 1, 1999
o New section 1 (Introduction) and 2 (General requirements); old
sections 1 through 6 renumbered to 3 through 8. sections 1 through 6 renumbered to 3 through 8.
* New section 4.3 (Scalability) added.
* Section 3.2 (Reply data) rewritten.
beck-03 -> rescap-00: December 9, 1999 o New section 4.3 (Scalability) added.
* ResCap is now a WG, so document name changes. o Section 3.2 (Reply data) rewritten.
* Added note about authentication to Security Considerations.
* Added appendix I for open issues. B.6 beck-03 -> rescap-00: December 9, 1999
* Added sections 2.1 and 4.4, and added to 3.6 (all on Security).
* Added sections 3.10 and 4.5 (on Replication and Synchronization). o ResCap is now a WG, so document name changes.
o Added note about authentication to Security Considerations.
o Added appendix I for open issues.
o Added sections 2.1 and 4.4, and added to 3.6 (all on Security).
o Added sections 3.10 and 4.5 (on Replication and Synchronization).
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 93 change blocks. 
214 lines changed or deleted 264 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/