[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-beck-rescap-req) 00 01

RESCAP                                                           J. Beck
Internet-Draft                                          Sun Microsystems
Expires: December 21, 2002                                 June 22, 2002


                          ResCap Requirements
                      draft-ietf-rescap-req-01.txt

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.

   This Internet-Draft will expire on December 21, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   A variety of resource identifiers have been widely deployed on the
   Internet as a means of identifying various resources, services, and
   destinations.  However, a means of attaching a set of attributes or
   characteristics to a given resource identifier and subsequently
   assessing those attributes or characteristics has not been specified
   and deployed.

   Two tasks are envisioned.  The first task will be to define a general
   resolution protocol that will translate resource identifiers to a
   list of attributes.  The second task will be to define an
   administrative model and update protocol that can be used to set up
   and maintain the information the resolution protocol accesses.



Beck                    Expires December 21, 2002               [Page 1]


Internet-Draft             RESCAP Requirements                 June 2002


   This document defines the requirements for these two protocols.

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













Beck                    Expires December 21, 2002               [Page 2]


Internet-Draft             RESCAP Requirements                 June 2002


1. Discussion

   This draft is being discussed on the ResCap mailing list at
   <rescap@cs.utk.edu>.  Subscription requests can be sent to <rescap-
   request@cs.utk.edu> (send an email message with the word "subscribe"
   in the body).  More information on the mailing list along with an
   archive of back messages is available at <ftp://cs.utk.edu/pub/
   rescap>.

2. Introduction

   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
   attribute may be requested from a ResCap server.  An example of an
   attribute might be a content type that an email address is capable of
   receiving.

   A capability is a named set of one or more attributes that is
   meaningful in the context in which it is evaluated.  A capability may
   be requested from a ResCap server.  An example of a capability would
   be the complete set of content types that an email address could
   receive.

   A particularly important resolution service of the general type
   described in the Abstract is one which, when given a mail address
   identifying a particular mail recipient, will return a series of
   attributes describing the capabilities of that recipient.  This
   differs from a directory service in that no searching or other
   advanced query operations are involved.  Likewise; this is not a
   discovery protocol.

3. General requirements

3.1 Security

   The protocols must include support for authenticated messages between
   clients and servers.  Specifically, it must be possible for a rescap
   client requesting information to reliably identify the server who is
   the source of the response.  The client should be able to require a
   server to authenticate itself.  The question as to whether the server
   is authorized to respond with the information requested is outside
   the scope of the protocols.  See the Security Considerations section
   for more information.

   Similarly, it must be possible for a rescap server to reliably
   identify the client who is making the request for information.  The
   server should be able to require the client to authenticate itself.
   The question as to whether the client is authorized to request the



Beck                    Expires December 21, 2002               [Page 3]


Internet-Draft             RESCAP Requirements                 June 2002


   information is outside the scope of the protocols.  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.

4. Resolution protocol requirements

   Throughout the rest of this section, "the protocol" refers to the
   resolution protocol.

4.1 Scalability

   The protocol must be highly scalable both for number of entries in
   the database and number of entries per second resolved.

   Example: Mail services with tens of millions of users could easily
   expect tens of millions of requests per day for client attribute
   information.

4.2 Reply data

   The protocol must be able to support attributes and capabilities that
   are arbitrarily long text or binary values.  The protocol should be
   optimized for the exchange of relatively short length resource
   identifiers and attribute values.  By way of example, the distinction
   between short and long could be determined by whether or not the
   request and response fit in an ordinary UDP packet.

   Servers must either provide the information requested, provide a
   referral indicating from where the information may be requested, or
   indicate the information is not available.  Servers may forward
   requests on behalf of clients, but the forward must be transparent to
   the client.

4.3 Granularity

   A mechanism needs to exist whereby a subset of capabilities for a
   resource can be fetched.  I.e., the protocol request syntax should be
   able ask for one or more features instead of all of them at once.
   However, the client also needs to be able to ask for all capabilities
   known to the server without naming all of them.




Beck                    Expires December 21, 2002               [Page 4]


Internet-Draft             RESCAP Requirements                 June 2002


   Example: A client might only want to know the S/MIME capabilities of
   a recipient, but not care about its media features.

