As per Relevance of the word followed, we have this rfc below:
Network Working Group T.
Request for Comments: 1249 M.
B.
University of
August 1991
DIXIE Protocol
Status of this
This RFC defines a mechanism by which TCP/UDP based clients
access OSI Directory Service without the overhead of the
transport and presentation protocols required to implement full-
DAP. This memo provides information for the Internet community.
does not specify any standard. Distribution of this memo
unlimited
Table of
1. Introduction .............................................. 2
1.1 History .................................................. 2
2. Protocol .................................................. 2
2.1 Header ................................................... 3
2.2 Operations ............................................... 4
2.2.1 Read ................................................... 4
2.2.1.1 Read Request ......................................... 4
2.2.1.2 Read Reply ........................................... 4
2.2.2 Search ................................................. 5
2.2.2.1 Search Request ....................................... 5
2.2.2.2 Search Reply ......................................... 5
2.2.3 List ................................................... 5
2.2.3.1 List Request ......................................... 5
2.2.3.2 List Reply ........................................... 5
2.2.4 Modify ................................................. 5
2.2.4.1 Modify Request ....................................... 6
2.2.4.2 Modify Reply ......................................... 6
2.2.5 Modify RDN ............................................. 6
2.2.5.1 Modify RDN Request ................................... 6
2.2.5.2 Modify RDN Reply ..................................... 6
2.2.6 Add .................................................... 6
2.2.6.1 Add Request .......................................... 7
2.2.6.2 Add Reply ............................................ 7
2.2.7 Remove ................................................. 7
2.2.7.1 Remove Request ....................................... 7
2.2.7.2 Remove Reply ......................................... 7
2.2.8 Bind ................................................... 7
2.2.8.1 Bind Request ......................................... 7
Howes, Smith, & Beecher [Page 1]
RFC 1249 DIXIE August 1991
2.2.8.2 Bind Reply ........................................... 8
2.3 Operation Code Summary ................................... 8
2.4 Return Code Summary ...................................... 8
3. References ................................................ 9
4. Available Implementations ................................. 9
5. Security Considerations.................................... 9
6. Authors' Addresses ........................................ 10
1.
OSI Directory Service defines a powerful mechanism for storing
retrieving information about objects, and for arranging those
in a hierarchical structure. Many types of objects and
can be stored in The Directory, including white pages information
application information, service information, etc. The OSI
defined to allow access to this information is the Directory
Protocol (DAP). The DAP, being an OSI application-layer program,
fairly heavy-weight and requires a substantial amount of
power and coding investment to implement
The DIXIE protocol is designed for use by smaller hosts (e.g.,
Macintoshes and PCs) that do not have the computing power
necessary software to implement a full OSI protocol stack. The
protocol is also useful for any Internet application that wants
simple interface to X.500 that requires very little
investment
The basic idea behind DIXIE is the same as that described in RFC 1202
for the Directory Assistance Protocol. DIXIE offers both UDP and
access to The Directory. While the Directory Assistance
exports something of a user interface, DIXIE provides a more
protocol translation
1.1
The DIXIE protocol has evolved over time, slowly growing into
protocol described by this document. Without an understanding of
circumstances surrounding this evolution, the wisdom of some of
DIXIE design decisions may not be apparent
2.
This section describes the DIXIE protocol in detail. DIXIE follows
client-server request and response paradigm. Clients send
packets to a DIXIE server, and the server sends reply packets
return. Communication may be over UDP or TCP, depending upon
needs of the client. All modification operations (ADD, REMOVE
MODIFY, MODIFYRDN) must be performed over a TCP connection,
Howes, Smith, & Beecher [Page 2]
RFC 1249 DIXIE August 1991
provides some level of authentication
Whichever method of communication is used, the general packet
is the same. Each packet consists of a sixteen octet header
by some data. The format of the header and data for each kind
request is described below
The representation used for all X.500 data passed between the
and the client is the QUIPU EDB format. So, for example,
Distinguished Name might look something like "c=US@o=University
Michigan". For a complete description of this format, see volume 5
of the ISODE Manual
The DIXIE server listens on port 96 for both UDP packets and
connections
2.1
The DIXIE packet header is sixteen octets long. For requests,
header is described by the following
Start Length
0 1 An opcode specifying one of the
described below. (see section 2.3 for a summary
1 2 A request identifier to be included in the reply
This number should be unique to a request
3 4 The total length of the request packet,
the header
7 2 Unused
9 1 Options. Currently, there are only three options
If bit 0 is set, "large" attributes will
included in the response. The choice of
constitutes large is up to the implementation
If bit 1 is set, the dereference aliases
control will be set for the X.500 operation.
bit 2 is set, aliases will NOT be dereferenced
searched during a search operation
10 1 Protocol version. The current version is 1.
11 1 For the search operation, this byte specifies
scope of the search. (see section 2.2.2.1)
12 2 Timelimit in seconds for the operation
14 2 Sizelimit for the operation (search and list).
Howes, Smith, & Beecher [Page 3]
RFC 1249 DIXIE August 1991
For replies, the header is described by the following
Start Length
0 1 A return code specifying either success
describing any error that occurred. (
section 2.4 for a description of each code
1 2 The identifier included in the
request packet
3 4 The total length of the response packet,
the header
7 3 Unused
10 1 Protocol version. The current version is 1.
11 5 Unused
All unused fields should be set to null octets and are reserved
future expansion
2.2
This section describes the DIXIE operations, which closely
the X.500 DAP operations
2.2.1
The DIXIE read operation corresponds to an X.500 DAP READ operation
2.2.1.1 Read
The header opcode should be set to 0x01. The data portion of
packet consists of the DN of the entry to read, a null octet,
then a null-octet separated list of attributes whose values are to
returned from the read. If no attributes to return are listed,
attributes are returned. The packet is terminated by two null
in a row
2.2.1.2 Read
The reply data for the read operation consists of the entry read
followed by a null octet. An entry consists of the DN of the entry
followed by the octet 0x02, followed by a 0x02-octet separated
of attribute values. An attribute value consists of an
type, followed by the octet 0x01, followed by a 0x01-octet
list of values. Each attribute type, attribute value
distinguished name has the form defined by the QUIPU EDB format
Howes, Smith, & Beecher [Page 4]
RFC 1249 DIXIE August 1991
2.2.2
The DIXIE search operation corresponds to an X.500 DAP
operation
2.2.2.1 Search
The header opcode should be set to 0x0f. Octet 11 in the
should be set to 0x01, 0x02, or 0x03, for a search scope of
object, one level, or whole subtree, respectively. The data
of the packet consists of the DN of the entry from which to start
search, a null octet, a string containing the search filter (dish
style), a null-octet, and then a null-octet separated list
attributes whose values are to be returned from the search. If
attributes to return are listed, all attributes are returned.
packet is terminated by two null octets in a row
2.2.2.2 Search
The reply data to the search operation consists of two octets
network byte order specifying the number of matches returned.
comes this number of sequences of the form: one 0x03 octet
by one entry. Each entry is as described above in section 2.2.1.2.
2.2.3
The DIXIE list operation corresponds to an X.500 DAP LIST operation
2.2.3.1 List
The header opcode should be set to 0x10. The data portion of
packet consists of the DN of the entry on which to perform the list
followed by a null octet
2.2.3.2 List
The reply data to the list operation consists of two octets
network byte order specifying the number of subordinates returned
followed by this number of sequences of the form: one 0x03
followed by a Relative Distinguished Name of a subordinate
2.2.4
The DIXIE modify operation corresponds to an X.500 DAP
operation
Howes, Smith, & Beecher [Page 5]
RFC 1249 DIXIE August 1991
2.2.4.1 Modify
The header opcode should be set to 0x02. The data portion of
packet consists of the DN of the entry to modify, followed by a
octet, followed by a null-separated list of modify operations
perform. Each modify operation is one of the following
type remove attribute
type=value make value the sole value for attribute
type+=value add value to attribute
type-=value remove value from attribute
The second form will see to it that existing values (if any)
deleted before the new ones are added. The third form will add
attribute type if it does not already exist. Note that the QUIPU
format, used to specify value, allows multiple values to be
separated by the "&" character. This operation is only allowed
TCP
2.2.4.2 Modify
There is no reply data for the modify operation. The only
of success or failure is the return code in the header
2.2.5 Modify
The DIXIE modify RDN operation corresponds to an X.500 DAP
operation
2.2.5.1 Modify RDN
The header opcode should be set to 0x13. The data portion of
packet consists of the DN of the entry to modify, followed by a
octet, followed by the new RDN the entry should have, followed by
final null octet. The old value of the RDN is never kept as
attribute of the entry. This operation is only allowed over TCP
2.2.5.2 Modify RDN
There is no reply data to the modify RDN operation. The
indication of success or failure is the return code in the header
2.2.6
The DIXIE add operation corresponds to an X.500 DAP ADD operation
Howes, Smith, & Beecher [Page 6]
RFC 1249 DIXIE August 1991
2.2.6.1 Add
The header opcode should be set to 0x11. The data portion of
packet consists of the DN of the entry to add, followed by a
octet, followed by a null-separated list of the entry's attributes
Each attribute in this list has the form
type=
where value can consist of a single value, or multiple
separated by the "&" character. The request is terminated by
null octets in a row. This operation is only allowed over TCP
2.2.6.2 Add
There is no reply data to the add operation. The only indication
success or failure is the return code in the header
2.2.7
The DIXIE remove operation corresponds to an X.500 DAP
operation
2.2.7.1 Remove
The header opcode should be set to 0x12. The data portion of
packet consists of the DN of the entry to remove, followed by a
octet. This operation is only allowed over TCP
2.2.7.2 Remove
There is no reply data for the remove operation. The only
of success or failure is the return code in the header
2.2.8
The DIXIE bind operation corresponds to an X.500 DAP BIND
using simple authentication as defined in Recommendation X.509.
2.2.8.1 Bind
The header opcode should be set to 0x04. The data portion of
packet consists of the DN of the entry as which to bind, followed
a null octet, followed by the password of the entry as which to bind
followed by a final null octet. A null DN corresponds causes a
as NULLDN to occur
Howes, Smith, & Beecher [Page 7]
RFC 1249 DIXIE August 1991
2.2.8.2 Bind
The format of the bind reply packet depends on whether the
was invoked over TCP or UDP. If the operation was invoked over TCP
there is no reply data. Success or failure of the operation
indicated by the return code in the packet header
If the bind operation was invoked over UDP, the data portion of
reply packet consists of an Internet address in standard
notation, followed by a 0x01 octet, followed by a decimal number (
text form), followed by a null octet. The address and number
be taken to be the IP address and port number to which the
should connect to obtain an authenticated TCP connection, bound
the entity specified in the request packet
2.3 Operation Code
This section describes the possible values for the DIXIE
operation code. There are currently 8 possible values
0x01
0x02
0x04
0x0f
0x10
0x11
0x12
0x13 Modify
2.4 Return Code
This section describes the possible values for the the DIXIE
return code. There are currently 17 possible values
0x01 The request was successful
0x02 The search did not find any matches
0x03 Some unknown, generic DIXIE error has occurred
0x04 The DIXIE opcode was not recognized by the DIXIE server
0x05 Insufficient access to perform a modification
0x06 A malformed DN was supplied
0x07 Some time limit or size limit was reached
Partial results will be returned
0x08 A modify was attempted before a bind
0x09 A fragment requested was not found
0x0a An attribute type specified is invalid
0x0b An attribute specified does not exist in the entry
0x0c An attribute value specification is invalid
0x0d An attribute value does not exist (as for removal of
Howes, Smith, & Beecher [Page 8]
RFC 1249 DIXIE August 1991
value).
0x0e A modification of an entry's RDN was attempted via a
operation. This is not allowed (use modrdn instead).
0x0f A supplied DN references an invalid portion of the tree
0x10 The DSA has passed back a referral to another DSA (as for
modification to a non-local entry), and the DIXIE server
unable to follow it
0x11 The DSA is down or unreachable
3.
[1] Information Processing - Open Systems Interconnection -
Directory, International Organization for Standardization
International Standard 9594, 1988.
[2] Kille, S., Robbins, C., Roe, M., and A. Turland, "The
Development Environment: User's Manual", Volume 5: QUIPU
Performance Systems International, January 1990.
[3] Rose, M., "Directory Assistance Service", RFC 1202,
Systems International, February 1991.
4. Available
This section is not meant as an endorsement of
implementation, it is provided merely as information for
Internet community. A full Un*x-based implementation of
DIXIE protocol in the form of a DIXIE server and
application library is freely available for anonymous FTP
the host terminator.cc.umich.edu in the ~ftp/x500 directory
Un*x and Macintosh clients that use the DIXIE protocol have
been implemented and are available from the same location
There is also a discussion list for DIXIE-related topics
dixie@terminator.cc.umich.edu. To join, send mail to dixie
request@terminator.cc.umich.edu
5. Security
Security issues are not discussed in this memo
Howes, Smith, & Beecher [Page 9]
RFC 1249 DIXIE August 1991
6. Authors'
Tim
University of
Information Technology
535 West William St
Ann Arbor, MI 48103-4943
Phone: +1 313 764-2278
EMail: tim@umich.
Mark
University of
Information Technology
535 West William St
Ann Arbor, MI 48103-4943
Phone: +1 313 764-2277
EMail: mcs@umich.
Bryan
University of
Information Technology
535 West William St
Ann Arbor, MI 48103-4943
Phone: +1 313 764-4050
EMail: bryan@umich.
Howes, Smith, & Beecher [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
