Minutes of the Second
IETF Directory Services (OSI-DS) Working Group
December 3-4, 1990
Boulder, Colorado
Richard Colella Peter Whittaker Steve Kille
NIST BNR UCL
January 11, 1991
1
1 Attendees
S.K. Steve Kille UCL s.kille@cs.ucl.ac.uk
MTR Marshall Rose PSI mrose@psi.com
R.C. Ross Callon DEC callon@bigfut.enet.dec.com
P.M. Peter Mierswa DEC mierswa@smaug.enet.dec.com
D.O. David Oran DEC oran@oran.enet.dec.com
H.J. Harold Jones DEC hjones@nac.dec.com
L.C. Lida Carrier Apple lida@apple.com
M.M. Marilyn Martin UBC martin@netcom.ubc.ca
K.A. Karl Auerbach Sun karl@eng.sun.com
G.M. Greg Minshall Novell minshall@wc.novell.com
D.M. Dan Molinelli TRW moline@trw.com
P.Y. Peter Yee NASA yee@ames.arc.nasa.gov
P.K. Paul Koski H/P koski@hpindeg.cup.hp.com
R.W. Russ Wright LBL wright@lbl.gov
DPZ David Paul Zimmerman Rutgers dpz@dimncs.rutgers.edu
M.G. Martin Gross DCS gross@polaris.dca.hil
RCo Richard Colella NIST collela@osi3.ncsl.nist.gov
PVM Paul Mockapetris DARPA pvm@darpa.mil
J.H. Juha Heinanen FUNET jh@funet.fi
J.M. Jim Mostek Cray Research mostek@cray.com
T.S. Theresa Senn Cray Research tcs@cray.com
PWW Peter Whittaker BNR pww@bnr.ca
I.H. Ian Hamilton BNR ianh@bnr.ca
YBW You-Bong Weon-Youn ATT youbong@arch2.att.com
H.S. Harvey Shapiro Nardac shapiro@wnyase.nardac-dc.navy.mil
C.C. Curtis Cox Nardac ccox@wnyosi.nardac-dc.navy.mil
J.M. Judy Messing Mitre messing@gateway.mitre.com
G.G. Gita Gopal Bellcore gita@bellcore.com
SYW Sze-Ying Wuu Bellcore sywuu@thumper.bellcore.com
K.S. Karen Sollins MIT sollins@lcs.mit.edu
D.B. Dave Brent CDNNet brent@cdnnet.ca
JGL Jose Garcia Luna SRI garcia@sri.com
M.K. Mark Knopper Merit mak@merit.edu
D.W. Dan Wintringham -- danw@oar.net
T.E. Tom Easterday Ohio State tom@nisca.acc.ohio-state.edu
V.C. Vinton Cerf NRI vcerf@nri.reston.va.us
A.H. Alf Hansen UofWisconsin alf.hansen@pilot.cs.wisc.edu
K.F. Karen Frisa CMU karen.frisa@andrew.cmu.edu
L.W. Linda Winkler -- b32357@anlvm.ctd.anl.gov
2
2 Introduction
The meeting was opened by the Chair, Steve Kille (UCL).
Introductions were made and minute-takers were solicited. The
proposed agenda was approved and the meeting proceeded accordingly.
2.1 Minutes of Previous Meeting
The minutes of the San Jose meeting were approved with minor
changes.
2.2 Matters Arising
2.2.1 Document Distribution
A number of attendees had problems with document distribution.
These fell into four categories:
o ASCII documents were formatted for A4 size paper, which is
inconvenient for those in the U.S.
o the ASCII versions of the documents were somewhat idiosyncratic
in format -- Steve pointed out that the primary form of
documents he generates is PostScript and was not intending to
spend significant amounts of time reworking the ASCII versions,
o a number of people could not print the PostScript versions of
the papers retrieved from NRI -- Steve said that this problem
was easily correctable and would take care of it, and,
o a few people remarked about late distribution of documents and
a consequent lack of time to obtain and review them prior to
the meeting.
2.2.2 Statement of Objectives/Scope/History
Steve spent a few minutes reviewing the objectives, scope, and
history of the group for those who were not at San Jose. He
emphasised that the DSWG was chartered to develop a technical
3
framework for an X.500 deployment, but was not intent on being the
instrument for deployment.
2.2.3 Introduction of Documents
Steve briefly introduced each of the documents that were input to
the meeting:
o Replication Requirement to Provide an Internet Directory Using
X.500. S.E.Kille.
o Replication to provide an Internet Directory using X.500: A
Proposed Solution. S.E.Kille.
o IETF Directory Working Group Scope (Version 3). S.E.Kille.
o The COSINE and Internet X.500 Naming Architecture. P.Barker
and S.E.Kille.
o Building an Internet Directory using X.500. S.E.Kille.
o An Interim Approach to use of Network Addresses. S.E.Kille.
o A String Encoding of Presentation Addresses. S.E.Kille.
o Using the OSI Directory to achieve User Friendly Naming.
S.E.Kille.
3 Liaisons
3.1 NADF -- Marshall Rose (PSI)
The North American Directory Forum is a consortium of service
providers and potential service providers of public X.400 and X.500
services. The NADF has as its focus the North American market.
However, they realise the need for international connections,
possibly through multi-lateral agreements. Their raison d'etre is
to figure out how to share proprietary information, required to
provide a seamless service, without compromising their business
interests.
The NADF has had four meetings to date. Their next meeting is in
March, 1991. Stable technical proposals addressing some of the
NADF members' concerns will probably be made in March, but the
4
consensus process makes actual timeliness for agreements uncertain.
The primary contact for the NADF is Don Casey (Western Union). To
provide continuity, a standing chair, Ted Meyer (Rapport), has been
retained.
3.2 OIW Dir SIG -- You-Bong Weon-Yoon (ATT)
The OSI Implementors' Workshop (OIW) produces multi-vendor
agreements based on OSI standards. The Directory Special Interest
Group (Dir SIG) produces agreements on the X.500/ISO 9594 standard.
Current work in the SIG is in developing international standard
profiles (ISPs) through coordination with the two other regional
OSI workshops, EWOS in Europe and AOW in the Pacific rim area.
Beginning in the December, 1990 meeting, the SIG will begin
developing multi-vendor implementation agreements on replication,
access control, and distributed operations (the latter will be
coordinated with the OSINET work on interoperability test
development).
3.3 RARE WG3 -- Steve Kille (UCL)
RARE WG3 has two subgroups of interest: a user information area
and a group working on directories. The Directory group has an
analogous function in Europe to this WG of the IETF. The next
meeting of RARE WG3 is January 17-18 in Brussels.
3.4 ISO/CCITT Meeting in Ottawa -- Steve Kille (UCL)
Steve summarised the current work in Directory standardisation as
it stood after the Ottawa meeting. The main areas of interest were
in:
o extensions to the information model in the areas of schema
(e.g., publication) and operational attributes (i.e., those
associated with a subtree, such as access control defaults),
o abstract services -- e.g., paged results (does not deal with
collating),
o matching rules -- will be user-extensible, rather more formally
defined than today, and bound to attribute syntax,
5
o replication -- now a CD (Committee Draft -- what used to be a
DP); defines incremental shadowing, among other paradigms,
o distributed entries -- large and complex document, not well
organized and difficult to comprehend. CCITT is intent on
seeing this in 1992, but it is not believed to even be a Work
Item in IEC,
o short-form names -- some support is expected in 1992, though
not necessarily a good technical solution,
o migration from '88 to '92 X.500 -- a document is available on
this,
o access control -- work is progressing, but the editor recently
resigned. A new editor has taken over and the access control
documents have been reissued on a second PDAM ballot (Proposed
Draft Amendment -- used to be PDAD).
4 PSI White Pages Pilot Presentation -- Marshall Rose (PSI)
Information is available as PSI TR 90-05-10-1 and PSI TR 90-09-10-1
from info@psi.com.
Marshall provided an overview of the PSI WP Pilot. As a
digression, he described an alternative name registration scheme
based on the existing civilian naming infrastructure for states,
counties, cites, etc. Some questions remain. This will likely
come onto the agenda at the next meeting.
5 FOX -- Paul Mockapetris (DARPA)
Paul briefly discussed the Field Operational X.500 (FOX) project
that DARPA is funding. It is based on a pair of meetings that
occurred two years ago which resulted in RFC 1107. There are four
participants:
o ISI -- main contractor and responsible for project oversight,
o NYSERNet/PSI,
o Merit, and,
o SRI.
6
The objectives are twofold: 1) get X.500 closer to operational
status, and, 2) demonstrate interoperability among multiple X.500
implementations. SRI will use the NIST implementation and
investigate supporting some of their traditional roles, such as
registration. Merit is considering using X.500 to publish network
numbers. PSI will be cooperating in interoperability testing with
the NIST implementation and another implementation (as yet
undecided).
6 Cosine Pilot Directory Service -- Steve Kille (UCL)
The slides of this talk are available from UCL. Mail to
info-server@cs.ucl.ac.uk.
7 Scope of Group and Review of Charter
Fundamentally, there were no significant disagreements about what
the scope and charter documents say. There were two specific
decisions made:
o the scope should specifically state that the aim of the group
is to align with the base standards and profiles on the
extensions when these become available, and,
o the charter will be collapsed into the scope document.
8 Infrastructure Strategy
The document Building an Internet Directory Using X.500 was
discussed. The substance of the discussions was:
o the document needs a caveat that this approach will not
necessarily address everyone's X.500 needs,
o need to address the issue of name allocation at the top levels
of the naming tree,
o need to do a better job of naming DSAs, rather than just having
them named high up in the tree (which is awkward),
o under the section on replication of knowledge and data, add
that an intercept strategy could be defined by others (e.g.,
the OIW Dir SIG), not necessarily by this WG,
7
o in Section 3.3, the sentence that begins, ``There is a
requirement to extend...'' will be amended to read, ``There
may be a requirement to extend...''
There was general agreement on the contents of the document and
folks felt that it should move forward. Steve proposed that the
target should be to have it become an RFC in one to six months.
9 Replication Requirements and Scheme
A number of issues arose during the discussion of replication:
o lower-layer stacks -- combinations of LL stacks should be
allowed even thought this results in less-than full
interconnectivity of DSAs. However, guidance should be given
on the desirability of having increasingly richer connectivity
as one moves higher up in the tree;
o remove Section 3 of requirements document -- this is either a
trivial or intractable problem; in either case, no statement is
needed
o Section 5 of requirements -- there was some confusion about
what this section meant. Steve agreed to rewrite it in words
similar to those he used in explaining it;
o Section 6 of requirements -- the new scaling target will be
100,000 non-leaf entries, given that this is at least an order
of magnitude greater than what we think is really required;
o replication approach -- after some discussion of the
appropriate approach to take to replication --- a non-standard
scheme such as that in QUIPU, an intercept strategy, or wait
for the standard. The general discussion was inconclusive. A
subgroup, consisting of those most active in the overall
disucssions was formed (DO, PM, PK, GM, SK) to look at the
problems, and in particular the issues of migration. The
consensus of the off-line discussion was that the best
approach, all things considered, was to use a scheme based on
that described in the replication proposed solution document.
This was agreed to by the rest of the WG. Also agreed was that
a replication scheme based on the standards work will be
adopted when available. The interim nature of the solution
should be emphasised. It was noted that DUA/DSA interaction is
not affected.
8
10 Domains and X.500
There was some discussion on how to represent domain names (i.e.,
the attributes) in the X.500 DIT: octet strings or IA5 strings.
There seemed to be some confusion about what the implications of
this are. Steve said that he would talk to Paul Mockapetris
off-line and figure out what the issues really are.
There was some lengthy discussion on the utility of storing DNS
information in the DIT.
Steve agreed to make the minor changes to the document suggested by
the discussion. Otherwise, he will progress the document as an RFC
pretty much as is.
11 Day 2
Gita Gopal of Bellcore gave a presentation on a Bellcore research
project studying methods of providing support for distributed
entries in a heterogeneous multi-server, multi-protocol,
multi-media, multi-context environment.
The Bellcore method is based on a central LDB, or Linking Data
Base, which contains one entry per person keyed on a unique PID
(personal identifier). Each entry contains references to all known
DBs holding information about the particular individual, as well as
the protocol information necessary to access those databases (i.e.
J. Foobar, Widget Inc, X.500 DSA, RFC1006 address, etc...).
The chief goal of this project is to allow users to access any and
all information about individuals maintained by various DBs using
only information from a particular DB. For example, given a DN for
a person's business entry (i.e. an organizationalPerson), a user
would be able to send mail to that person's home by telling a UA to
check the LDB and use the business DN to find a residential OR
address.
The use of aliases in an X.500 DIB was suggested as an alternative
method of achieving the same results, but was rejected as being
inapplicable to distributed entries. The LDB solves the
distributed entry problem by considering the person as the
essential element rather then focusing on the entries themselves.
Contexts are supported using a dynamic schema. Users are expected
to have some knowledge of the context from which they are searching
(the example of having to know what a telephone number is, and what
9
equipment it can be used with, before being able to make use of it,
was raised as analogous to the LDB scheme).
There are several outstanding issues that require further research:
the LDB only links entries for people - certain simplifying
assumptions have been made based on this - the capability for
handling the more complex interactions and interlinkages that might
arise when linking information about machines, applications, or
organizations; security has not been thoroughly explored, nor have
access controls; the "publishability" of PIDs needs further
investigation - are these to be used exclusively as internal
pointers, or has more general "personal access (i.e. phone)
numbers"?; management and generation of unique PIDs, and the
administrative problems involved.
12 User Friendly Naming
Discussion then turned to Steve Kille's paper on User Friendly
Naming. The goals of this paper are the provision of: an improved
method of transmitting names, and better handling of purported name
lookup.
The Result Of The Discussion Was That Steve Would Revise The Paper
To Reflect The Issues And Concerns Raised By The Wg, And Present It
Again At The Next Meeting.
Among the issues raised were:
tuning the algorithm to handle changes in DNs; at the moment, a
change to a previously resolved DN makes that earlier resolution
useless (the user would have to go through the process of resolving
a purported name each time a DN changed). the addition of "yet
another" syntax, and the related issue of other work in the field,
specifically the OSF work. It was decided that the paper would
reference and track the OSF work.
Yew-Bong referred to the work Al Grimstad of Bellcore, which was
submitted to CCITT SG VII as a corporate position on User Friendly
Naming. Current SG work should also be tracked.
The X.500 SG is unlikely to provide a standard until 1996: should
this method be submitted for SG VII consideration?
Moving from one machine to another: is it reasonable to expect the
same syntax to work under different architectures (i.e. VM and
Unix, where, for example, the meaning of `"' to the command line
10
interpreter is vastly different (quote on Unix, escape character on
VM).
The related issue of allowing a user to "tune" their environment:
different machines (under the control of different organizations)
might have different "correct" behaviour. User customisation might
hide or expose these differences, and make searching more
difficult.
Vinton Cerf and Peter Mierswa suggested that User Friendly Names
are inappropriate as an "exchange format": only DNs should be
relied upon, and communicated between users. In addition, V.C.
suggested that "guessability" was less important than exactness.
Paul Mockapetris raised the question of the "Monte Carlo" method of
name resolution: users guess at a name and receive a list of
possibilities; they continue guessing until they get the DN they
want or need. The user interface should allow this behaviour.
The current model does not handle deep DITs very well; more work is
needed in this area. It would help if the top two or three levels
had "non-obscure" names. wild card searches (especially leading
wild cards) need further investigation. multiple occurrences of
the same string in a DN (i.e. as both a county and a city) must be
underlined to the user. DNs should always be returned when
resolved - should users be able to build dependencies on purported
names? care must be taken when stripping RDNs for
"displayability".
13 Replication Solutions
Steve introduced this section by noting that several documents bear
directly on this subject, notably the proposed RFCs on Presentation
Address Representation and Network Address Representation. It was
decided that these would be dealt with first.
13.1 Network Addressing
Steve's summary of the problem, and the solution offered in his
paper:
If you look at an OSI address from a DIT, you get a presentation
address, which works fine with an OSI network service, but does not
work with RFC1006 or X.25( 80) addresses, owing to the lack of an
OSI network server for these address formats. This document
11
provides a method, using Telex addresses, to map non-OSI addresses
onto OSI addresses. It is ugly, but it is functional, and requires
no extensions to current protocol.
The OSF Towers solution allows you slice different protocols in and
out at any particular layer, allowing you a choice of transport and
network addresses. It is a better and more elegant solution, but
it requires extension to X.500(88). This is unacceptable, in my
view.
Ideally, I would like to push OSI/CCITT into adopting OSF Towers
for 1992; we could move to it at that time. Until then, however,
we would be better off going with an interim solution that does not
require protocol extensions, but that allows full
inter-connectivity.
After a brief discussion to clarify the reasons for adopting this
method over the Towers method, it was agreed that this would be
accepted as the OSI-DS WG official recommendation on network
addressing, but that it would be explicitly noted as an interim
solution only.
Among the concerns raised were:
OSF Towers and this method are both "hacks", the former as it
requires extensions, the latter as it uses the UCL Telex number as
the basis of network addresses. Steve's method is less of a hack,
though.
This method does not guarantee 100% success: if a DUA cannot
interpret the Telex number, then it will not be able to contact the
specified entity. Steve admits that this method does not give 100%
success, but since it uses current protocols rather than
extensions, it will offer a better success rate than Towers.
13.2 Presentation Addresses
Steve: this document must be taken in concurrence with the Network
Addressing document: it provides for better handling of dotted
decimal encodings, and provides an extension to presentation
address handling (`/' changed to `+') to bring our work in line
with ISO 8348 (X.213).
P.M. This is an extension to the standard?
S.K. Yes.
12
G.M. Is there a need to represent a presentation address that
specifies an IP address that is not an RFC1006 address?
S.K. I hope not, but we need to be able to specify IP addresses
that are not on the Internet, such as local LANs.
After minimal discussion, it was agreed that this document should
proceed in parallel with the Network Addressing paper.
13.3 Replication Solutions
Steve provided an overview of the current proposal:
Sec. 1: Benefits of the approach: it has been proven in
operation; owing to its current use, there will be minimal effort
involved in moving to it as a pilot standard; the approach is
simpler and easier to implement than the current standards
approach.
Sec. 2 Enhancement of Distributed Operations to provide better
handling of referrals and chaining (an extension to the standard).
This approach is closely tied to the previously reviewed papers on
network and presentation addresses. It uses the concept of a
"community" (coded into the presentation address) to allow a D SA
to decide if a DUA and another DSA can in fact communicate
directly.
Sec. 3 Extend the semantics of X.500 so that DSAs can deal more
intelligently with Subordinate, Cross, and Non-Specific
Subordinate, References.
Sec. 4 The replication data model: replication of all sibling
entries rather than subtrees, or specific entries.
Sec. 5 Improved DSA naming: placing DSA names in a well known DSA
with root knowledge; placing DSA names in the higher (closer to the
root) portions of the DIT.
Sec. 6 Definitions of objects necessary to represent knowledge
information in the DIT (rather than having DSAs maintain it as a
"local matter").
Sec.7 Definition of a simple replication protocol: data
propagation in a star-like fashion.
Sec.8 Definition of the "Internet DSP" Application Context to allow
13
for easier identification of Internet extensions.
Sec. 9 Scaling limits and migration strategy.
Sec. 10 Reserved for future definitions of application contexts,
object classes, and attributes necessary for replication
The Result Of The Discussion Was That Steve Would Revise The Paper
To Reflect The Issues And Concerns Raised By The Wg, And Present It
Again At The Next Meeting.
In addition, Steve introduced the ASN.1 required to allow QUIPU to
transfers replicated EDBs in pieces, rather than single units.
This extension will be available in the next release.
Steve also suggested that it would be appropriate to write a paper
on how to structure the DIT to achieve high performance and high
reliability using current replication methodologies. He took this
as an action item for himself. This document could then be put
forward as a statement of administrative guidelines on DSA naming,
and DIT structure.
Issues raised:
scaling: the paper quotes 10000 units as the upper level of
scalability. Steve noted that this refers to fan-out, not number
of entries, as the unit of replication is a single level, and not
an entry or subtree. Steve also noted that QUIPU would be extended
to allow incremental updates of replicated data using an MHS. Since
the master DSA would always be reachable, there would be no problem
in using MHS to transfer EDBs while using replicated data to lookup
the appropriate MHS address.
DSA-DUA communities. The paper as presented did not properly
described how a DS A decides whether or not a DUA and another DSA
can communicate directly. Steve indicated that he would rephrase
Section 2 to reflect the fact that PSAP communities are used to
make this decision, not actual physical connections.
V.C. asked whether access controls were replicated. Steve answered
that private agreements must be used to maintain ACLs on replicated
data, and that an open environment would be publicly readable. ACs
are stripped during replication as they are a private matter: only
published schema get transferred.
P.M. questioned the Section 3 use of NSSRs: the changing of NSSR
semantics from AND to OR would mean that multiple DSAs could not
hold different "chunks" of superior entries. Steve indicated that
14
he would place a clear warning about this in the document.
Expiry dates on information. Two separate issues were identified:
caching and replication. It was determined that caching requires a
TTL mechanism, but that replication can use a simpler approach,
such as having a slave make regular "pulls" from the master. P.M.
noted that applications must be built to expect stale data (X.500
makes no guarantees about data freshness), and that obtaining
authoritative data is an application problem. It was decided that
the unit of replication would be delivered with an advisory refresh
date.
14 Naming Architecture Registration
Steve: In order to build useful applications, we need to extend
the Naming Architecture as supplied in the standard. This paper
describes the formal administrative support for the creation of new
elements in the architecture. The aim of this session is to
discuss and define the registration and maintenance methodologies
(currently UCL maintains pilot architecture for both the Internet
and COSINE). UCL would maintain ownership of this document until
the end of the COSINE project in December of 1992. It is hoped
that this work will have been incorporated by the standards bodies
by that time. The document defines an arbitration method for
deciding what does and does not become part of the naming
architecture: the editor has discretionary powers to include,
exclude, or modify, as needed, subject to appeals to the OSI-DS WG
mailing list, or arbitration from RARE and the OSI-DS WG.
After a brief discussion, it was agreed that this document could be
issued (with minor revisions) as the first RFC of the DS series,
and that it would be updated every 3-6 months.
Issues raised:
Size of entries in a DIT: concern focused primarily on the size of
the photo attribute. After some discussion, Steve indicated that
he would reword the document to indicate that participating DSAs
can store entries at their discretion, but that if they choose to
store entries of a given type, they must agree to store the
published attribute maximum sizes.
PWW, MK, and ?? mentioned concerns with certain object classes and
attribute types listed in the paper. After gentle chiding from SK,
they agreed to test the procedure by submitting complete ASN.1
proformas for the additions they were concerned with.
15
Steve indicated that he would make an arbitrary decision whether or
not to include the appendices Unix shells for Naming Architecture
Maintenance. They were considered useful, but not for everyone.
15 Security Considerations
Peter Yee: this paper identifies some of the security issues that
must be addressed when planning a security policy for the Internet
pilot.
Steve Kille: We must distinguish between X.500 as a user and as a
provider of security for the pilot. As a provider, we can use
X.509 in a very straightforward fashion.
As a user of security services, we have a more interesting issue.
Unlike replication, we can work entirely within the standards. We
need to prepare notes identifying the organizational issues
involved, and documenting methods addressing these issues. There
are three main areas of concern: authentication, access control,
and remot e updates.
After considerable discussion, it was agreed that Peter Yee should
revise and re submit his document for consideration at the next
meeting. Steve Kille asked for volunteers to do the "voluminous
legwork" required to research and resolve the open items in this
area, but there were no volunteers.
Issues raised:
Remote management. There was considerable disagreement over the
issue of simple authentication as adequate security for remote
management. PEM representatatives and proponents of strong
authentication felt that simple authentication was not appropriate,
as it would be too easy for an outsider to remove or modify
certificates, or keys.
One proposed solution that was partially acceptable is the
requirement that DSAs be able to store X.509 information
(certificate lists, public and private keys, certificates), and
that DSAs using simple authentication or no authentication would
not allow remote updates.
Searchability. Several participants indicated that without some
form of access control, they would not open their DSAs to the
Internet, as they did not want to allow "DSA dumping". It was
generally accepted that authentication (simple or strong) or
16
"skinny pipes" on searches would be acceptable.
Steve Kille has since proposed a method of limiting searches and
lists to the OSI-DS WG mailing list.
Applications that require X.509. There was some debate over
whether or not the number of applications requiring strong
authentication would actually increase if it were provided. More
research is needed, as this is a "chicken or egg" situation: do
the applications cry out for X.509, or does X.509 invite new
applications?
The relationship between the OSI-DS WG and RSADSI/PKP. It was
suggested that perhaps the IETF or the IAB could negotiate an
Internet wide RSA licence with the relevant bodies. More liason
work and research is needed.
16 Next Meeting
SRI offered to host the next meeting in California, Feb. 12-13.
Steve will issue a preliminary agenda in the near future.
17 AOB
Standard APIs. It was agreed that the IETF should adopt a standard
API for the pilot. X/OPEN and XDS were mentioned. This item will
be discussed further at the next meeting.
The Canadian X.500/Library Project. Dave Brent asked if the WG
should look into this. Stev asked for volunteers to propose an RFC
on the subject. This will be discussed at the next meeting.
17