Internet DRAFT - draft-ietf-whip-iwps-design-spec
draft-ietf-whip-iwps-design-spec
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:08:16 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 06 Jul 1995 22:00:00 GMT
ETag: "323e61-9829-2ffc5ce0"
Accept-Ranges: bytes
Content-Length: 38953
Connection: close
Content-Type: text/plain
Integrated Directory Services Working Group T. Genovese
draft-ietf-ids-iwps-design-spec-01.txt Microsoft
Expires: 7 January 1996 7 July 1995
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 Integrated Directoy Services (IDS) Working Group proposes to
establish a specification 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 general problem set. The Internet always
benefits from this type of implementation diversity and the most
Genovese [Page 1]
Internet Draft Specification for Internet White Pages 7 July 1995
likely future 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 to which 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. Developers
of this service 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.
Genovese [Page 2]
Internet Draft Specification for Internet White Pages 7 July 1995
To insure a consistent user view of the service, the User Agent (UA)
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
Genovese [Page 3]
Internet Draft Specification for Internet White Pages 7 July 1995
IWPS is depicted in Figure 1.
+-------------+
+--------+ +---------+ +----------+ IWPS Server |
| |----------->| WPN |-------->| Search | wps.domain |
| IWPS | +---------+ +----------+-------------+
| Client | +---------+ /
| |<-----------| WPI |<----------+
+--------+ +---------+
A White Pages Name is submitted and a White Pages
Identifier is returned.
+--------+ +---------+ +---------+
| |----------->| WPI |-------->| Fetch |
| IWPS | +---------+ +---------+
| Client | +---------+ /
| |<-----------| WPRR |<----------+
+--------+ +---------+
A White Pages Identifier is resolved to its White Pages Resource
Record (WPRR). The WPRR lists the IWPS server(s) that
manage the IWPS Record.
+------------+
+--------+ +---------+ +---------+ Directory |
| |----------->| URL |-------->| Fetch | Service |
| IWPS | +---------+ +---------+------------+
| Client | +-------------+ /
| |<-----------| IWPS Record |<------+
+--------+ +-------------+
A URL from the WPRR 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. What input the UA expects from the user, or how the UA
Genovese [Page 4]
Internet Draft Specification for Internet White Pages 7 July 1995
presents the results to the user is outside the scope of this
document. There are two basic operational requests defined for IWPS
complaint UAs.
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
Genovese [Page 5]
Internet Draft Specification for Internet White Pages 7 July 1995
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.
4.0 Naming
Choosing the name associated with the IWPS is complicated by opposing
naming requirements. One requirement is 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
in the United States). We also, require a IWPS name that would
uniquely identify a person or information object throughout the
entire network. 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 cannot meet
both goals with the same name. Therefore, two naming structures are
needed. The following conceptual names be used:
White Pages ID (WPI) Maps one name to one and only
one IWPS entry.
White Pages Name (WPN) Maps one name to one or more
IWPS entries.
4.1 White Pages Identifier - WPI
The WPI is designed to directly locate a particular person or
information object in the network. 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 precisely locate the information object within the
network. In particular it is important that the WPI have the
following qualities:
1. Global uniqueness
2. Persistence
3. Independence
4. Human transcribability
For illustration purposes it will be assumed that the WPI will have
the following form:
<Nameing Authority:Service provider:Local naming information>
Genovese [Page 6]
Internet Draft Specification for Internet White Pages 7 July 1995
i.e. <IANA:wp.nersc.gov:u7224>
In the above example IANA is the Nameing Authority for the service
provider wp.nersc.gov that manages the information object u7224. It
is recommended that the DNS be used to specify IWPS service
providers. The specification of the 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 WPI's will help to facilitate this changing
environment. This will be accomplished by mapping a WPI to a White
Pages Resource Record (WPRR). A WPRR consists of a version number
and a series of URLs that resolve to IWPS service. The process of
resolving a WPI to a particular user consist of the following steps:
1. The UA extacts from WPI the DNS registered Service
provider.
2. DNS is queried for a WPRR.
3. The UA extracts a URL and uses the Local naming
information to query the Service provider.
A Service Provider will use a WPRR to list the various IWPS sytems
they use. For example a WPRR could consist of the following
WPRR:
1. Version
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 WPRR. This process will require a
new RR for DNS.
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 WPRR. It is left to the UA implementation (which
may require 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
persistent 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. Though human transcribability is an
Genovese [Page 7]
Internet Draft Specification for Internet White Pages 7 July 1995
important consideration, 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 a person or other information
object in the network. 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 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.
Genovese [Page 8]
Internet Draft Specification for Internet White Pages 7 July 1995
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. This area is a separate Research topic and will be covered
in its own 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.
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
Genovese [Page 9]
Internet Draft Specification for Internet White Pages 7 July 1995
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 handled.
This area of research is under development in the IETF Application
Area.
6.0 Security
The IWPS must deal with two general security issues:
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
Genovese [Page 10]
Internet Draft Specification for Internet White Pages 7 July 1995
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.
7.0 Security Certificates
Another feature that IWPS can provide us is the ability to store
Security Certificates. This capability 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
Genovese [Page 11]
Internet Draft Specification for Internet White Pages 7 July 1995
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 with which it is
associated:
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 have
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.
Genovese [Page 12]
Internet Draft Specification for Internet White Pages 7 July 1995
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 cannot control:
1. Remote server response or availability
2. Network speeds or partitions
11.0 References
[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.
[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.
[WR92] Weider, C., Reynolds, J., "Executive Introduction to
Directory Services Using the X.500 Protocol", RFC 1308, ANS, March
1992.
12.0 Authors Address
Tony Genovese
The Microsoft Corporation
One Microsoft way
Redmond, Washington 98007
USA
Phone: (206) 703-0852
Genovese [Page 13]
Internet Draft Specification for Internet White Pages 7 July 1995
EMail: TonyG@Microsoft.com
Genovese [Page 14]
Internet Draft Specification for Internet White Pages 7 July 1995
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 Security Certificates --
certificates ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX
Keys{iwpsAttributeType 3}
Genovese [Page 15]
Internet Draft Specification for Internet White Pages 7 July 1995
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 Unstructured 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 16]
Internet Draft Specification for Internet White Pages 7 July 1995
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 17]
Internet Draft Specification for Internet White Pages 7 July 1995
Appendix B Technical Contributors
The following people contributed to the technical issues and discussions of
this document:
Allen, Jeff R. Jeff_Allen@hmc.edu
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
Genovese [Page 18]
Internet Draft Specification for Internet White Pages 7 July 1995
Waugh, Andrew ajw@mel.dit.csiro.au
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 19]
Internet Draft Specification for Internet White Pages 7 July 1995
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 Encryption 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 20]
Internet Draft Specification for Internet White Pages 7 July 1995
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.
URL:
Uniform Resource Locator.
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 User 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: 23 September 1995
Genovese [Page 21]
