Network Working Group C. Huitema/INRIA
Internet Draft P-A. Pays/INRIA
December 1993 A. Zahm/TS-E3X
Expiration Date: June 1994 A. Woermann/TS-E3X
Simple Object Look-up protocol (SOLO)
<draft-huitema-solo-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "work-
ing draft" or "work in progress." Please check the 1id-abstracts.txt
listing contained in the internet-drafts Shadow Directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet Draft.
[Huitema et alii] [Page 1]
Internet Draft SOLO December 1993
Abstract
We present here a simple access protocol to a "white page" service. This
protocol is based on the experience acquired in several X.500 based
"white page" pilots, and builds upon such developments as the "user
friendly naming" notation or the "centroids" concept developped in the
"whois++" project.
Although largely inspired by the X.500 protocol, SOLO does not try fol-
low the X.500 model. Designing a SOLO front-end to an X.500 server is
very easy, but the SOLO internetworking is not based on X.500 -- the
navigation part is based on the WHOIS++ centroids. In fact, one can as
well design a SOLO front-end to a WHOIS server, and only minor efforts
are needed for redesigning a "finger" daemon to provide the SOLO ser-
vice. Conversely, the SOLO service is powerful enough to make gatewaying
between X.500 access protocols and SOLO easy.
The first section of this memo present the basic SOLO protocol. The
second section presents the methods which are used for "networking" SOLO
servers. The third section is a formal definition of the SOLO protocol.
Section 4 list the various SOLO information messages. Section 5
addresses the security implications of providing a SOLO service.
1. Presentation of the SOLO protocol:
The SOLO protocol consists of two main operations: a simple look-up
operation that enables clients to request information on a name
object, and a "zone transfer" operation used by index handlers.
These operations are carried upon TCP-IP connections; the requests
and results use a simple text format. Three additional commands are
defined, i.e. a "signal" to notify the need to poll a server, a
"reset" to abort an ongoing operation, and a "quit" to close the
connection.
1.1. A basic example:
In order to request information on an object, a client will set
up a TCP-IP connection towards the server. Servers will be
awaiting requests on port <solo>. After establishing the
[Huitema et alii] [Page 2]
Internet Draft SOLO December 1993
connection, the client will send a request of the form:
SOLO <Huitema, Sophia, INRIA, FR> ? CN, O, OU, Phone, Email;
In this line, SOLO is the command name (other commands are for
example QUIT or POLL). It is followed by the "name" of the
object, which is expressed using the "user friendly name" con-
ventions, by a question mark, and by a list of "attribute
names", using the acronyms defined for the white page pilot.
If the server was able to find the information, it will send a
"matched" reply, followed by the values of the attributes, end-
ing by a dot on a line by itself, e.g.:
500 Matches: <CN=Christian Huitema,OU=Sophia,O=INRIA,C=FR>
CN: Christian Huitema
OU: Sophia, Sophia-Antipolis,
"Unite de recherche de Sophia Antipolis"
O: INRIA, "INSTITUT NATIONAL DE RECHERCHE EN
INFORMATIQUE ET AUTOMATIQUE"
Phone: +33 93 65 77 77
Email: Christian.Huitema@sophia.inria.fr
.
Indeed, several errors could have occured, for example if the
name was ambiguous or non existent, or if the server did not
hold the information locally.
After receiving the response, the client has the choice to send
another command, e.g. to get information on another object, or
to close the connection.
1.2. Name errors
SOLO servers distinguish three kinds of name errors, ambiguous
specifications, incorrect specifications and over specifica-
tions. They reply to these errors by an appropriate error mes-
sage, optionally followed by one or several "hints", i.e. sug-
gested references. The following dialogue is an example of
[Huitema et alii] [Page 3]
Internet Draft SOLO December 1993
ambiguous reference:
SOLO <Martin, Sophia, INRIA, FR> ? Phone, Email;
201-Ambiguous name: <Martin, Sophia, INRIA, FR>
301-Partial Match: <Sophia, INRIA, FR> <OU=Sophia,O=INRIA,C=FR>
400-Suggestion: <CN= Laure Martin,OU=Sophia,O=INRIA,C=FR>
400 Suggestion: <CN= Michel Martin,OU=Sophia,O=INRIA,C=FR>
There were several "Martin" at INRIA, and the server just pro-
vide the names of all entries that matched the request. The next
dialogue is an example of incorrect reference:
SOLO <Huttema, Sophia, INRIA, FR> ? Email;
202-No such name: <Huttema, Sophia, INRIA, FR>
301-Partial Match : <Sophia, INRIA, FR> <OU=Sophia,O=INRIA,C=FR>
400-Suggestion: <CN= Christian Huitema,OU=Sophia,O=INRIA,C=FR>
400 Suggestion: <CN= Bernard Hettena,OU=Sophia,O=INRIA,C=FR>
Note that the server applied here a local strategy to derive
possible matches -- it tried a "phonetic" match on the name
token "Huttema". Also note the presence in both examples of a
"partial match" information line: it signals that the upper com-
ponents of the name assertion, in this case <Sophia, INRIA, FR>,
were exactly matched by the server and correspond to the dis-
tinguished name <OU=Sophia,O=INRIA,C=FR>.
Note that there could be examples where intermediate components
are ambiguous, for example:
SOLO <Martin, IN*A, FR>? Email;
201-Ambiguous name: <Martin, IN*A, FR>
400-Suggestion: <Martin,O=INA,C=FR>
400-Suggestion: <Martin,O=INRA,C=FR>
400 Suggestion: <Martin,O=INRIA,C=FR>
In that case, the suggestion contains potential candidates for
"continuation" queries. The server can use two methods to con-
struct the "suggested name", i.e.:
[Huitema et alii] [Page 4]
Internet Draft SOLO December 1993
(1) replace the "upper part" components of the initial query by
a "distinguished" value,
(2) provide the "distinguished name" of candidate entries.
In the first case, the suggested name is not necessarily a "dis-
tinguished" name, but merely a hint that can be used in a
further query.
Over specification occurs when a requestor present a set of nam-
ing attributes, some of which cannot be matched:
SOLO <Huitema, Sophia, Region=PACA, INRIA, FR> ? Email;
203-Over specified name: <Huitema,Sophia,Region=PACA,INRIA,FR>
301-Partial Match: <INRIA, FR> <O=INRIA,C=FR>
400 Suggestion: <CN= Christian Huitema,OU=Sophia,O=INRIA,C=FR>
1.3. Partial name matches and redirections
A SOLO server may not always be able to fully match a query.
There will be cases however where the local server can provide
some "hint" on the resolution of some of the "name parts". For
example, a server that knows that the company E3X has recently
changed names may be able to respond to a query by a partial
match indication:
SOLO <Woermann, OSI, E3X, FR> ? Email;
301-Partial Match: <E3X, FR> <O=TS-E3X,C=FR>
400 Suggestion: <Woermann, OSI,O=TS-E3X,C=FR>
In the previous exchange, the SOLO server did not provide an
indication of where to submit the next query. It could indeed
have provided such information through a "suggested server" mes-
sage:
SOLO <Woermann, OSI, E3X, FR> ? Email;
301-Partial-Match: <E3X, FR> <O=TS-E3X,C=FR>
302-Suggested-server: <O=TS-E3X,C=FR> mitsou.inria.fr
302-Suggested-server: <O=TS-E3X,C=FR> osi.e3x.fr
400 Suggestion: <Woermann, OSI,O=TS-E3X,C=FR>
[Huitema et alii] [Page 5]
Internet Draft SOLO December 1993
Note that we have suggested here two different servers. The
client will presumably chose one based on local information.
1.4. Absolute matches:
There are some cases where the SOLO user wants to completely
specify the name of the requested object, without leaving any
interpretation possibility to the server. This is specified by a
particular format of the SOLO request:
SOLO <CN= Christian Huitema,OU=Sophia,O=INRIA,C=FR> ! Email;
The differences between this format and a standard request are
the following:
(1) The name should be fully specified. The separator between
the name and the list of attributes is an exclamation mark
(!) instead of a question mark (?).
The SOLO server can only respond positively to this query if it
finds an entry that exactly matches the purported name.
1.5. Attributes and Universal Resource Locators (URL)
It is often impractical for a server to provide a complete
attribute value: some objects like photographies or voice seg-
ments are too bulky to be transmitted easily. Others may not be
available on the SOLO server itself. In these cases, the SOLO
server may elect to return a pointer to the value, in the form
of an "Universal Resource Locator", instead of the value itself.
The presence of an URL in the value field is signalled by a
placing an hyphen in front of the attribute type, as in:
SOLO <Huitema, Sophia, INRIA, FR> ? Photo, Email;
500 Matches: <CN=Christian Huitema,OU=Sophia,O=INRIA,C=FR>
-Photo: "http://zenon.inria.fr:2220/peoples/huitema/photo"
Email: Christian.Huitema@sophia.inria.fr
.
[Huitema et alii] [Page 6]
Internet Draft SOLO December 1993
In fact, some clients may want to force this facility, in order
to be able to locate an attribute without having to actually
receive the data. They can achieve this by prepending an hyphen
in front of the attribute type in their request, as in:
SOLO <Huitema, INRIA, FR> ? -Email, -Photo;
500 Matches: <CN=Christian Huitema,O=INRIA,C=FR>
-Photo: "httl://zenon.inria.fr:2220/peoples/huitema/photo"
-Email: "solo://mitsou.inria.fr:8888/<Huitema,INRIA,FR>!Email"
.
Note the special form of universal resource locator used for the
"Email" attribute: this is the normal way to designate a
resource reachable through within a SOLO server.
Clients cannot force SOLO servers to return a value instead of
the URL: this could be outside of the server's capabilities.
However, servers should always return the full attribute value
when this is available.
1.6. Aliases and alternate values:
Some SOLO servers will be implemented as access points to an
X.500 service. It is important that the SOLO clients recognize
some oddities which can result from the X.500 support of aliases
and alternate values, e.g.:
SOLO <S=Bolot+First=Jean,O=INRIA,C=FR>?Email;
500 Name matches: <CN="Jean-Chrysostome Bolot",O=INRIA,C=FR>
Email: "bolot@mitsou.inria.fr"
SOLO <CN="Suzan Mendes",OU=Sophia,O=INRIA,C=FR>?Email;
500 Name matches: <CN="Suzan Mendes",OU=OSI,O=TS-E3X,C=FR>
Email: "s.mendes@osi.e3x.fr"
.
In the first case, the first name specification "Jean" was
matched by one of the multiple values declared for the first
name attribute, although the common name refers to the dis-
tinguished value "Jean-Chrysostome". In the second case, the
[Huitema et alii] [Page 7]
Internet Draft SOLO December 1993
entry for "Suzan Mendes" was an alias, pointing to her real
entry in the X.500 server of TS-E3X.
In fact, X.500 is probably not the only name service that pro-
vides aliasing or alternate names. We are likely to observe the
same "oddities" with many data bases.
1.7. Filters and substrings:
There are cases where the clients will not be able to completely
specify the name of the object they are searching. The SOLO pro-
tocol allow these clients to enter "loose" specifications by
means of substrings or filter.
Any name part can be replaced by a substring specification,
using the special character "*", as in for example:
SOLO <chr*Hu*ma*, INR*, FR> ? Email;
500 Matches: <CN=Christian Huitema,O=INRIA,C=FR>
Email: huitema@sophia.inria.fr
.
As implied by well established conventions, the "*" can be
matched by any sequence of characters.
The "User Friendly Name" syntax allows users to combine several
"attribute assertions" in a name part, using the "+" character
as a delimiter, e.g.:
SOLO <First=Christian + S=Huitema, INRIA, FR> ? Email;
The "+" character is in fact equivalent to an "AND" operator.
The SOLO syntax extends this possibility by also allowing the
character "|" as an OR operator, e.g.:
SOLO <CN=John Smith | CN=Jack Smith, INRIA, FR> ? Email;
Which can be matched by either value. Indeed, the "+" and "|"
can be combined, in which case "natural" precedence rules apply,
[Huitema et alii] [Page 8]
Internet Draft SOLO December 1993
i.e. the AND operation takes precedence over the OR. For exam-
ple, the previous specification is equivalent to:
SOLO <First=John+S=Smith | First=Jack+S=Smith,INRIA,FR>?Email;
Experts will note that this notation is more restrictive than
the full set of boolean combinations allowed by X.500 filters.
This restriction is based on the desire to keep SOLO simple, and
also supported by the substantial experience acquired by the
authors when deploying X.500 systems. We believe that the pro-
posed compromize is just right.
Experts will also remember that the "User Friendly Name" specif-
ication imposes a restriction on the use of the "+" delimiter:
when multiple assertions are stated in a name part, then they
should be explicitely typed. This restriction does not apply in
SOLO. The following command:
SOLO <John + Smith | Jack + Smith, INRIA, FR> ? Email;
is explicitely allowed.
1.8. Limiting the size of the output:
The filters, the substring notation, or even the use of partial
matches, may enable the user to specify extremely fuzzy names.
Such fuzzy names can potentially be matched by a very large
number of entries.
Sending very long lists of "suggested" names is inadequate for
several reasons:
o it may be a very inefficient use of network resources,
o it may impose unexpected constraints to the user interface
which is not necessarily rigged to handle long lists,
o it may also be a privacy violation, as it would allow
intruders to easily obtain complete listings of an
[Huitema et alii] [Page 9]
Internet Draft SOLO December 1993
organization's personal.
SOLO servers are allowed to limit the number of names which can
be returned by a single command. A limited set of result will be
signaled by a specific error report:
SOLO <Martin*, INRIA, FR> ? Email;
201-Ambiguous name: <Martin*, INRIA, FR>
400-Suggestion: <CN= Laure Martin,OU=Sophia,O=INRIA,C=FR>
400-Suggestion: <CN= Michel Martin,OU=Sophia,O=INRIA,C=FR>
204 Too many names to list them all.
In fact, the privacy argument is so compelling that SOLO servers
are encouraged to impose a relatively low limit, e.g. not larger
than 8. The precise value of this limit should be set by the
local administrator, as well as a policy choice to display a
random set of suggested names first and then the error message,
or to not display any name at all if the command is too fuzzy.
2. Networking white page informations:
The SOLO server may want to maintain "indexing" information. This is
done according to the "centroid" model. The informations held by a
given server are summarized in a centroid, i.e. a gigantic entry
that contain for all indexed attribute types the list of attribute
values found in any of the data base entries.
2.1. Using the index request:
In order to obtain the indexing information belonging to a
server, a client or another server may set up a TCP connection
to the server using the <solo> port, then send the index com-
mand:
POLL S, OU, O, L, C;
Where POLL is the command, <> an empty name specification, and
where the rest of the command just lists the attributes for
which indexing information is required. A typical response will
be:
[Huitema et alii] [Page 10]
Internet Draft SOLO December 1993
501 Sending indexes.
S: Name1, Name2, Name3, Name4,
name5
OU: Unit1, Unit2
O: The local org name
C: XX
.
Errors can indeed occur, e.g. if the server is unwilling to send
the requested information.
A special form of the command allows the clients to obtain the
list of attributes managed by the server, i.e. by specifying an
empty list of attributes.
POLL ;
502 Providing attribute list
C, L, O, OU, S, G
.
Indexing servers will keep this information and organize it in
tables in order to manage navigation.
In some cases, the server may be unwilling to provide a full
listing: for example, providing the names of all the employees
of a company may be perceived as a serious security violation.
In this case, the server may elect to replace the attribute
values by a simple "star":
POLL S, OU, O, L, C;
501 Sending indexes.
S: *
OU: Unit1, Unit2
O: The local org name
C: XX
.
This procedure may also be used when listing all values would be
unpractical.
[Huitema et alii] [Page 11]
Internet Draft SOLO December 1993
2.2. Signalling secondary servers
In order to set up or maintain the network of SOLO servers, a
POLL command is not sufficient: the index servers have no way to
guess that a new server has becomed operational, or that a
remote data base has been updated.
The SGNL command allows remote servers to "signal" their
existence. More precisely, it allows administrators to notify
the presence of remote servers, as in:
SGNL mitsou.inria.fr
403 Will poll: mitsou.inria.fr
Where an administrator signalled the need to poll the server
"mitsou.inria.fr", and where the index server responded that he
scheduled the emission of a POLL command. There can indeed be
cases where the server will not schedule this emission, such as:
SGNL matso.inrja.fr
111 No such host: matso.inrja.fr
SGNL felix.inria.fr
112 No SOLO server on host: matso.inrja.fr
SGNL tom.inria.fr
113 Unwilling to poll: matso.inrja.fr
Note that this simple "announce message" was prefered to a more
radical transaction where the remote server will take the ini-
tiative to download its indexing data in the local server for
the following reasons:
o we want to allow administrators to use a client interface to
signal the need to poll.
o polling the servers and fetching the data is simpler to
organize, as the data are naturally available.
o pushing the data to an unprepared index server would be
distateful, as the recipient is not necessarily ready to
receive.
[Huitema et alii] [Page 12]
Internet Draft SOLO December 1993
A similar problem was analyzed in the WHOIS++ effort.
2.3. Relaying of queries
SOLO servers which cannot fully solve a query have two choices.
They may simply send back the "partial matches" and/or "sug-
gested servers" informations described in section 1. But they
may also decide to immediately relay the query towards one or
several of the suggested servers.
When doing so, the server will forward the query using the SOLO
protocol, then send the result back to the user.
The server which takes the decision to relay a query may chose
one of the possible servers, or try several of them and con-
struct a response by merging the various results. Whether one or
several server are tested, whether they are tested in parallel
or in sequence, and how the answer is constructed is fully a
local decision: we do not believe that we have acquired enough
experience to write down a mandatory recommendation. However, it
is obvious that some indication of the decision, and in particu-
lar some indication of the source of the data, should be given
back to the user. This is done through a specific information
message, indicating the decision to relay, as in the following
example:
SOLO <Woermann, OSI, E3X, FR> ? Email;
301-Partial-Match: <E3X, FR> <O=TS-E3X,C=FR>
302-Suggested-server: <O=TS-E3X,C=FR> mitsou.inria.fr
302-Suggested-server: <O=TS-E3X,C=FR> osi.e3x.fr
402-Relaying: <Woermann, OSI,O=TS-E3X,C=FR> mitsou.inria.fr
500 Matches: <CN=Ascan Woermann,OU=OSI,O=TS-E3X,C=FR>
Email: woermann@osi.e3x.fr
.
The "relaying" information shows the request that was deduced
from the original query, as well as the name of the server to
which this request was relayed. It is followed by the messages
received from the this server.
[Huitema et alii] [Page 13]
Internet Draft SOLO December 1993
As relayed commands can be further relayed, it is important to
include some protection against loops in the protocol. This is
achieved by inserting an optional "count of relays" between the
SOLO request code and the request itself, as in:
SOLO 1 <Woermann, OSI,O=TS-E3X,C=FR> ? Email;
SOLO servers should increment the count of relay when relaying a
request. They should never relay a request where the count as
already reached a value equal to 8, or larger. An absent count
is equivalent to a count of zero.
2.4. Use of caches:
The experience has showed that name queries tend to be repeti-
tive, and that a "working set" effect can be efficiently
exploited. It is thus highly desirable that servers exploit this
working set effect by keeping a cache of the "most frequent"
requests.
There are three types of information that can be cached by the
SOLO: the full or partial name matches, the binding between
names and servers, and the attribute values.
Full matches are obtained through the "Matches" information
lines (code 500). Partial matches are obtained by the similarly
named information lines (code 301). In both cases, the cache
entry will associate a name request to the matched value.
Server suggestions are obtained through the "Suggested-server"
lines (code 302). The cache entry will associate a name to one
or several suggested servers.
Attribute values are obtained as a result of successfull
queries.
Servers should be careful to time out cache entries after a rea-
sonable duration, so as to avoid keeping aged information alive.
It is suggested to avoid keeping any cache entry more than a
[Huitema et alii] [Page 14]
Internet Draft SOLO December 1993
day.
2.5. Networking with other technologies:
In some cases, SOLO server will be able to determine that the
requested object cannot be accessed through the SOLO service,
but could be obtained using another technology, e.g. whois,
finger or X.500. They can pass this information through the
"suggested service" command, e.g.:
SOLO <Baker, CS, UCL, GB> ? Phone;
301-Partial match: <CS, UCL, GB> <OU=CS;O=UCL;C=GB>
401-S-service: x500://cs.ucl.ac.uk:107/<Baker,OU=CS;O=UCL;C=GB>
401 S-service: finger://cs.ucl.ac.uk:79/Baker
The end of the code 401 line carries an "universal resource
locator". How this information is acquired is outside the scope
of this memo.
2.6. Stacking multiple requests:
The SOLO protocol follows a very simple client/server model.
Clients ask questions, and servers reply by a list of informa-
tions. In some cases, clients may want to send several requests
in one session. They normally do so by sending one question at a
time, waiting for an answer, then proceeding to the next ques-
tion.
Clients may however send further commands on the TCP connection
without waiting for the answer to the previous one.
3. Protocol specification:
3.1. The format of a request:
All requests of the SOLO protocol start by a four letter request
code, e.g. SOLO, POLL, SGNL, RSET, QUIT. The codes can be
[Huitema et alii] [Page 15]
Internet Draft SOLO December 1993
expressed in upper or lower cases, or a combination of both.
In the case of the SOLO request, the command includes:
(1) a variable number of spacing characters (spaces or tabs).
(2) an optional "count of relays" indicator, encoded using one
decimal digit, followed if present by a variable number of
spacing characters.
(3) the name of the requested object, enclosed within angle
brackets.
(4) a variable number of spacing characters (spaces or tabs).
(5) a precision specifier, which can be either a question mark
(?) or an exclamation mark (!).
(6) a list of attributes, terminated by a semicolon (;).
In the case of the POLL request, the command includes:
(1) a variable number of spacing characters (spaces or tabs).
(2) a list of attributes, terminated by a semicolon (;). lp In
the case of the SGNL request, the command includes:
(3) a variable number of spacing characters (spaces or tabs).
(4) the domain name of the server that should be polled.
The RSET and QUIT request don't contain any information after
the command code.
All commands are terminated by an "end of line" mark, composed
of the two characters "carriage return" and "line feed".
[Huitema et alii] [Page 16]
Internet Draft SOLO December 1993
3.2. The format of the replies:
The replies sent by the SOLO servers are always composed of one
of several information lines, followed in some cases by a data
line.
The information lines are always composed of:
(1) A three digit information code,
(2) A continuation character, i.e. a space character if this is
the last information line or an hyphen otherwise,
(3) A free form text composed of letters, white spaces and
digits.
If the line does not contain additional information, the free
form text is terminated by a dot(.). If it contains additional
information, the free text is followed by a semi-colon (:) and
the information. This information is composed of a name specifi-
cation enclosed in angle brackets, optionally followed by
another name enclosed in angle brackets, for partial match
reports, or the domain name of a suggested server. In one case
(code 401), the information is composed of an "universal
resource locator"; in a few other (111, 112, 113, 403), the
information consists solely of a "domain name".
All information lines are terminated by an "end of line" mark,
composed of the two characters "carriage return" and "line
feed".
When the first digit of the last information line has the value
"5", this line is followed by a list of attribute values.
3.3. Format of name specifications:
Name specifications occur in the SOLO request and in several
error messages. Names are formatted according to the rules
specified in RFC-1485 (string representation of distinguished
[Huitema et alii] [Page 17]
Internet Draft SOLO December 1993
names)...
3.4. Format of attribute lists:
Attribute lists are present in the SOLO and POLL requests.
Attribute lists are composed of attribute names separated by
commas (,). An arbitrary number of spacing characters (space,
tab) can be inserted around the attribute names. The attribute
list is always terminated by a semi-colon. An attribute list may
be empty.
The attribute type can be preceded by an hyphen to indicate,
within the POLL command, that pointers (URL) are requested
instead of values.
3.5. List of attribute values:
A list of attribute values is composed of several attribute
values. Each attribute value is encoded of one or several lines
of texts; all lines of text are terminated by a carriage return
and a line feed. The list is terminated by a line containing a
single dot character. The list may be empty, i.e. it may be the
case that the dot line is the only line in it.
The first line of an attribute value starts by the encoding of
the attribute type, followed by a colon. All other lines should
start by one or several spacing characters (space or tab). Each
line contains one or several values, encoded according to the
rules specified in RFC-1488 (String representation of standard
attribute syntaxes), and separated from the following value by a
comma and an arbitrary number of linear spaces.
Within the values returned by the POLL command, the attribute
type can be optionally preceded by an hyphen. In this case, the
values returned are universal resource locators, instead of
actual values.
[Huitema et alii] [Page 18]
Internet Draft SOLO December 1993
3.6. Attribute names:
Attribute names are encountered in name specifications, in
attribute lists and in attribute values.
The attribute names can be:
o simple keywords, as defined in RFC-1488 (String representa-
tion of standard attribute syntaxes) or in the Whois++
lookup service.
o text renditions of object identifiers.
Official keywords should be prefered whenever possible. The fol-
lowing table list a set of key words which are expected to be
recognized by SOLO servers, as well as their WHOIS and "User
Friendly Name" equivalents:
________________________________________________
| Whois (RFC-1274) | RFC-1485 | SOLO |
|_______________________|____________|__________|
| Name (CommonName) | CN | CN |
| (Surname) | S | S |
| (First name) | | First |
| (Country) | C | C |
| (StateOrProvinceName) | ST | ST |
| (LocalityName) | L | L |
| Organization | O | O |
| Department | OU | O |
| Title | | Title |
| Work-telephone | | Phone |
| Fax-telephone | | Fax |
| Work-address | | Address|
| Email-address (RFC822)| | Email |
|_______________________|____________|__________|
The "First" keyword is derived from the "first" command line
argument to "whois"; the "Phone", "Fax" and "Email"
[Huitema et alii] [Page 19]
Internet Draft SOLO December 1993
simplications come from the wide usage of these arguments and
the desire to focus on "business" attribute by default (see the
"security" section for a rationale). The corresponding "object
identifiers" can be found in RFC-1274 (X.500 directory schema).
3.7. Values:
Values are encoutered in name specifications and in value lists.
There are three possible encodings for a value:
o a set of printable characters, excluding any occurence of
the special characters comma(,), colon(:), equal(=), semi-
colon(;) question mark (?) and of the angle brackets (< and
>). In this syntax, multiple occurence of white spaces can
be replaced by a single white space.
o a quoted string, optionally preceded by an alphabet nota-
tion, and delimited by double quotes. In this case, the MIME
"quoted text" format is used.
o a binary string, encoded as defined in the "base64" nota-
tion, and delimited by simple quotes.
Only the first two formats can be used within the command line.
When the value is an universal resource locator, use of the
quoted text notation is encouraged.
4. A list of information codes:
Information codes fall within 5 categories:
(1) System errors are numbered from 100 to 199.
(2) Name errors are numbered from 200 to 299.
(3) Intermediate informations are numbered from 300 to 399.
[Huitema et alii] [Page 20]
Internet Draft SOLO December 1993
(4) User informations are numbered from 400 to 499.
(5) Completion reports are numbered from 500 to 599.
4.1. System errors
System errors indicate that the query could not be further pro-
cessed. The following errors have been defined:
________________________________________________________
| 100| Unrecognized command | |
| 101| Incorrect name specification | |
| 102| Incorrect attribute list | |
| 103| Incorrect command parameters | |
| 104| Momentary congestion, try later | |
| 105| Server problem | |
| 106| Data base problem | |
| 107| Timing out after relaying | |
| 108| Abandoning the request | |
| 110| Too many relays, probably looping| |
| 111| No such host | domain-name|
| 112| No SOLO server on host | domain-name|
| 113| Unwilling to poll | domain-name|
|____|___________________________________|______________|
[Huitema et alii] [Page 21]
Internet Draft SOLO December 1993
4.2. Name errors
Name errors occurs when the name specification is invalid. The
following errors have been defined:
_________________________________________________
| 201| Ambiguous name | <name>|
| 202| No such name | <name>|
| 203| Over specified name | <name>|
| 204| Too many names to list them all| |
|____|_________________________________|_________|
4.3. Intermediate informations
Intermediate informations are informations that can be "cached"
by the server. The following codes are defined:
______________________________________________
| 301| Partial Match | <name> <name> |
| 302| Suggested-server| <name> domain-name|
|____|__________________|_____________________|
4.4. User informations
User informations are suggestions that can be passed to the
user. The following codes have been defined:
________________________________________
| 400| Suggestion| <name> |
| 401| S-service | URL |
| 402| Relaying | <name> domain-name|
| 403| Will poll | domain-name |
|____|____________|_____________________|
[Huitema et alii] [Page 22]
Internet Draft SOLO December 1993
4.5. Completion reports
Completion reports precede a list of attribute values. Two
reports are defined:
________________________________
| 500| Matches | <name>|
| 501| Sending indexes| |
|____|_________________|________|
5. Security considerations:
The SOLO protocol is designed to widely publicize information about
people, e.g. telephone numbers or electronic mail addresses. As
such, the most important considerations relate to the protection of
personal privacy: notification and filtering, listing and browsing.
Then, one finds the classical problem of "name server" attacks. The
attention of the administrators is also drawn onto the particular
problem of embedding login information into mail addresses.
5.1. Notification and removal
In several countries, the privacy protection laws require that
users be notified of their listing in any data base containing
personal information; in some countries, one has to sollicit
their explicit agreement before listing their informations. The
matter is only made worse by the international nature of the
Internet: information placed in a connected data base should be
considered as publicized on a world wide basis.
Even when the local laws do not require it, it is good practice
to observe the following guidelines:
o Notify people listed in the SOLO server that you are pub-
lishing their personal information,
o Be ready to remove some people from their data bases. There
are a number of people who may have good reasons not to be
[Huitema et alii] [Page 23]
Internet Draft SOLO December 1993
listed at all.
o Don't publish more data than necessary. We clearly need to
list identification data such as first names or surnames,
and there are very good reasons for listing an email
address, a fax number or an office phone number. But one
should clearly think twice before listing a home address or
the list of ongoing projects...
Local regulations may impose stronger protections. These regula-
tions should indeed be followed.
5.2. Listing and browsing
Practicians of the "privacy laws" are adamant against the risks
posed by "remote listing" procedures. When available without
restriction, services such as the X.500 "LIST" operation allow
complete foreigners to copy a data base and use it for "innova-
tive" purposes, e.g. correlate it with another base, or use it
as the start of a "mailing" operation.
We have seen in the section on "limiting the size of the output"
the need to limit the number of names returned by the "SOLO"
command. A similar risk is posed by the "POLL" command, as:
POLL CN;
would allow to list the names of all the person present in the
data base. In the absence of secure communications, if the
remote party cannot be precisely identified, administrators of
the SOLO service would be well inspired to limit the set of
attributes returned by the POLL command to only those that iden-
tify the organization, e.g. Organization name, Unit name, Coun-
try, Region and City. The "CN=*" facility should be used instead
of returning a full listing of names.
[Huitema et alii] [Page 24]
Internet Draft SOLO December 1993
5.3. The name server attacks
The SOLO service will be used to store communication data, e.g.
phone numbers or electronic mail addresses. There is a classic
attack against this service, in which an intruder "emulates" a
server and return forged addresses, so that he or an accumplice
receives the information that was meant to be sent to a third
party.
X.500 protects clients against this attack by "strongly authen-
ticating" request and responses, so that there is no way to emu-
late a server or to alter the information. SOLO does not include
strong authentication. Two alternate methods could be used:
(1) Run SOLO on top of a secure network, e.g. using IP security.
(2) Protect the data themselves, e.g. have them signed and
scealed, as e.g. PEM certificates.
One should note that the second alternative is the only one that
maintain the protection even when caches are used.
5.4. Logins and addresses
Email addresses are often build as a combination of a host name
and a login name or account number. It is well known that expos-
ing these combinations facilitates the task of intruders -- they
only have to "guess a password" instead of having to guess both
an account number and a password. This problem is however not
specific to SOLO. Any other white page service or any message
sent to a wide distribution list would also publicize the infor-
mation.
6. Acknowledgments:
We would like to thank the members of the IETF "directory service"
working groups and the participant to OPAX, PARADISE and various
other white page pilots for their encouragements. The use of URLs
[Huitema et alii] [Page 25]
Internet Draft SOLO December 1993
was suggested by Marshall Rose in a discussion on the "future of
X.500", and was also discussed in the RARE "WG-NAP" working group.
The members of the RARE WG-NAP initiated the analysis of the privacy
requirements which is reported in the "security" section. Several
members of the INRIA and TS-E3X teams reviewed the draft. Also, we
would like to pay tribute to the member of the WNILS working group,
as we shamelessly copied the "centroid" concept which was developped
for the WHOIS++ service.
7. References:
(1) Gargano, Joan, Weiss, Ken. Whois and Network Information Lookup
Service, Whois++. RFC in preparation.
(2) Weider, Chris, Fulton, Jim, Spero, Simon. Architecture of the
Whois++ Index Service. RFC in preparation.
(3) Howes, T. , Kille, S., Yeong, W., Robbins, C. The X.500 String
Representation of Standard Attribute Syntaxes. RFC-1488.
(4) Kille, Steve, Using the OSI Directory to achieve User Friendly
Naming. RFC-1484. July 1993.
(5) Kille, Steve, A String Representation of Distinguished Names.
RFC-1485. July 1993.
(6) CCITT. X.500 series of recommendations. 1988.
(7) Barker, Paul, Kille, Steve, The COSINE and Internet X.500
Schema. RFC-1274. November 1991.
[Huitema et alii] [Page 26]
Internet Draft SOLO December 1993
8. Authors' Addresses
Comments should be sent to:
Christian Huitema
INRIA
2004 Route des Lucioles
BP 93
06902 Sophia-Antipolis Cedex
France
Email: Christian.Huitema@sophia.inria.fr
Paul-Andre Pays
INRIA
BP105
78153 Le Chesnay Cedex
France
Email: Paul-Andre.Pays@faugeres.inria.fr
Alain Zahm, Ascan Woermann
TS-E3X Groupe France Telecom,
Les Algorithmes,
Route des Lucioles,
Bat. Pythagore A
06560 Valbonne France
Email: zahm@osi.e3x.fr, Woermann@osi.e3x.fr
Table of Contents
Status of this Memo .............................................. 1
Abstract ......................................................... 2
1 Presentation of the SOLO protocol: .............................. 2
1.1 A basic example: .............................................. 2
1.2 Name errors ................................................... 3
1.3 Partial name matches and redirections ......................... 5
1.4 Absolute matches: ............................................. 6
[Huitema et alii] [Page 27]
Internet Draft SOLO December 1993
1.5 Attributes and Universal Resource Locators (URL) .............. 6
1.6 Aliases and alternate values: ................................. 7
1.7 Filters and substrings: ....................................... 8
1.8 Limiting the size of the output: .............................. 9
2 Networking white page informations: ............................. 10
2.1 Using the index request: ...................................... 10
2.2 Signalling secondary servers .................................. 12
2.3 Relaying of queries ........................................... 13
2.4 Use of caches: ................................................ 14
2.5 Networking with other technologies: ........................... 15
2.6 Stacking multiple requests: ................................... 15
3 Protocol specification: ......................................... 15
3.1 The format of a request: ...................................... 15
3.2 The format of the replies: .................................... 17
3.3 Format of name specifications: ................................ 17
3.4 Format of attribute lists: .................................... 18
3.5 List of attribute values: ..................................... 18
3.6 Attribute names: .............................................. 19
3.7 Values: ....................................................... 20
4 A list of information codes: .................................... 20
4.1 System errors ................................................. 21
4.2 Name errors ................................................... 22
4.3 Intermediate informations ..................................... 22
4.4 User informations ............................................. 22
4.5 Completion reports ............................................ 23
5 Security considerations: ........................................ 23
5.1 Notification and removal ...................................... 23
5.2 Listing and browsing .......................................... 24
5.3 The name server attacks ....................................... 25
5.4 Logins and addresses .......................................... 25
6 Acknowledgments: ................................................ 25
7 References: ..................................................... 26
8 Authors' Addresses .............................................. 27
[Huitema et alii] [Page 28]