Internet DRAFT - draft-ietf-whip-iwps-requirements
draft-ietf-whip-iwps-requirements
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:08:20 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 17 Nov 1994 23:00:00 GMT
ETag: "323e63-96a5-2ecbe070"
Accept-Ranges: bytes
Content-Length: 38565
Connection: close
Content-Type: text/plain
White Pages Requirements Working Group T. Genovese
draft-ietf-whip-iwps-requirements-01.txt ESnet
Expires: 16 May 1995 16 November 1994
A Specification for the Simple Internet White Pages Service
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), it 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Overview
The IETF Internet White Pages Requirements (Whip) Working Group
proposes to establish a set of requirements for a simple Internet
white pages service without prejudice to existing recommendations or
implementations. This Document is designed to be used by other WGs in
the IETF to guide the overall structure of the Internet White Pages
Service (IWPS).
1.0 Introduction
The Internet community has done a significant amount of work in the
analysis of Internet White Pages Services and several documents
address the issue of IWPS requirements [KS89, PA94]. The work on
this document has benefited from the review of this work and several
implementations. Each implementation was developed to explore a
solution set of requirements. A number of them are based on an
underlying technology like X.500 [KH93]. Others have defined new or
built on old systems [PD94]. With each approach we acquired a new
understanding of the eneral problem set. The Internet always benefits
from this type of implementation diversity and the most likely future
Genovese [Page 1]
Internet Draft Internet White Pages Requirements 16 November 1994
for the IWPS is that it will consist of a number of directory like
services that will interwork to provide the general IWPS.
The purpose of this document is to define a single set of functional
requirements for the Internet White Pages Service that accommodates
the wide variety of information retrieval protocols that may be used
to create a directory service, based upon the work done to date. It
is not the purpose of this document to propose restrictions for the
development of the independent implementations of the IWPS. Yet, as
these systems are built and deployed new issues of interoperability
and data reliability come to play. Therefore a common set of
information objects and procedures is proposed to minimize these
problems.
This Document will focus only on common information and operational
modeling issues that all IWPS provider must conform to. To insure a
consistent User view of this service we need to define a common
naming structure. This will allow a User to go between different
implementations of the service and have a consistent way of looking
for people or other Information objects in the Internet. For
developers of this service we need to have an unambiguous method of
representing the Information objects managed by the service. This
will help facilitate interoperability and data management.
As any group of people begin to work on an issue a set of words or
terms start to take on meaning only to the group. This helps them to
communicate common ideas. Depending where you are when you join the
effort the terms may be confusing or even new. To facilitate our need
to communicate common ideas, Appendix C attempts to document certain
words and terms used in this document. It also, will expand all
acronyms used in this document. It may be useful for the reader to
glance through this appendix before reading this document.
2.0 Scope
This document will describe a conceptual model for the IWPS and deal
with naming, schema, query and response issues for a narrowly defined
subset of directory services. This document attempts to establish a
simple set of information objects that should prove extensible and
usable by developers of the IWPS. These information objects, coupled
with a basic set of process requirements, will form a basis from
which related IETF efforts can build an ubiquitous IWPS. It will only
deal with issues that are common to this service. It will not
attempt to be an exhaustive specification of wide scale directory
services.
To insure a consistent user view of the service, the User Agent (UA)
Genovese [Page 2]
Internet Draft Internet White Pages Requirements 16 November 1994
will need to be addressed. This will not be a specification of a UA
but, will deal with those issues of information content as presented
to or by the user. This Document will also describe a basic set of
operations that will need to be supported by the UA.
3.0 Conceptual Model
The Internet White Page Service will utilize the current information
servers and not restrict the development of new information servers.
It will also, strive to provide a consistent User view of the
service. To achieve these potentially tangential requirements it
will be necessary to develop a model that can guide the current use
and future development.
At first glance it would seem that the definition of a simple,
unified, client/server model would meet our needs. However, a simple
model can not be achieved because, the different information servers
that constitute the the IWPS will not, at least initially, use common
designs or protocols. The servers of the IWPS do not provide a
consistent delineation of function between the client and the server
or a common method of query and response. One way to accommodate the
existing, diverse client/server architectures, while creating a
ubiquitous IWPS is to define a conceptual client/server model and the
functions that must be performed within this model.
This document will concentrate on how and what these servers must do
as a minimum to participate in the IWPS with a limited set of data
that will constitute the IWPS data model. We need to augment this
data model with the type of operations that must be supported by the
IWPS clients and servers. Throughout this document we refer to the
IWPS UA as the software that the User uses to access the IWPS. This
UA can be seen as a client of the IWPS servers. Therefore, you can
use the term client or UA interchangeably when discussing IWPS.
The requirement for a consistent naming architecture for the IWPS
presents a complex problem. This issue is described in detail later
in this document. To aid in the understanding of the conceptual model
we should point out that there are two name forms used in the IWPS.
The following conceptual names will be used:
White Pages Name (WPN) Maps one name to one or more
IWPS entries.
White Pages ID (WPI) Maps one name to one and only one
IWPS entry.
The basic model for interaction between the Client and Server of the
IWPS is depicted in Figure 1.
Genovese [Page 3]
Internet Draft Internet White Pages Requirements 16 November 1994
+-------------+
+--------+ +---------+ +----------+ IWPS Server |
| |----------->| WPN |-------->| Search | wps.domain |
| IWPS | +---------+ +----------+-------------+
| Client | +---------+ /
| |<-----------| WPI/URN |<----------+
+--------+ +---------+
A White Pages Name is submitted and a White Pages
Identifier is returned.
+--------+ +---------+ +---------+
| |----------->| WPI/URN |-------->| Fetch |
| IWPS | +---------+ +---------+
| Client | +---------+ /
| |<-----------| URC |<----------+
+--------+ +---------+
A White Pages Identifier is resolved to its Uniform Resource
Characteristic (URC). The URC list the IWPS server(s) that
manage the IWPS Record.
+------------+
+--------+ +---------+ +---------+ Directory |
| |----------->| URL |-------->| Fetch | Service |
| IWPS | +---------+ +---------+------------+
| Client | +-------------+ /
| |<-----------| IWPS Record |<------+
+--------+ +-------------+
A URL from the URC is selected and resolved to the IWPS
Record.
Figure 1 Internet White Pages Model
There are no restrictions on the general design or operations of IWPS
UAs. Any UA that is going to participate in the IWPS must be capable
of passing required operational requests to the various information
servers. These request must conform to the specific server
requirements. How the user has to present the information for the
requests to the UA or how the UA present the results to the user is
outside the scope of this document. There are two basic operational
requests defined for IWPS complaint UAs.
Genovese [Page 4]
Internet Draft Internet White Pages Requirements 16 November 1994
1. Search
2. Fetch (get, read, retrieval)
The UA would use a WPN as the set of input parameters for the Search
operation. The UA would use a WPI as the input parameter for the
Fetch operation. Some UAs may wish to support addition modifiers to
these operations. On a Fetch the User may be allowed to request that
only certain attributes be returned. This would imply that the server
supports this modifier or the UA would have to support it.
There are two forms of response expected from the server for each of
the above requested operations.
1. Positive - data or results
2. Negative - errors or suggestions
With the Search operation a positive response would imply that a WPI
was returned to the UA. A positive response to a fetch operation
would be the actual information object. Some negative responses to a
fetch or search operation will be:
Fetch:
1. Access denied.
2. Server specific Errors - administrative limit notices.
3. Referral to one or more servers.
Search:
1. Access denied.
2. Server specific Errors - administrative limit notices.
3. Partial match notification.
4. Suggestions for possible WPNs to try.
With respect to the search operation, effective server responses of
the type 3 and 4 form above would help facilitate IWPS navigation.
There are two basic modes of operation that describe the way the UA
will be used to access the servers.
1. Connection oriented - Interactively
2. Connectionless - Command/Response
Long lived connections would help serve Users that are doing
interactive types of searches or requesting multiple Information
objects. Connectionless mode of use would serve single queries
similar to those performed within the domain name system. Support of
both modes of UA to server interactions is expected by IWPS Users.
Genovese [Page 5]
Internet Draft Internet White Pages Requirements 16 November 1994
4.0 Naming
The name associated with the IWPS is complicated by opposing naming
requirements. One requirement was to allow a user, with incomplete
naming information to be able to navigate the IWPS until the person
or information object is found. This name form would map one name to
one or more information objects (i.e. All Smiths at LLNL, US). We
also, require a name that would uniquely identify a person or
information object. This name form would map one name to one and
only one information object.
It would be ideal if the name we used to navigate through the IWPS
could be derived from the unique identifying name but, we can not
meet both goals with the same name. Therefore, two naming structures
are needed. It is recommended that the following conceptual names be
used:
White Pages Name (WPN) Maps one name to one or more
IWPS entries.
White Pages ID (WPI) Maps one name to one and only
one IWPS entry.
4.1 White Pages Identifier - WPI
The WPI is designed to directly locate a particular person or
information object in the Internet. A WPI provides a one to one
mapping between a name and an IWPS information object. When a User
presents a WPI to a User Agent the service will be able, after name
resolution, to locate the information object precisely. It is
recommended that the WPI be represented as a URN [SM94]. In
particular it is important that the WPI have the following qualities:
1. Global uniqueness
2. Persistence
3. Independence
4. Human transcribability
These and other qualities are characteristics of a URN.
For illustration purposes it will be assumed that the WPI URN will
have the following form:
<URN:IANA/wp.nersc.gov:u7224>
Where wp.nersc.gov is the DNS registered service provider that
manages the information object u7224. It is recommended that the DNS
be used to specify IWPS service providers. The specification of the
Genovese [Page 6]
Internet Draft Internet White Pages Requirements 16 November 1994
WPI attribute is in Appendix A.
The IWPS, for any particular organization, will consist of a number
of different information servers. These multiple servers may use
different access protocols. The set of servers may also change over
time. The use of URN will help to facilitate this changing
environment. This will be accomplished by using the URN to URC
mapping features [M94]. After a URN is resolved to its URC the
attributes of the URC would be used by the IWPS UA to access a
particular server. e.g.
URN -> URC:
1. Version, etc. info
2. URL: finger://nersc.gov
3. URL: whois: //nersc.gov
4. URL: solo: //es.net
This leaves administrative control of servers accessed by the IWPS
UAs with the local manager of the URC.
It is possible that a person or information object may be registered
with multiple servers. This could lead to having multiple WPIs for
each information object. It is recommended that the information
object have only one WPI and the multiple servers should be listed as
URLs in the WPI's URC. It is left to the UA implementation, with
possible User interaction, to select which URL to resolve.
The WPI is designed to be Human Transcribable so, Users could
exchange them via Email or on business cards. Because of the
persistence nature of a WPI it could be used to get the latest
information about a User even though the information in an Email or
on a business card has expired. It is more likely that WPIs will be
used more in UA to Server or Server to Server requests.
4.2 White Pages Name - WPN
A WPN consists of the attributes from an information object
Template. The Ancillary Information Attribute, described later, is
not part of the WPN. Depending on the number of attributes
enumerated in a IWPS query, it will provide a one to many mapping
between a name and an IWPS information object. In general the WPN
will be used by people with incomplete naming information to
construct a Purported Name that can be submitted to the IWPS to
locate an Internet person or information object. This Purported Name
would be used as a guess when querying the IWPS. This process of
discovery will be iterative in nature. It is envisioned that the most
common use of a WPN would be to do searches of the IWPS space to
Genovese [Page 7]
Internet Draft Internet White Pages Requirements 16 November 1994
locate individuals.
To insure a consistent view of what an Internet person WPN will
contain, the information object Template Internet White Page Person
is specified in Appendix A. It contains the minimum required set of
attributes for representing a person in the IWPS. Similar information
object Templates can be defined for organizations, documents,
services, etc. This document deals only with the Internet person WPN.
Because the Internet person WPN consists of a number of attributes it
is possible that you can construct a number of Purported Names for
the same person. e.g.
Huitema, Inria, Fr
Christian Huitema, Inria, Fr
Huitema, Rodeo, Inria, Fr
Huitema, Sophia, Inria, Fr
The actual order the attributes of the WPN are presented by the user
to the IWPS UA or used by the UA to generate a query is left to the
implementation. The User must realize that the more complete the WPN
is the better the chance is that useful information can be returned.
i.e. a query for just "Huitema, Fr" will most likely fail.
5.0 IWPS Schema Considerations
The information description requirements for the IWPS consists of the
following:
1. Syntax for definition/representation of Information
Object Templates.
2. Registration procedures for information object
Templates, etc.
3. Database structure or schema.
Items 1 and 2 will be covered in this Document. Database structure
because, it will potentially restrict implementations (i.e. X.500
schema based Vs DNS schema based) will not be defined in this
document.
5.1 Syntax for definition/representation of Information objects
A clear, precise and consistent method must be used when information
object Templates and their attributes are discussed within the
context of IWPS. There are two possible methods to do this. i.e.
Genovese [Page 8]
Internet Draft Internet White Pages Requirements 16 November 1994
1. BNF
2. ASN.1
The Working Group recommends the use of ASN.1. It provides us with a
set of predefined attributes and encoding syntaxs. Also, it is well
documented and widely available.
The use of ASN.1 to specify the structure of the information objects
does not imply the use of Basic Encoding Rules (BER) for any IWPS
servers protocols. The use of Object inheritance is not used or
specified by this document.
5.2 Registration of IWPS Information object Templates.
The Working Group recommends the registration and publication of all
information object Templates used for the IWPS. We will use the IANA
branch of the ISO OID tree for registration of the IWPS Object
Templates. This branch was used by the Object Templates listed in
Appendix A. To facilitate distribution of IWPS information object
Templates they should be made available on the Internet information
server (i.e. InterNIC). At a minimum it is recommended that any new
information object Template that will be made available via the IWPS
will be published in a RFC and its OID registered with IANA.
Individual organizations may define information object Templates that
are only local in scope. This may be needed to meet local
organizational needs. If these information object Templates are not
registered with the IWPS, they may not be processable by the general
IWPS UAs. All information that the organization wishes to be part of
the IWPS must use an IWPS registered information object Template.
5.3 Database Structure
It is envisioned that the IWPS will consist of a number of
independent information servers. Each of these servers will
construct their own Databases. Therefore, no Internet wide directory
Database will be provided. This by its nature will cause
interoperability and synchronization problems that must be worked
out. This area of research is under development in the IETF
Application Area.
6.0 Security
The IWPS must deal with two general security issues:
Genovese [Page 9]
Internet Draft Internet White Pages Requirements 16 November 1994
1. Privacy laws/rules
2. Access Control/Authentication
The Global nature of the Internet creates a complex interplay of
Country and Organizational laws/rules. It would best serve the IWPS
if all information was readily available to all people in the
Internet but, this comes up against the security/privacy needs of
Organizations and/or people. Security is further complicated by the
potential diverse nature of the IWPS server environment. Each server
could have different forms of Access/Authentication controls in place
to meet their needs.
6.1 Privacy
The question of User's Privacy requirements for North America has
been addressed by NADF [NADF92]. The NADF document does not take
into account the Global Internet set of Users. This topic is an area
of research in the IETF Applications Area. It will not be dealt with
in this document.
6.2 Access Control/Authentication
With the IWPS environment consisting of multiple server types and
different autonomous management domains the question of Access
control is at best problematic. It is also clear that a model to
approach this problem is needed if the IWPS is to be deployed.
To meet the current needs of this community it is recommended that
the general issues of Access Control/Authentication be broken down
into the following two models:
1. Anonymous or Public Access
2. Administrative Access
The issue of Administrative Access Control is a current research area
of the IETF Application Area. This topic deals in general with the
issues associated with the ability to add or modify entries in the
IWPS. This document will only address the Anonymous or Public Access
issues of the IWPS.
The IWPS is to be considered a public access service only. If an
organization is participating in this service, they must provide at a
minimum anonymous access to their service. It may be the result of a
query posted to one of these servers that a response is returned that
the requested information is not available to the requester. This
negative response is a minimum requirement for all IWPS servers.
Genovese [Page 10]
Internet Draft Internet White Pages Requirements 16 November 1994
7.0 Security Certificates
Another feature that IWPS can provide us is the ability to store
Security Certificates. It is needed by secure mail services such as
PEM and PGP. To facilitate the storage and management of these
Certificates a new element is defined for the iwpPerson object. This
new element will allow multiple Certificates to be stored with the
person record. It also allows for the deprecation of certificates
through the use of a validity field. This field is use to state the
beginning and end dates the certificate is valid. The element
"certificates" is defined in Appendix A.
8.0 Data Integrity
The question of Data Integrity was first addressed in RFC1107 [KS89].
It basically states, that if the information is out of date it is
useless and the service will not be used. Therefore, a clear
requirement is that any production IWPS provider must insure that all
data is reasonably correct and current.
To facilitate the User in determining the quality of the data that
has been retrieved it is recommended that the optional Ancillary
information attribute of the IWPperson Template be supported. This
would require the IWPS UA to be able to retrieve and display this
information. This may be done as a separate operation from the fetch
of the information object. The Ancillary Information Attribute is
defined in Appendix A. It is further recommended that any new
information object Template include as a minimum the Ancillary
information attribute as an optional attribute. It would then be
left to the IWPS servers to optionally support the storage and
retrieval of this data.
The Ancillary Information attribute has been designed to provide the
following information about the information object it is part of:
1. The date and time of the last modification.
2. Who performed the last modification.
3. Who owns or is responsible for the data stored
in the information object.
4. What is the official source of the data.
5. Which attributes in the information object has
Genovese [Page 11]
Internet Draft Internet White Pages Requirements 16 November 1994
been changed.
As new information object Templates are defined for the IWPS a new
changeRecord type will need to be defined for it and assigned to the
changeRecord attribute.
This attribute is not a part of the WPN. It is not to be used as
part of the Purported Name presented to the IWPS UA.
9.0 Unstructured Data
There are a number of existing directory based systems that are
currently providing White Pages style of information. These systems
respond to queries by returning information without regard to any
structure of the data. There is nothing in their protocol
specifications that identify individual fields or attributes in the
response that would allow it to be machine processable.
To accommodate these systems and the way they return information, the
element unstructureData has been added to the iwpPerson object. This
element consists of a 1k block of data without any structure or
content requirements. It can be used to represent/store any of the
current sets of White Pages information.
It should be noted that this element is added for backward
compatibility of the existing systems only. It should not be used
for the development of any new white page service.
10.0 Performance
If the IWPS is to be useful to its User community it must provide for
reasonable performance. To set a performance requirement is
unnecessary. Simply because, if the service does not meet the
performance needs demanded by its Users it will not survive.
The performance of the distributed IWPS will be affected by many
things potentially outside the control of the local provider. The
local provider can not control:
1. Remote server response or availability
2. Network speeds or partitions
11.0 References
Genovese [Page 12]
Internet Draft Internet White Pages Requirements 16 November 1994
[KH93] Hardcastle-Kille, S.; Huizer, E.; Cerf, V.; Hobby, R.; Kent,
S.; "A Strategic Plan for Deploying an Internet X.500 Directory
Service", RFC 1430, ISODE-Consortium, February 1993.
[KS89] Sollins, K., "A Plan for Internet Directory Services", RFC
1107, Laboratory for Computer Science, MIT, July 1989.
[M94] Mitra, "URN to URC resolution scenario", Internet Draft:
draft-ietf-uri-urn2urc-00.txt
[MM94] Mealling, M. "Encoding and Use of Uniform Resource
Characteristics", Internet Draft: draft-ietf-uri-urc-spec-00.txt
[NADF92] North American Directory Forum, "User Bill of Rights for
entries and listings in the Public Directory', RFC 1295,
North American Directory Forum, January 1992.
[PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC
1588, University of Southern California, February 1994.
[PD94] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C.,
Architecture of the Whois++ Service, Internet Draft: draft-ietf-
wnils-arch-01.txt, April 6, 1994.
[SM94] Sollins, K., Masinter, L., "Requirements for Uniform Resource
Names", Internet Draft: draft-sollins-urn-01.txt
[WR92] Weider, C., Reynolds, J., "Executive Introduction to
Directory Services Using the X.500 Protocol", RFC 1308, ANS, March
1992.
12.0 Author's Address
Tony Genovese
Energy Science Network
National Supercomputing Center
Lawrence Livermore National Laboratory
7000 First Street
Livermore, California 94551
USA
Phone: (510) 423-2471
EMail: Genovese@ES.net
Genovese [Page 13]
Internet Draft Internet White Pages Requirements 16 November 1994
Appendix A Information Object Template Definitions
The Information Objects Template and attributes defined in this appendix are
used to define the contents of Information Objects of the IWPS.
In particular the the Template defined below deals with the
person Object. Any new Information Object must be registered with IANA.
-- The Information Object Template for the IWPS person --
iwpPerson OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN{
commonName,
wpi}
MAY CONTAIN{
surname,
organizationalName,
postalAddress,
telephoneNumber,
emailAddress,
certificates,
unstructuredData,
ancillaryInformation}
::={iwpsObjectTemplate.1}
-- The WPI attribute to be use by Information Objects of the IWPS --
wpi ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreStringSyntax
((SIZE(1..ub-iwps-wpi))
::={iwpsAttributeType 2}
-- The element for the storage of Email information --
emailAddress ATTRIBUTE
WITH ATTRIBUTE-SYNTAX EmailAddress
::={iwpsAttributeType 1}
EmailAddress ::= SEQUENCE (SIZE(1..ub-email-boxes)) OF
caseIgnoreString(SIZE(1..ub-email-addr))
-- The element to be used to store Securiy Certificates --
certificates ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX
Keys{iwpsAttributeType 3}
Genovese [Page 14]
Internet Draft Internet White Pages Requirements 16 November 1994
Keys ::= SEQUENCE (SIZE(1..ub-keys)) OF keyInfo
keyInfo ::= SEQUENCE{
validity Valid,
key KeyType}
Validity ::= SEQUENCE{
notBefore UTCTime,
notAfter UTCTime}
KeyType ::= SEQUENCE{
algorithm OBJECT IDENTIFIER,
subjectKey caseIgnoreStringSyntax(SIZE(1..ub-keysize))}
-- The Unstructure Data element used to contain free form data --
unstructuredData ::= caseIgnoreStringSyntax(SIZE(1..ub-data))
-- The Ancillary Information attribute used for data integrity --
ancillaryInformation ::=
SEQUENCE{
LastModifiedDate
UTCTime,
LastModifiedBy,
commanName,
OwnerofData,
commonName,
OfficialSourceofData
dataBase,
WhatWasChanged
changeRecord}
dataBase ::= caseIgnoreStringSyntax(SIZE(1..ub-database))
-- Change record subtypes are the MUST CONTAIN attributes --
changeRecord ::= iwpsPersonType (commonName | wpi)
iwpsPersonType ::=
BIT STRING {
commonName (0),
surname (1),
organizationalName (2),
postalAddress (3),
telephoneNumber (4),
Genovese [Page 15]
Internet Draft Internet White Pages Requirements 16 November 1994
emailAddress (5),
wpi (6)
}
-- Size limits used by the IWPS --
ub-database INTEGER ::= 1024
ub-data INTEGER ::= 1024
ub-email-boxes INTEGER ::= 8
ub-email-addr INTEGER ::= 1024
ub-keys INTEGER ::= 6
ub-keysize INTEGER ::= 512
ub-iwps-wpi INTEGER ::= 256
-- Object Identifiers use by the IWPS --
Internet OBJECT IDENTIFIER ::= {ISO(1) org(3) DOD(6) 1}
iwps OBJECT IDENTIFIER ::= {Internet NN}
iwpsAttributeType OBJECT IDENTIFIER ::= {iwps 1}
iwpsObjectTemplate OBJECT IDENTIFIER ::= {iwps 2}
Genovese [Page 16]
Internet Draft Internet White Pages Requirements 16 November 1994
Appendix B Technical Contributors
The following people contributed to the technical issues and discussions of
this document:
Gargano, Joan jcgargano@ucdavis.edu
University of California
Computing Services
Davis, CA 95616
(916) 752-2591
Hamilton, Martin martin@mrrl.lut.ac.uk
Department of Computer Studies
University of Technology
Loughborough, Leicestershire LE11 3TU, UK.
Hedberg, Roland rhg@UMDC.UMU.SE
Umea University
Umea
SE
+46 90-165204
Howes, Tim tim@terminator.rs.itd.umich.edu
ITD Research Systems
4214 Argus Building
535 West William Street
Ann Arbor, MI 48103-4943
+1 313 747 4454 (voice)
+1 313 764 5140 (fax)
Huitema, Christian Christian.Huitema@inria.fr
Jurg, Peter Peter.Jurg@SURFnet.nl
Langlois, Sylvain Sylvain.Langlois@der.edf.fr
Lenggenhager, Thomas Lenggenhager@SWITCH.CH
SWITCH Teleinformatics Services
Limmatquai 138
CH-8001 Zurich
CH
+41 1 261 8178
Pays, Paul-Andre pays@faugeres.inria.fr
Spero, Simon ses@tipper.oit.unc.edu
Waugh, Andrew ajw@mel.dit.csiro.au
Genovese [Page 17]
Internet Draft Internet White Pages Requirements 16 November 1994
Woermann, Ascan Woermann@osi.e3x.fr
Wright, Russ Wright@LBL.Gov
Lawrence Berkeley Laboratory
1 Cyclotron Road
Mail-Stop 50B-2258
Berkeley, California, USA 94720
+1 510 486-6965
Genovese [Page 18]
Internet Draft Internet White Pages Requirements 16 November 1994
Appendix C Glossary
Attribute:
Typed information that constitutes a part of an
Information Object that is stored in the IWPS.
DNS:
Domain Name System.
Entry:
An Information Object.
IETF:
Internet Engineering Task Force
Information Object:
An instance of an Information Object Template.
Information Object Template:
An abstract way of representing people, machines
Servers, etc., as data that can be stored in a
IWPS server.
IWPS:
The Internet White pages Service.
NADF:
North American Directory Forum
PEM
Privacy Enhanced Mail
PGP
Pretty Good(tm) Privacy: Public Key Encrytion for the Masses
Purported name:
A naming construct which is syntactically a name, but
which has not been shown to be an actual entry in the
IWPS.
Genovese [Page 19]
Internet Draft Internet White Pages Requirements 16 November 1994
Schema:
The structure applied to the data that represents Objects
in the Internet. This will consist of a set of rules
and constraints that define Information Objects and
Information Object Templates.
URC:
Uniform Resource Characteristics.
URL:
Uniform Resource Locator.
URN:
Uniform Resource Names.
User:
The end user of the IWPS. i.e. The person that accesses the
IWPS.
User Agent:
The software Application that is used by a person to
access the IWPS.
WPI:
White Pages Identifier. A naming construct that
identifies one and only one entry in the IWPS.
WPN:
White Pages Name. A naming construct that may identify
one or more entries in the IWPS. The WPN would be used
to construct Purported Names for submission to the IWPS
UAs for directory searches.
Expires: 16 May 1995
Genovese [Page 20]
