 |
|
|
|
|
|
|
// LinuxTag 2005
Besuchen Sie uns auch nächstes Jahr wieder auf dem LinuxTag 2005
im Karlsruher Messe- und Kongresszentrum. Für nähere Details und den
genauen Termin besuchen Sie bitte die LinuxTag Homepage.
|
|
|
|
|
|
|
|
EUROPAS GRÖSSTE GNU/LINUX MESSE UND KONFERENZ
KONFERENZ-DVD 2004 |
|
|
|
|
|
|
| Hauptseite // Vorträge // An introduction to OpenLDAP |
|
|
An introduction to OpenLDAPCopyright © 2004 by the Author(s)
Dieser Beitrag ist lizensiert unter der Creative Commons License.
Zusammenfassung
OpenLDAP is an Open Source implementation of the network protocol and object oriented database system called Lightweight Directory Access Protocol (LDAP). The importance of this IETF standard is continuing to increase and OpenLDAP proves to be a usefull and stable implementation.
The paper gives an introduction into the LDAP data model (attribute definitions, objectclass definitions, Directory Information Base, Directory Information Tree) and operational protocol (authentication operations, retrieval operations and data update operations). Thereafter an overview about the OpenLDAP implementation, its structure and features is given. The paper ends with examples of OpenLDAP deployment, namely white pages service, central authentication system and schema registry service. The latter example also introduces into the subjectspace "Metadata"
This paper is intended for anyone interested in the subject.
An introduction to OpenLDAP
LDAPv3 (Lightweight Directory Access Protocol) is an IETF [1]
Standard that has developed from X.500 , a standard of the International Telecommunication Union (ITU) [2]
for multi purpose directories. Originally LDAP was designed as a lightweight client protocol for accessing X.500 servers, using the TCP/IP protocol instead of the seven layered OSI stack. By now in its version 3, LDAP has evolved to a client server world, independent of X.500.
One of the main advantages of LDAP technology is its data model that easily allows to map „reality“, i.e. create information objects that are modelled according to the described entities and their properties. Other data base technologies like relational databases spread information about one entity into several locations (tables) for optimal computer processing (normalization), which in specific applications is the right strategy but on the other hand creates a lack of flexibility with respect to changing the data schema. If, like in LDAP, all information bits that belong together are stored in one place, it is much easier to change the schema, e.g. if you decide to store additional properties of the entities described in the data base. We can go as far as saying that it is not the technology but the way humans think which specifies the paradigm of the LDAP data model. Here we should keep in mind that directory data are not only meant to be accessed by humans but also by programs.
The X.500/LDAP data model is based on a simple elementary structure named attribute, which consists of an attribute type and an attribute value. The attribute type specifies the syntactical structure as well as the semantic contents of the attribute. The attribute type telephoneNumber, for example, specifies that the value may only contain digits and characters normally used in telephone numbers (syntax), and simultaneously its specification tells the user that the value is a telephone number, which, e.g., a computer can automatically dial. Attributes are displayed in a very simple fashion:
telephoneNumber= ++49 7071 1234567
Besides its syntax, an attribute type definition some more things: whether the attribute type may contain only one or multiple values, as well as so called Matching Rules, which specify the algorithms for value comparisons (e.g. caseIgnorString vs. caseExactString) for exact match, substring match and ordering.
As mentioned above the aim of the data model described here is to map entities of real life (what ever that may be) with processable information objects. This is done by grouping a number of attributes (remember: type/value pairs) to information objects, which are called entries. Which attributes are allowed to be used in an entry is specified by a so called object class, which is referenced in the entry in the form of an attribute with the type „objectclass“, for example:
objectclass=person
The value of the objectclass attribute refers to a class definition which among others specifies which attribute types are allowed (MAY attributes) and which are mandatory (MUST attributes) to be used in entries (instantiations of the object class). For example the definition of the object class person specifies that an entry modelled with this object class must be at least have one attribute of the attribute type commonName (cn) and one of the attribute type surName (sn). It also specifies that it additionally may contain attributes of the following attribute types: userPassword, telephoneNumber, seeAlso and description. An almost complete example of an entry description would be the following:
...
objectclass=person
cn=Max Example
cn=Maximilian Example
sn=Example
telephoneNumber= ++49 7071 1234567
An entry may contain more than one object classes, depending on the types of object classes used. Only one structural object class (e.g. person) which describes the main characteristics of the entry may be used (see section 1.1.4. for the whole truth), but as many auxiliary object classes as needed to add additional properties, e.g., labeledUriObject, if the entry contains pointers to home pages.
1.1.3. Naming and Directory Information Tree
The main thing that is missing in the last mentioned example is the name of the entry, i.e. the key for uniquely referencing it and thus making it retrievable. Such an entry name again is made from attributes. The so called Relative Distinguished Name (RDN) of an entry consists of one or more attribute type/value pairs that are contained in the entry. Thus the RDN of the above example entry could be:
cn=Max Example
In this case the attribute type cn is called the naming or distinguished attribute.
The LDAP naming model is depending on the way entries are organized in a hierarchical structure named Directory Information Tree (DIT). Entries are organized as nodes in this tree. One of the possible name spaces b is inherited from X.500 and was designed to create a world wide distributed white pages service which specifies as hierarchy levels of the DIT a country level, an organisation level and one or many levels for organisational units and as lowest level person entries. Figure 1 shows an example for a DIT with three country nodes (with naming attribute type countryName, c) for Germany, Sweden and The Netherlands, two organisations (naming attribute type organizationName, o) one of which contains two departments (organizationalUnitName, ou) and one person entry with the RDN made out of a commonName attribute (commonName, cn).
Figure : DIT Example
The term „relative“ in Relative Distinguished Name refers to the hierarchy level of the respective entry. The naming rule says that within the same hierarchy level (in this example all entries below the node ou=Department 2) the name has to be unique (distinguished from the other names). All RDNs of the entries on the path to the hypothetical root node (marked by the dashed arrows) together form the so called Distinguished Name (DN) of the entry. Thus the distinguished name of our example entry would be:
In the format called LDIF (LDAP Data Interchange Format), which is quite similar to the notation used in the above examples, the almost complete entry would look like this:
DN: cn=Max Example, ou=Department 2, o= Company X, c=DE
...
objectclass: person
cn: Max Example
cn: Maximilian Example
sn: Example
telephoneNumber: ++49 7071 1234567
Beware that the naming scheme used in these examples is one out of many possibilities. Another often used naming scheme is derived from the DNS and uses the attribute type domainComponant (dc) as naming attribute, with the advantage that these names are already registered and per se unique. Such a DN would, e.g., be:
uid=mexample, dc=Departm2, dc=comp-x, dc=de
Besides the idea of an object class that models an entry, another important feature of the object oriented paradigm is included in the X.500/LDAP data model, namely inheritance. There are three inheritance mechanisms specified in LDAP: class inheritance, attribute inheritance and value inheritance.
An object class is always specified as a subordinate of another object class and then inherits all features of the superior object class. Thus the structural object class organizationalPerson is subordinate to the structural object class person and inherits all MUST and MAY attributes of the latter. Actually every class has to have a superior class with the exception of so called abstract object classes that may not be instantiated by their own. The most important abstract object class is called top and only defines the attribute type object class as MUST attribute. For example the object class person is subordinate to top. An entry has to include all superiors of the one structural object class chosen for the main characteristic of the entry. In the above example the last missing bit is:
objectclass: top
Similar an attribute type may inherit all definitions from another attribute type. For example cn and o are both derived from the attribute type name and have the same syntax, etc. The main advantage of this inheritance mechanism is that, e.g., a search filter „(name=abc)“ will find the value abc in cn attributes as well as in ou attributes.
Other than the first two inheritance mechanisms, which set up their own inheritance hierarchy, the third mechanism, namely the value inheritance, builds on the hierarchy of the DIT. An attribute type can be specified as a so called collective attribute, which means that its value will be passed down into every entry of the subtree. Thus you can, e.g., specify a collective attribute type fax, include it into the organization entry with the value „1234567“, and every person entry below has a virtual attribute „fax=1234567“. This can ease data management very much .
1.2. The LDAP operational model
The LDAP network client server protocol includes all operations that are needed for database management. Since the protocol is session based, there are operations for establishment and closing of sessions, retrieval operations and update operations.
1.2.1. Session operations and authentication mechanisms
To open a client server session (often called connection) the bind operation is used. This operation is also used for authenticating the client or its user. Two authentication mechanisms are supported:
simple bind, a password authentication binding to an entry specified by its DN. Since the password is passed over the net unencrypted, this mechanism should only be used in combination with an encrypted session. LDAP supports the TLS session encryption as specified in . An anonymous bind is performed by a simple bind with zero length password (and DN).
SASL bind, using the dedicated standardized security layer called Simple Authentication and Security Layer , which itself supports a number of authentication mechanisms, including external (based on authentication on lower network levels) and GSSAPI , itself an abstraction layer for several mechanisms including Kerberos 5 , and X.509 strong authentication.
With these possibilities all security levels needed for directory services can be accomplished.
To end an LDAP session the operations unbind or abandon are used. The latter tells the server to forget any outstanding searches etc.
1.2.2. Retrieval operations
Directories are designed for few updates but many reads. Retrieval therefore is the most used operation. Although LDAP defines two retrieval operations, namely compare and search, only the latter is used, since it includes all the functionality of the compare operation.
The search operation includes a number of parameters that make it a very universal tool:
base object, the name (DN) of an entry below which the search is to be performed
scope, specifying whether the whole subtree (sub) below the base object is to be searched, or only one level below it (one), or whether only the base object entry itself is to be searched (base)
dereference alias, whether to follow so called alias entries that point to an entry somewhere else in the DIT (never, in subordinates of the base object, only in the base object, always)
size limit, a restriction of the number of entries the server shall give back to the client
time limit, restricting the amount of time (in seconds) the server shall take for performing the search
types only, specifying whether attribute values shall be returned, or only the attribute types
filter, the specification of what to search for. A filter can be as complex as needed, allowing AND, OR and NOT combinations, as well as equality, substring match, approximate match, greaterOrEqual and lessOrEqual, mere presence.
Attributes, specifying which attribute types of the entries found shall be returned by the server.
For managing the data, the following operations are specified in LDAP:
add for adding new entries
delete for deleting existing entries
modify for changing the contents of an entry
modifyDN for changing the name and simultaneously the location of the entry in the DIT
1.3. Extensibility of LDAP
Both the data model and the operational model of LDAP are extensible.
1.3.1. Extensibility of the data model
Besides some standardized schema (i.e. object classes, attribute types, attribute syntaxes, matching rules, etc.), LDAP administrators can specify their own schema. Only if interoperability with other LDAP applications is needed, the used schema has to be either standardized (e.g. through the IETF process) or registered (in a schema registry). Besides this openness towards new schema, the schema definitions themselves are also conceived extensible.
1.3.2. Extensibility of the operational model
Besides the above mentioned operations standardized in LDAP, new operations, so called extended operations, may be specified as well as existing operations enhanced by so called controls. A number of such controls and extended operations have been specified in IETF RFCs and implemented in different LDAP implementations, e.g. for digitally signed operations and for server side sorting of search results.
The first open source implementation of the LDAP standard (Version 2 in those days) [3]
was done at the University of Michigan [4]
by Tim Howes and his colleagues as a client protocol for accessing X.500 servers. Actually the first development works started way before any LDAP standardization in 1991. The last LDAP version provided by Michigan was 3.3 from April 1996. After some patch aggregations done by the small company Netboolan (set up by Kurt Zeilenga), the OpenLDAP Foundation and Project was founded in August 1998 with Kurt as its chief architect. OpenLDAP v.2.0, the first open source implementation of LDAP v3, was released in 2000. One year later Kurt was hired by IBM, OpenLDAP development still being his main activity. The current OpenLDAP version is 2.2.11, the last version marked as stable is 2.1.30.
Kurt as well as others involved in OpenLDAP work are well connected with the LDAP related working groups of the IETF and thus OpenLDAP implements very early newly standardized features.
OpenLDAP is often used in production level services in the commercial realm as well as in higher education organizations. It has proven to be stable, reliable and relatively performant. Some performance figures in relation to commercial LDAP implementations can be found in and .
2.1. Overview of the software package
2.1.1. The single software parts
Currently the OpenLDAP suite consists of:
The LDAP server called Slapd (Stand alone LDAP Daemon)
The LDAP replication server called Slurpd (Stand alone Update and replication Daemon)
The LDAP Library for Client development in C, an API that is based on an IETF Draft that never made it to an RFC . It nevertheless can be seen as a quasi standard, since other implementations of this API exist, e.g. from Netscape.
Additionally the OpenLDAP project provides:
JLDAP, LDAP class libraries for Java contributed by Novell
JDBC-LDAP, a JAVA JDBC – LDAP bridge driver contributed by Octet String.
The following will only deal with the first three items.
2.1.2. Prerequisites, installation and configuration
Since as already mentioned, LDAP is based on several other standards, like SASL and TLS, OpenLDAP needs respective software packages if such features shall be enabled. Additionally, several data base back-ends can be used in OpenLDAP, the default being Berkeley DB 4. We advise to have the following software packages installed to be able to use all important OpenLDAP features:
These are the newest versions currently available. You can use older versions of some of these packages, e.g. if they are included in your Linux/BSD operating system. But you should be aware of the fact that sometimes critical security bugs might still be included in these older versions.
OpenLDAP itself can be downloaded from
http://www.openldap.org/software/download
as a gzipped tar file, that can be untared by:
tar -xzf <filename>
With all those packages preinstalled, the OpenLDAP software can be configured with the following configure options:
./configure --prefix=<installation path> --with-cyrus-sasl \
--with-tls
To make sure that the preinstalled software is found, you can include the respective paths in the environment variables LDFLAGS and CPPFLAGS used by the compiler gcc, e.g.:
LDFLAGS=“-L/usr/local/openssl/lib“
CPPFLAGS=“-I/Usr/local/openssl/include“
Other recommended Configure options are:
--enable-slapd --enable-slurpd --enable-syslog --enable-local \
--enable-aci --enable-crypt --enable-rlookups \
--enable-referrals --enable-spasswd --enable-shared \
--enable-dynamic
Additionally you can enable as many data back-ends, as you might need (see below) and other features not mentioned here. For a complete reference type
./configure --help
If configure didn't complain running with your configure options, the compilation and installation of the software is done by successively running the following make commands (the latter of which should be performed as root):
make depend
make
make test
make install
2.2. Structure of Slapd and its back-end concept
Slapd is a well structured software. The C-code reflects this structure by being divided in several C files, each providing specific functionality. The overall structure is three layered:
An LDAP front-end that actually speaks the LDAP protocol towards the clients. comes with a big variety of database back-ends which can even be run in parallel.
The main part, providing schema initiation, configuration, access control, etc.
One or several back-ends that provide the database to store the data. Every operation of the LDAP protocol has its counterpart in the back-end communication.
In the Version 2.2.X OpenLDAP additionally includes a plugin interface, which allows you to plugin additional code to the slapd without having to edit the slapd-c-code and recompile the whole software. This tremendously enhances the flexibility of Slapd. There are actually two plugin interfaces, one performing before the actual operations in the back-end and one after those operations. In the case of the search operation there is an additional possibility to perform a rewrite of the search filter.
To be able to specify multiple database back-ends means that a single slapd server can respond to requests for many logically different subtrees using either the same or different back-end technologies. Some of the more important back-ends include:
bdb
, using Sleepycat Berkeley DB 4, a high performance transactional data base
ldbm
, a lightweight DBM type back-end that either uses GDBM or Berkeley DB as actual database technology.
hdb
, a hierarchical data base back-end, derived from BDB, which is much more performant in write operations and thus is recommended, if the data often change.
shell
,
perl
and
tcl
providing arbitrary interfaces to theses scripting languages
sql
, a general SQL interface for including a RDBM as back-end. This back-end is still to be seen as experimental.
ldap
, providing an ldap-proxy that can be set up nearer to the clients than the actual ldap server itself. Besides the cashing functionality, this back-end provides translation capabilities, so, e.g. servers with different schema than expected by the clients can be integrated by having the ldap-proxy translate between the different attribute types etc. Such translations can also be done with respect to naming schemes.
meta
is similar to the
ldap
back-end but works with more than one server and thus is a proxy to multiple servers. The translation features are based on regular expressions that can be specified in a configuration file, which can sometimes consume a lot of performance.
Unfortunately there is no standardization of LDAP access control. Thus every implementation provides their own mechanisms for controlling the access to the data. Basically there are two different approaches to this problem: Either store the access control information in the configuration file or in the actual data in the DIT. The latter approach has the advantage that you can configure new access rules without having to restart the daemon. Nevertheless, the first approach was chosen in the Umich/OpenLDAP implementation. It is planned though to include on the fly reloadable configurations by a config-back-end in version 2.3., which is either based on LDIF files or even better on corresponding data in the directory.
By now only access control defined in the slapd configuration file works, but it does provide a very fine granular and flexible access control.
The general access rule definition is:
access to <what> [by <who> <access> <control>]+
<what> can be a number of things, so you can exactly specify what you want to impose an access rule on:
„*“ means all entries of the server.
„dn.exact=“ or „dn.regex=“: A specific DN or regular expression matching a number of DNs
„dn.sub=“, „dn.one=“, „dn.base=“: A specific subtree marked by a DN and its scope (sub, one, base)
An LDAP filter specifying a number of entries
A list of attributes
<who> again can be specified in various ways:
„*“ means everybody
„anonymous“ means everyone who performed an anonymous bind
„users“, every authenticated users
„self“ the user authenticated as the target entry
„dn.exact=“ or „dn.regex=“: A specific DN or regular expression matching a number of user DNs
„dn.sub=“, „dn.one=“, „dn.base=“: A specific subtree of users marked by a DN and the scope (sub, one, base)
A user specified by a DN attribute in the entry itself
„group.“... specifying an LDAP group and only members of that group gain access. This works with „.exact“ as well as with „.regexp“
The same works with peername (IP adress), socketname (named file pipe), domain (hostname) and socketurl (URL)
<access> specifies either the general kinds of access, namely „none“, „auth“ needed to bind, „compare“, „search“, „read“ and „write“ or additive accesses marked by „0“, „x“, „c“, „s“, „r“, and „w“ respectively, prefixed by either „=“ for setting the access to exactly this level, „-“ for removing this level or „+“ for adding it.
The single access control statements are being processed one after the other and the basic rule is that as soon as one rule matches, the following rules will not be considered anymore. This behaviour can be altered by the <control> bit of the rule, which may contain one of the following three statements:
„stop“, the default behaviour, stopping to evaluate further directives
„continue“ for continuing to evaluate later directives allowing for other <who> clauses
„break“ for continuing to evaluate later directives allowing for other <access> clauses
The major problem with this kind of access control is its complexity, which may cause misconfiguration. Always keep in mind that the order of the access rules is important and that one should try to keep the access rules as simple as possible.
2.4. Replication mechanisms
Replication is the other important feature of LDAP, which has not yet been standardized. Thus again it is implementation specific. OpenLDAP provides two different mechanisms, the slurpd as push replication and LDAP Synchronization as pull or push replication.
2.4.1. Slurpd replication
Already the University of Michigan LDAP implementation contained a push replication based on the Slurpd replication daemon. The master LDAP server in such a replication mechanism logs all changes to the data in a so called replication log file, which has a format similar to LDIF but is enhanced with a replica statement and a time stamp. This file is continuously read by the slurpd daemon, which then performs the changes via normal LDAP operations, i.e. pushes into the slave servers named in the replica statement (see figure 2).
Figure : Slurpd Replication
2.4.2. Replication with LDAP Synchronization
The second replication mechanism implemented in OpenLDAP 2.2.x is specified in . The operation described in this Internet Draft allows a client or slave server to maintain a copy of a fragment of directory information tree of the master. It supports both polling for changes (pull) and listening for changes (push). The operation is defined as an extension of the LDAP Search Operation.
By now this second replication mechanism has to be seen as experimental and shouldn't yet be deployed in production services. Nevertheless it provides a more flexible replication mechanism than slurpd.
3. OpenLDAP deployment examples
There are numerous applications of LDAP. Every time a human or a program needs structured information from the net it could be the technology of choice since the database is directly connected to the net via a dedicated network protocol. The most important operating systems have implemented a directory as basis for their user and resource management. Starting from the old Novel Network operating system (NDS), nowadays you have such LDAP enabled directories in Windows 2000/2003, in Solaris, in different distributions of Linux, etc. Just as examples of LDAP applications three scenarios will be briefly outlined in the following sections. All three examples have been implemented with OpenLDAP software by the author.
Already in X.500 times, directories were conceived to be used as White pages and Yellow Pages information systems. Actually all schema needed for these applications was standardized together with the protocols. Until today, this is the most common usage, and Clients like the Netscape browser or MS Outlook are able to retrieve contact information of persons via an LDAP interface.
One advantage of LDAP technology is that different applications may use the same data. For instance a university can set up a White Pages service that displays contact information of all members of the university. The DIT is well structured according to the several organizational Units (faculties and single Institutes) and the person entries are sorted under the ou-entry to which the person belongs. With such a database it is possible to provide several services, e.g. an electronic telephone book and an Email-address directory just by setting up two Web-to-LDAP-Gateways that search for the respective attribute types.
If such an university now decides to set up an electronic university calendar, it can use that data base and enhance it with additional entries modelled by additional object classes to store the information of the single courses. Since the professors, lecturers, etc. are already included in the DIT, the course information only needs to include pointers to the respective person entries.
3.2. Central authentication system
In today's computer environment of larger organisations a user is often able to work on a large number of computers in the network, e.g. on her own PC, on the work station of her working group, on dedicated servers for number crunching for complex text processing, etc. In order to get access, the user has to remember a different password on each of these computers, and the system administrator has to manage the accounts of all users on all computers. Central authentication systems like NIS solved this problem by providing one user database and having this data base used for the login processes on the single computers. NIS not only thus replaces the Unix files /etc/passwd, but also a number of other files in /etc, like /etc/hosts and /etc/services. Unfortunately there are a number of security issues with NIS.
Figure : Abstraction layers in Unix login processes
Here LDAP comes into the scene by providing a very secure store for the user information. Specifies an LDAP schema for all the information NIS can provide (e.g. users, hosts, services, etc.). By using the abstraction layer NSS (Named Service Switches) most Unix flavours can integrate the LDAP protocol in the login process without having to change the C-libraries. Applications can access the user and password information stored in the LDAP server via another Software layer called Pluggable Authentication Modules (PAM). Figure 3 shows how these abstraction layers are integrated in modern Unix systems.
3.3. Schema registry service
As already stated above, schema is a vital factor for interoperability of LDAP applications. Thus a lot of schema has been standardized through the IETF process within several LDAP related working groups. Since more and more schema for new directory applications is being specified and since currently no LDAP related IETF working group is willing to standardize such schema, other mechanisms for disseminating useful LDAP schema had to be found. The IETF itself conceived a schema listing service in a number of expired Internet drafts (from 1998). Based on these drafts, a project funded by TERENA [5]
and a number of European National Research networks [6]
set up a schema registry with OpenLDAP software [7]
had been set up that provides a flexible Web interface for users as well as an LDAP interface for applications that need information about schema. All IETF standardised schema had been included in the proof of concept service. In a next project phase the service will be transformed to a reliable production service and additional schema will be included within a discussion process of participating experts.
The registry does not only include LDAP schema and data about that schema, but it also includes data about the specification documents, in the case of the IETF the so called Requests For Comments (RFC). If one conceives a text as data, such data about texts, like author name, date of publication, title, keywords, etc. are called metadata, basically data about data. Librarians since a long time are discussing different metadata formats for their books and other resources. For interoperability it was vital to find a format that could be used by all metadata creators. It seems that the Dublin Core Metadata Element Set (DCMES) of 16 elements has crystallised to be such a lingua franca for all libraries, archives, etc. It is conceived as „cross-domain information resource description“, where information resource is defined to be "anything that has identity". This metadata set was used for describing the texts in the schema registry. The following LDAP attributes had been defined for this purpose:
dcTitle $ dcCreator $ dcCreatorPointer $ dcSubject $ dcDescription $ dcPublisher $ dcPublisherPointer $ dcContributor $ dcContributorPointer $ dcDate $ dcType $ dcFormat $ dcIdentifier $ dcSource $ dcLanguage $ dcRelation $ dcCoverage $ dcRights $ dcAudience
The redundant attributes like dcCreator and dcCreatorPointer were included to have the possibility to just point to a person entry which contains data about the respective creator, publisher and contributor.
DCMES allows for so called qualifiers, that either refine an element (e.g. dcTitle.alternative) or provide encoding information (e.g. dcSubject.DDC, to indicate that the subjects are taken from the Dewey Decimal Classification scheme). This additional information should be deletable again for interoperability, without loosing any vital information, e.g. if the data sets are aggregated in an index.
LDAP provides several mechanisms that could support DC qualifiers:
Due to missing standards, the Schema Registry chose to use the attribute inheritance mechanism. Currently there are attempts to implement the description options for the encoding qualifiers.
|
|
|