4.4 Expiration

   Some means to indicate the expected lifetime of a capability is
   required, so that a client application can judge whether, or when,
   the information should be considered stale.

   The expectation is that data will be infrequently updated, and that
   the granularity for time-stamps would be in seconds.

   The protocol should also support a mechanism for indicating the "last
   changed date" of a given attribute.

   Example: The ResCap server may believe that the recipient is only
   temporarily unable to receive large mail messages.

4.5 Referral

   Some sort of request referral mechanism is needed.  In other words,
   the protocol must support a mechanism whereby a response can indicate
   "I don't know, but go ask the ResCap server at address X." or "use
   the following URL to retrieve the ResCap response you requested."
   That is, the response might be a simple DNS name, or it might be a
   full ResCap URL.

   Example: A server might delegate all requests for S/MIME certificate
   information to a different server that keeps track of that type of
   information.

4.6 Security

   The protocol must be able to handle authenticated queries.  The
   protocol must also support transmission of signed and/or encrypted
   responses.  The protocol should allow for a ResCap server to hold and
   return "pre-signed" responses.  This would allow it to hold
   capability information signed by the controller of the resource to
   which it refers, and also to sign responses off-line to avoid the
   need to perform signature computations at the time of responding to a
   query.  This may imply a need to apply a signature to just part of a
   response.

   Servers may require clients to use authenticated requests.  Clients
   are not required to be able to create authenticated queries.  Such
   clients will not be able to make requests of servers requiring
   authenticated queries; such servers might regard this as a feature.




Beck                    Expires December 21, 2002               [Page 5]


Internet-Draft             RESCAP Requirements                 June 2002


   Clients may require servers to use authenticated responses.  Servers
   must be able to create authenticated responses.

   Controls on which attributes will be announced should exist.

   Note that consideration of transport-level security is out of scope
   here; an appropriate mechanism such as TLS or IPSec should be used
   instead.

   Example: A server might give less information to a client that is
   unauthenticated than to one that is authenticated.  Some information
   from the server may be important enough for the server to want to
   prevent tampering, or even to prevent snoopers from reading.

4.7 Server location

   DNS resource records should be used to determine a protocol server.

   Example:  The ResCap server that provides responses for resources at
   "example.com" might itself be running on a host other than
   "example.com", such as if the administrator of "example.com" has
   outsourced ResCap services to another company.

4.8 Preferences

   Preferences for a set of capabilities, if needed, are to be a
   supplied in a schema-specific fashion.

   Example: A recipient might strongly prefer image/tiff files over
   image/jpeg because s/he can display image/tiff on his/her system
   without launching an external application.

4.9 Simplicity

   The protocol should be sufficiently simple that it allows
   implementation of client and/or server functionality in very small,
   low cost devices (e.g.  telephones, modems, printers, smart-cards,
   etc.).

4.10 Replication and Synchronization

   We need to define the model for consistency between replicas - e.g.
   if a client is using one replica for queries and has to fail over to
   another, what assumptions can the client make about the consistency
   between the two replicas?

   We should consider whether to assume strict master-slave as this
   choice would severely limit scalability of the service.  Multi-master



Beck                    Expires December 21, 2002               [Page 6]


Internet-Draft             RESCAP Requirements                 June 2002


   seems preferable, but this impacts the protocol as hooks are needed
   to allow clients to make sense of the data if they need to get it
   from multiple servers.

5. Administrative update protocol requirements

   Throughout the rest of this section, "the protocol" refers to the
   administrative update protocol.

5.1 Access control

   Authentication of anyone updating the database is required.

   Example: Individual mail users should be able to update some or all
   of the information about them in the database, but such updates must
   be done with authentication to prevent others from maliciously
   entering false information.

5.2 Inheritance

   The protocol must support inheritance.  Specifically, mechanisms must
   be provided by which administrators can set default values for
   members of their administrative domains.

   If a change is made to a default resource capability value that has
   previously been inherited by some other resource, then the inheritor
   should receive the new value.

   Example: The media features for all addresses at a particular mail
   server might be the same because the mail server processes all
   messages at all addresses.

