n2dsy@hou2d.ATT.COM (J. Gordon Beattie, Jr.) (03/22/89)
FORWARDED FROM AMATEUR RADIO:
Date: 22 Mar 89 04:09:30 GMT (Wed)
From: n2dsy@n2dsy.nj.usa.hamradio.org.iso (Gordon Beattie)
Reply-To: n2dsy@kd6th.nj.usa.hamradio.org.iso
Message-ID: <446@n2dsy.nj.usa.hamradio.org.iso>
To: all
Subject: Directory Service Description Draft 1
I have enclosed Draft 1 of a Directory Service Outline for
your comments. for now I am sending this to the following
individuals: ka2bqe kd6th w0rli wa7mbl k3rli wd6cmu n6vv kb7uv
wa1lou wb2mnf w2vy ve3gyq w4ri, w2jup, kb1bd ka2usu and n2ids.
Feel free to circulate this as you see fit. If you would like
others added to the list please let me know. I will be posting
this to the packet BBSs, netnews rec.ham-radio.packet and CI$.
After getting comments I will be adding fields, formats and
validation criteria to the fields. Thanks for your interest.
Gordon Beattie, N2DSY
201-387-8896(H)
201-615-4168(O)
...!att!hou2d!n2dsy
--------------------
Directory Service Outline - DRAFT 1
J. Gordon Beattie, Jr., N2DSY
The Radio Amateur Telecommunications Society
For the last several years packet system software developers and
users in the Amateur Radio Service have been experimenting with
simple directory servers. These usually provide callbook and/or
"home BBS" data through local transactions or a remote mail
interface. These systems include WD6CMU's WP, the W0RLI server
and the WA4ONG Callbook servers.
The user base has expanded and with it the interests and
associated information needs. many activities would be
supported if a directory server contained information on network
addresses, frequencies, e-mail addresses in forms other than
what is currently used by packet BBSs and possibly even
organizational data. Organizational data might allow mail to be
directed to "ARRL Hudson Division Director" or "ARRL Northern
New Jersey Section Manager".
The objective of this discussion is to facilitate interoperation
between directory systems which support the advanced
capabilities required by this evolving environment.
In order to determine what specific steps need to be taken to
produce these systems, some basic questions need to be
addressed. The first deals with directory data elements. The
directory data elements may vary from system to system, but some
common specification is required including:
1. The format of individual data elements;
2. A minimal subset of data elements that must be selected and
supported on all systems;
3. The use of aliases for some data elements must be permitted
and defined;
4. Relationship(s) of the data elements must be defined;
5. A mechanism to control access to a data element and its value
is needed.
The second question deals with functional requirements of the
systems. Each item may be broken up into several items, and
then either fully or partially supported.
1. There are operations which may be used by users and/or
systems. These operations may be invoked with parameters
arranged as a filter. Filter constructs such as "equal to
xxx" or "greater/less than xxx" are provided. Several of
these constructs can be used to qualify an operation.
* Basic operations should include:
Read - one or more attributes of a particular entry
Compare - one or more attributes of a particular entry
List - of entries subordinate to the entry selected
Search - of the directory based on selected filter attributes
Abandon - a previously invoked request of the directory
* Advanced operations should include:
Add - an entry to the directory
Remove - an entry from the directory
Modify Entry - attributes and/or attribute values
Modify Name - of an entry in the directory
* Results of these operations can come in one of four ways:
Complete Results - in which case the request is fully
satisfied
Partial Results - in which case the request is satisfied
without an indication of possible further
action
Referred Results - in which case the request is satisfied
with an indication of possible further
action
Errors - in which case something was wrong with the semantics
of the request.
The operations may be concatenated together to produce a
specific request. An example would be a wildcard search
of all BBSs in New Jersey with an indication that the
resultant response include callsigns, network addresses
and a list of supported distribution lists. This would
use the "Search" and "Read" operations.
2. Proposed user sematics should be defined solely for the
purposes of understanding specific requests of the directory.
We should not try to impose a set of sematics on a particular
developer or user community.
3. Remote or local use for each of the functions should be
defined.
4. Automatic referral of requests to another system(s)
supporting data elements requested but not available on the
receiving system.
5. Some mechanism is needed for transport of remote requests -
any of the standard mail formats perhaps?
6. For remote use of advanced operations (at least) we will need
a method for authenticating the user and/or message.
Summary
Now let us get practical for a moment. First, the systems you
have may already do some of these functions. Second, the system
outlined above is complex to implement, and probably unrealistic
to expect in the short-term. I am asking that we work toward
building interoperable systems by doing a bit of up-front,
collective high-level design. This will provide developers with
a common "blueprint" for directory system implementation. From
this "blueprint" will be able to identify additional functions
and data elements.
Appendix A
These section outlines a proposed set of directory elements
which might be supported by a directory system. This directory
system would provide support for the following services:
1. Standard packet BBS mail routing (WP-type)
2. Domain-based mail routing for X.400 and Internet systems
3. Network routing for OSI systems based on the Network Service
Access Point Identifier (NSAP-ID).
4. Network routing for DoD Internet systems.
5. Net/Rom or other network node
6. Organizational Role Alias for ARRL Officials so that mail can
be directed to a Director, Section Manager, etc.
7. Organizational Role Alias for officials of other
organizations
8. Organizational entries to support referral of inquiries to
organizational directory databases
8. Postal Address lookup
There will be directory entries for people, organizations,
devices and applications. In order to get the crew thinking
about possible elements I have created a sample set of data
elements for a directory entry of a "Person" are outlined below:
ENTRY ::= Person
POSSIBLE SUPERIORS{
Top
Country
Organization
}
MUST CONTAIN{
Common Name (Amateur Callsign)
Begin Time DEFAULT (Time of Entry)
End Time DEFAULT NULL
}
MAY CONTAIN{
Amateur Radio Specific Attributes
CONTAINS{
Surname
Given Name
Nickname
Message Handling Attribute Set
CONTAINS{
Home PBBS
X.400 Address
Internet Address (SMTP)
}
OSI Domain
NSAP-ID
Internet Domain
Internet Address
Node Name
Organizational Role
CONTAINS{
Organization Name
Organizational Unit
Title
}
}
Locale Attribute Set
CONTAINS{
Street Address
Locality Name
State/Province Name
}
Postal Address Set
CONTAINS{
Physical Delivery Office Name
Postal Address
Post Office Box
Street Address
Postal Code
}
Telecommunications Address Set
CONTAINS{
Telephone Number
Facsimile Telephone Number
X.121 Address
}