Internet DRAFT - draft-ietf-whip-wps-reqs-summary
draft-ietf-whip-wps-reqs-summary
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:08:22 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 13 Dec 1994 23:00:00 GMT
ETag: "323e65-2e5a-2eee2770"
Accept-Ranges: bytes
Content-Length: 11866
Connection: close
Content-Type: text/plain
draft-ietf-whip-wps-reqs-summary-01.txt WHIP Working Group
INTERNET DRAFT Dec 1994
Requirements for an Internet White Pages Service
Fri Dec 9 18:43:46 CST 1994
C. Allan Cargille
MCI
ACargille@mcimail.com
This draft document is being circulated for comment.
If consensus is reached it will be submitted to the RFC editor
for publication as an Informational RFC, to provide information
for the Internet community.
Please send comments to the author, or to the IETF IDS
(Integrated Directory Services) Working Group mailing list,
"ids@merit.edu".
This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract:
RFC1588 reported on a meeting held in November 1993 to
discuss the future of and approaches to a white pages
directory services for the Internet. This document
summarizes the requirements for an Internet white pages
service from that RFC, and can be used to measure proposed
solutions against these requirements.
Cargille Expires May, 1995 [Page 1]
DRAFT White Page Requirements Dec 1994
1. Introduction
RFC1588 reported on a meeting held in November 1993 to discuss
the future of and approaches to a white pages directory services
for the Internet. This document summarizes the requirements for
an Internet white pages service from that RFC, and can be used to
measure proposed solutions against these requirements.
Because this document is intended to summarize information
presented in RFC1588, detailed citations (ie, quotation marks and
page numbers) are not utilized.
2. What do I need to know to be able to read this document?
The only critical background reading is contained in RFC1588
[ref]. To be more knowledgeable about the directory protocols
involved, one might read information on X.500 [refs to X.500 doc
and summary RFCs] and the WHOIS++ protocol [rfc]. RFC1588
contains additional references.
3. Acknowledgements
Appendix I of RFC1588 contains a summary list of requirements,
which served as a starting point for this document (pp. 33-35).
That list was initially developed by Chris Weider and amended by
other discussion and meeting participants. Those participants
are listed in RFC1588 (p 31). Jon Postel and Celeste Anderson
wrote and edited RFC1588 following the meeting.
4. Requirements
Listed below are all the requirements which I found based on a
detailed pass through 1588. These are not in priority or order.
Some may be conflicting goals. In a following draft, I will
organize these into logical groupings and provide text describing
the intent or need for each. Some requirements may apply to
specific Internet WPS technologies. Please feel free to
recommend additional requirements -- the working group should
have the authority to add to or delete from this list:
Support Searching - Searching is the ability to find people
given some information about them.
Fast Searching
Support Retrieval - Retrieval is defined as obtaining
additional information associated with a person, such as an
address, telephone number, email mailbox, or security
certificate.
Cargille Expires May, 1995 [Page 2]
DRAFT White Page Requirements Dec 1994
Support Security Certificates - The Internet WPS should
support the storage and retrieval of security certificates
or public keys.
Accommodate multiple technologies
Simple
Common Ground approach
Lowest Common Denominator
High Functionality
Low Entry Cost (cookbook info on how to bring up new server)
Take advantage of deployed technology / existing
infrastructure (X.500 and other)
Reliable
Standardized naming scheme
Encourage multiple clients
Encourage multiple servers
Support interaction between servers
Support access to servers of various protocols
Fast Searching / "reasonable" search response time
Support additional data in records
Contain accurate data
Be Scalable to the whole Internet
Support fuzzy searching
Local Management
Decentralized authority
Support Access Control
(Possibly) Support multiple transport protocols
Support Descriptive Naming / Logical searches
Support Multiple interfaces
Cargille Expires May, 1995 [Page 3]
DRAFT White Page Requirements Dec 1994
Support multiple clients
Be Flexible (in data contained?)
Have low resource requirements
Be Inexpensive (product cost and staff time)
Ability to migrate in future
Ability to externalize existing local directory to Internet
(with minimum effort) -- or --
Ability to easily export local directory info to Internet
WPS (data conversion tools?)
Ability to automate Internet WPS queries
Consistency in responses to queries
Possibly - allow site to choose level of complexity they
choose to deploy
Complexity proportionate with site needs
Software freely available / public domain versions
(especially Unix)
Reliable infrastructure (root servers / centroid servers)
Clear mechanisms defined for new sites to join Internet WPS
Easy for new sites to join Internet WPS
Assistance available for new sites to join Internet WPS
Ability to limit information exposed outside an organization
Easy to build client software (user agents)
Replication (?)
Easy to install servers
Client-server protocol easy to debug / experiment with
Simple centralized organization registration procedures (if
used at all)
Data up to date
Ability to develop & deploy high performance servers for
upper layers of tree (if tree structure used) or centroids
Cargille Expires May, 1995 [Page 4]
DRAFT White Page Requirements Dec 1994
Protocol simplicity -- one developer can implement a server
on the order of one week's time.
Efficient implementations -- disk based storage, reasonable
disk and memory requirements for servers
Adds value if run strictly as local service
Local service easy to integrate into global service
(?) Replication of data -- at what level?
Ability for local sites to decide what protocol or
technology they choose to deploy or externalize
Access controls over data
If update is supported, then authentication must be
supported
Contains mechanism to prevent trawling of data
Supports data protection needs of various countries
Consistent naming conventions
Naming conventions that support searching based on
information that users are likely to know and search on
Cookbooks for administrators
Complete User guides available
Ability to limit number of servers contacted in a search
Ability to specify info in query to properly limit query
(CAC) Ability to return info which allows user to
intelligently limit query
Some scheme for fast searching, most likely by indexing
"Live" data used to populate Internet WPS, to avoid stale
data
Possibly - standard query language from DSA to current
databases
Standard protocol for directory queries
Standard query format
Standard field names
Cargille Expires May, 1995 [Page 5]
DRAFT White Page Requirements Dec 1994
Data maintained by local organization
Extensible/flexible but consistent naming scheme
Clear idea of naming authorities
High QOS from lowest common denominator (since that is what
the service will be judged as)
Security ?
Easy navigation
Ability to handle multi-media information?
Protocol support for maintenance of data
Ability to change protocol rapidly to correct deficiencies
Reasonably painless upgrade path for organizations
Widely deployed clients
Stable APIs (for implementations)
Shallow learning curve for novice users (client and server
administrator)
Easy mechanism for maintaining data
Supportable infrastructure
Ability to handle rapidly changing data ?
5. Author's Information
C. Allan Cargille
Senior Engineer
MCI Telecommunications
2424 Garden of the Gods Road
Colorado Springs, CO 80919 USA
Internet: ACargille@mcimail.com
X.400: TBA
Voice: +1 (719) 535-1736
Fax: TBA
Cargille Expires May, 1995 [Page 6]
DRAFT White Page Requirements Dec 1994
6. References
[1] RFC1588
[2,3,4]
X.500 reference, RFCs
[5] Whois++ reference
Cargille Expires May, 1995 [Page 7]