5.3 Scalability

   The protocol must support atomic processing of request messages.
   This processing does not include updating any replicated sources for
   the information nor.  The client should receive a completion response
   from the server, but the underlying protocol (if used over UDP) might
   require the client to retransmit its request at appropriate intervals
   until it receives such a response.

5.4 Security

   The protocol must include support for authenticated messages.
   Servers and clients must use authenticated requests and responses to
   effect changes to attributes or capabilities.





Beck                    Expires December 21, 2002               [Page 7]


Internet-Draft             RESCAP Requirements                 June 2002


5.5 Replication and Synchronization

   SRV and/or NAPTR resource records may be used to determine a protocol
   server.  [SRV, NAPTR]

6. Security Considerations

   Security issues are discussed in sections 2.1, 3.6, 4.1 and 4.4 of
   this memo.

   It is also worth noting that the data which these protocols will be
   designed to deal with are meant to be public, not private.

   However, support for authentication should be included in the
   resolution protocol to permit administrators to restrict the
   attributes that are returned in response to a request according to a
   locally specified security policy.  The security policy may require
   the use of a transport security protocol, e.g., TLS [TLS], to provide
   additional security services not supported by these protocols.

7. Acknowledgements

   The author would like to thank Paul Hoffman, Graham Klyne, Ned Freed,
   James Galvin and Keith Moore for their assistance.

References

   [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
              location of services (DNS SRV)", RFC 2052, October 1996.

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

   [RFC2246]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
              and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
              January 1999.

   [RFC2533]  Klyne, G., "A Syntax for Describing Media Feature Sets",
              RFC 2533, March 1999.











Beck                    Expires December 21, 2002               [Page 8]


Internet-Draft             RESCAP Requirements                 June 2002


Author's Address

   John Beck
   Sun Microsystems
   901 San Antonio Road M/S U-MPK-17-202
   Palo Alto, CA  94303-4900
   US

   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
       paragraph?

   2.  Are sections 4.1 and 4.4 redundant?

   3.  Section 3.10 currently lays out no requirements, but asks some
       questions and raises some issues which need to be addressed in
       order for the proper requirements to be determined.


Appendix B. Revision history

B.1 Initial revision (beck-00): April 15, 1999


B.2 beck-00 -> beck-01: May 14, 1999

   o  Added note to Abstract about this not being a discovery protocol.

   o  Examples added throughout.

   o  Section 1.2 renamed from "Long replies" to "Reply data", and
      clarified.

   o  Clarified section 1.4, and added note about support for a "last
      changed date".

   o  Section 1.6 renamed from "Privacy" to Security, and clarified,
      largely by absorbing section 2.2 (Privacy).  As a result, section
      2.3 (Inheritance) renumbered to 2.2 .

   o  New section 4 (Acknowledgements) added, and old sections 4
      (References) and 5 (Author's Address) renumbered to 5 and 6.





Beck                    Expires December 21, 2002               [Page 9]


Internet-Draft             RESCAP Requirements                 June 2002


B.3 beck-01 -> beck-02: June 15, 1999

   o  New section 1.9 (Simplicity) added.


B.4 beck-02 -> beck-02a: November 23, 1999

   o  Added notes about infrequent updates and granularity of seconds to
      section 1.4 (Expiration).

   o  Added note about transport-level security being out of scope to
      section 1.6 (Security), and did some word-smithing.

   o  Section 1.7 (Server location): specific references to SRV and
      NAPTR replaced by general reference to DNS.  Deleted corresponding
      references from section 5 (References).  Also rewrote example in
      section 1.7 .

   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).

   o  Added note about public vs.  private date to section 3 (Security
      Considerations).

   o  Added appendix X (Revision history).


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.

   o  New section 4.3 (Scalability) added.

   o  Section 3.2 (Reply data) rewritten.


B.6 beck-03 -> rescap-00: December 9, 1999

   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).



Beck                    Expires December 21, 2002              [Page 10]


Internet-Draft             RESCAP Requirements                 June 2002


   o  Added sections 3.10 and 4.5 (on Replication and Synchronization).


















































Beck                    Expires December 21, 2002              [Page 11]


Internet-Draft             RESCAP Requirements                 June 2002


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.



















Beck                    Expires December 21, 2002              [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/