Z39.50 Maintenance Agency Procedures

Updated: January 6, 1999
The Library of Congress is designated as Maintenance Agency and Registration Authority for ANSI/NISO Standard Z39.50 and ISO 23950.

As Maintenance Agency, formal responsibilities include development and processing of, and provision of access to:

As Registration Authority, formal responsibilities include maintenance of:

And in addition, informal responsibilities include development and processing of, and provision of access to:


Defect Reports

These procedures last updated May 1998
The Maintenance Agency provides access to Z39.50 Defect Reports. A defect report describes: Any Z39.50 user, implementor or interested party may bring a defect to the attention of the Maintenance Agency, which prepares a defect report.

There are three types of Defect Reports:

Procedures for handling Editorial and Technical Defects

When notified of an editorial or technical defect the Maintenance Agency prepares a Defect Report, noting the nature of the defect and the solution proposed and lists the completed draft Defect Report on the Z39.50 Maintenance Agency page. The report is initially assigned a status of 'pending ZIG review'; it is subject to comment and discussion via email (over the ZIG list) and may be revised as a result, and it is ultimately proposed at a ZIG meeting, for ZIG endorsement. If the ZIG endorses the report, then the report is assigned a status of 'endorsed by ZIG'. If not, the report will be either withdrawn, or re-drafted (with status 'still pending ZIG review') for further discussion via email and presented again at a future ZIG meeting. The Maintenance Agency determines whether or not the ZIG endorses the report.

Following ZIG endorsement, the defect report is submitted to ISO/TC46/SC4, and assigned a status of 'pending ISO approval'. Defect reports approved by ISO are assigned a status of 'Approved by ISO'.

Approved defect reports are maintained on the Maintenance Agency page until incorporated into the standard. At the time of the revision of the standard, the Maintenance Agency will apply all ISO approved Defect Reports to the new edition of the standard.

Procedures for handling Clerical Defects

When notified of a clerical defect the Maintenance Agency prepares a draft Defect Report, and lists it on the Z39.50 Maintenance Agency page. Clerical reports do not undergo an approval process. When a new publication of the standard is developed, clerical errors indicated by the Clerical reports will be corrected.

Format of Defect Report

A Defect Report, maintained by the Z39.50 Maintenance Agency, consists of the following elements:
  1. Report Number (s)
    Initially, a Z39.50 Maintenance Agency Defect Report Number assigned by the Maintenance Agency. Subsequently, if the report is submitted to ISO, the TC46/SC4 Defect Report Number assigned by SC4 is also indicated.
  2. Source of Report
    Initially, the person and/or organization who originated the report. Subsequently, if the report is submitted to ISO, the "Z39.50 Maintenance Agency" is indicated as the "source" (and the origination information is retained).
  3. Submitted-to and Date
    Initially, a date assigned by the Z39.50 Maintenance Agency. Subsequently, if the report is assigned to ISO, then "Submitted to ISO TC46/SC4 <date>" is also indicated.
  4. Report Concerning
    This indicates ISO 23950, and the affected services, etc.
  5. Type of Defect
    Technical, editorial, or clerical.
  6. Reference in Document
    Page number, clause, etc.
  7. Nature of Defect
    Initially, the defect is summarized by the Maintenance Agency. The summary may be revised as a result of discussion within the ZIG, prior to submission of the defect report to ISO.
  8. Solution Proposed by Source
    Initially, a proposed solution is developed by the Maintenance Agency. The proposed solution may change as a result of discussion within the ZIG, prior to submission of the defect report to ISO.
  9. Status/Secretariat's Response
    e.g., Pending ZIG endorsement; endorsed by ZIG/submitted to ISO; Approved by ISO TC46/SC4, Approved by ISO (final).

Amendments

These procedures last updated May 1998
The Maintenance Agency provides access to Z39.50 Amendments. An amendment alters and/or adds to the previously agreed technical provisions in the existing edition of the standard.

Any Z39.50 user, implementor or interested party may propose an amendment to the Maintenance Agency.

Amendment Procedures

The Maintenance Agency works with the proposer and with the ZIG to develop the proposal, which is posted on the Maintenance Agency page.

The proposed amendment is initially assigned a status of 'pending ZIG review' and is subject to comment and discussion via email (over the ZIG list). The proposal may be revised as a result of discussion, and a new proposal prepared, for discussion at a ZIG meeting. If the ZIG endorses the proposal, then it is assigned a status of 'endorsed by ZIG'. If not, the proposal is either withdrawn, or re-drafted (with status 'still pending ZIG review') for further discussion via email and presented again at a future ZIG meeting. The Maintenance Agency determines whether or not the ZIG endorses the proposal. All endorsed amendments are listed on the Maintenance Agency page.

At the time of subsequent revision of the standard, the Maintenance Agency will apply all endorsed amendments to the new edition of the standard. Thus amendments not submitted individually to ISO for approval, rather, they are approved (or dis-approved) by result of the approval process for the new version of the standard.

However, these procedures will be revised to provide for review and approval by ISO of individual amendments, if the Z39.50 community feels there is such a need.


Clarifications

These procedures last updated May 1998
The Z39.50 Maintenance Agency provides access to Clarifications -- summaries of discussions of questions concerning aspects of the Z39.50 standards which are viewed as ambiguous or require interpretation.

A question or issue requiring clarification or interpretation may be raised at ZIG meetings or over the ZIG list. The Maintenance Agency prepares a Clarification Report to be reviewed at the next ZIG meeting. The Clarification Report includes the name of the implementor who raised the issue, the date, a synopsis of the issue, a provisional response, and a status.

Each Clarification Report is initially assigned a status of 'pending'. At the ZIG meeting when the report is reviewed, if it is endorsed by the ZIG, it is subsequently assigned a status of 'approved'. If not, it is either withdrawn, or assigned a status of 'still pending', and subsequently revised and scheduled for review at a subsequent meeting. The Z39.50 Maintenance Agency determines whether or not the ZIG endorses the report.


Profiles

These procedures last updated May 1998
The Z39.50 Maintenance Agency maintains a Profile Page providing a list of Z39.50 Profiles.

Any implementor group, standards committee, or other body who develops a Z39.50 profile (hereafter, profile-developer) may request that the Maintenance Agency list the profile on the Profile page. The name of the profile and the profile developer is listed, with a link to the text of the profile, the date associated with the text, and a brief (one-line) description, provided by the profile-developer.

Status associated with the profile is not listed explicitly; profile-developers have various procedures for approving profiles, and the Maintenance Agency does not track the approval process. The profile-developer may maintain its own profile page or may reflect the status of a profile within the text of the profile (the name of the profile may implicitly reflect draft status).

A profile-developer may request one or more object identifiers (OIDs) corresponding to a profile, for purposes of negotiation. Normally neither the Maintenance Agency nor the ZIG becomes involved in the approval process for a profile. However, a profile-developer may request that the ZIG endorse a profile, in cases where the approval process for the profile requires or recommends ZIG endorsement. The profile-developer may request ZIG endorsement via the Maintenance Agency, who then coordinates the ZIG-endorsement process. The Maintenance Agency requests (via the ZIG list) ZIG-review of the profile and comment, and schedules discussion for the next ZIG meeting. The result of that discussion may be:

  1. the ZIG might endorse the profile;
  2. the ZIG might stipulate endorsement if specific changes are made;
  3. the ZIG may decline to endorse the profile, suggesting areas that need to be re-worked; or
  4. the ZIG may simply decline to endorse the profile.
In cases (2) and (3) the Maintenance Agency works with the profile-developer to try to incorporate suggested changes. In any case The Maintenance Agency determines if and when the ZIG endorses the profile.

For profiles where the ZIG becomes involved in the endorsement process as described above, the Profile page does not track the endorsement process; the profile-developer is responsible for doing so, for example within the text of the profile, or on its web page.

A profile-developer may wish to submit a profile for approval as an Internationally Registered Profile, IRP. The IRP procedures are described separately. The Maintenance Agency (and ZIG) becomes involved in that process only if and to the extent that ZIG endorsement of the profile is requested.


These procedures last updated May 1998

Objects and Definitions

The Z39.50 Maintenance Agency is the Registration Authority for Z39.50 objects and definitions. These are identified by ISO Object Identifiers (OIDs). The ISO-assigned OID for Z39.50 is 1.2.840.10003. (See About Z39.50 Object Identifiers.) All Z39.50 OIDs are subordinate to this OID, and thus the Z39.50 Maintenance Agency is the Registration Authority for OIDs subordinate to 1.2.840.10003.

Any OID, viewed as a node on the global OID tree, is either a leaf or non-leaf node. A leaf-node is referred to (here) as an object, and a non-leaf nodes as an object class (or just "class").

At the level immediately subordinate to 1.2.840.10003, the Z39.50 standard has assigned object classes 1.2.840.10003.1 through 1.2.840.10003.14. In addition, the Maintenance Agency has assigned one additional class: 1.2.840.10003.15.

Before proceeding, a notational convention:
The notation {1 2 840 10003} is used to denote 1.2.840.10003. In Appendix 1 (OID) of Z39.50, the notation {Z39-50} is used to denote {1 2 840 10003}, and thus, for example, {Z39-50 1) denotes {1 2 840 10003 1}. Further, since {Z39-50 1} represents the OID class "application context", which is assigned the notation {z39-50-context}, the notation {Z39-50-context 1} would denote {1 2 840 10003 1 1}. This notation is used here.
Thus the Maintenance Agency is registration authority for (Z39-50 1} through {Z39-50 14} assigned by the Z39.50 standard, and in addition, is responsible for assigning additional classes: {Z39-50 15}, etc., and is the registration authority for those as well. An object registry is maintained by the Maintenance Agency accessible via the web page.
Object ClassClass OIDDescription
Z39-50-context {Z39-50 1} application context definitions
Z39-50-APDU {Z39-50 2} abstract syntax for APDUs
Z39-50-attributeSet {Z39-50 3} attribute set definitions
Z39-50-diagnostic {Z39-50 4} diagnostic sets and diagnostic formats
Z39-50-recordSyntax {Z39-50 5} abstract record syntaxes
Z39-50-transferSyntax {Z39-50 6} transfer syntaxes for non-bibliographic records
Z39-50-resourceReport {Z39-50 7} resource report formats
Z39-50-accessControl {Z39-50 8} access control formats
Z39-50-extendedService {Z39-50 9} extended service definitions
Z39-50-userInfoFormat {Z39-50 10} user information formats
Z39-50-elementSpec {Z39-50 11} element specification formats
Z39-50-variantSet {Z39-50 12} variant set definitions
Z39-50-schema {Z39-50 13} schema definitions
Z39-50-tagSet {Z39-50 14} tag set definitions
Z39-50-negotiation {Z39-50 15} negotiation definitions

Application Context Definitions

One application context definition is registered (within the text of Z39.50-1995) and the Maintenance Agency anticipates that there will be no further requirements to register application context definitions. If further registrations are required, procedures will be developed.

Abstract Syntax for APDUs

The abstract syntax for APDUs is supplied in section 4.1 of Z39.50. This is the only abstract syntax for Z39.50 APDUs and it is not anticipated that another will be defined. Changes to the syntax are effected via amendment or defect reports.

Attribute Set Definitions

Three categories of attribute sets are considered: Registration and maintenance of attribute sets involves the following:
  1. Changes to definitions of standard attribute sets. These are done via amendment or defect report.

  2. Extensions to definitions of standard attribute sets. An implementor, group, or other interested party may propose an extension, to be listed (as pending) in the object register, subject to discussion and comment over the ZIG list, and scheduled for consideration at the next ZIG meeting. The ZIG might: The Maintenance Agency determines the intent of the ZIG and update the attribute set definition in the object registry accordingly.

    If the proposal is, for example, a list of Use attributes, the proposal should not attempt to assign permanent numeric values. The values are assigned by the Maintenance Agency when the attributes are added, and the proposer should not assume any specific values.

  3. Registration of public attribute sets. An implementor, group, or other interested party may request registration of an attribute set as a public definition. The requesting party should provide a complete definition of the attribute set (however, in some cases, the request will be considered if the definition is still in development and not yet complete), a reference, and justifications for a public (rather than local) identifier. The Maintenance Agency determines whether the attribute set should be publicly registered, and may suggest that it should instead be registered locally. If the request is accepted, the Maintenance Agency assigns an OID and add the definition to the object registry.

  4. Changes or extensions to public attribute sets. The procedures for changes or extensions to public attribute sets are similar to those for extensions to standard attribute sets (2 above).

  5. Registration of and changes and extensions to locally defined attribute sets. See Locally Defined Objects.

Diagnostic Sets and Diagnostic Formats

The procedures for maintenance of diagnostic sets and formats are largely the same as procedures for attribute set definitions. (To be developed further.)

Abstract Record Syntaxes

Procedures for maintenance of abstract record syntaxes bear similarity to procedures for attribute set definitions (but this needs to be developed further.)

Transfer Syntax for Non-bibliographic Records

The Maintenance Agency does not anticipate that any transfer syntaxes will require Z39.50 OIDs. If any are required, procedures will be developed.

Resource Report Formats

Procedures for maintenance of resource report formats are similar to the procedures for attribute set definitions. (To be developed further.)

Access Control Formats

Procedures for maintenance of access control formats are similar to the procedures for attribute set definitions. (To be developed further.)

Extended Service Definitions

Procedures for maintenance of Extended Services to be developed.

User Information Formats

Procedures for maintenance of user information formats are similar to the procedures for attribute set definitions. (To be developed further.)

Element Specification Formats

Procedures for maintenance of element specification formats are similar to the procedures for attribute set definitions. (To be developed further.)

Variant Set Definitions

Procedures for maintenance of variant set definitions are similar to the procedures for attribute set definitions. (To be developed further.)

Schema Definitions

Procedures for maintenance of schema definitions are similar to the procedures for attribute set definitions. (To be developed further.)

Tag Set Definitions

Procedures for maintenance of tag set definitions are similar to the procedures for attribute set definitions. (To be developed further.)

Negotiation Definitions

These procedures last updated February 2000
The process of negotiation is described in the Model for Z39.50 Negotiation During Initialization.

One particular area where implementors have expressed a requirement for negotiation, is profiles. A profile might specify within its text a set of rules that may be negotiated. An OID may be assigned to that specific set of rules. The profile might specify several alternative sets of rules, each to be identified by an OID.

A profile-developer may request one or more OIDs corresponding to a profile, for purposes of negotiation. The Maintenance Agency allocates requested OIDs provided that the profile-developer supplies a description, for each OID, of how that OID is to be used within the protocol, including the semantics of its usage. OIDs allocated for a profile are listed in the object registry. Alternatively, the profile-provider might request a single OID and then act as registration authority for subordinate OIDs. In this case the profile-provider is not responsible for reporting allocated OIDs to the Maintenance Agency, but may do so, and if so, they are listed in the object register.

Locally Defined Objects

Each registered implementor (see procedures pertaining to the Z39.50 Register of Implementors is assigned an integer identifier, referred to (for purposes of OID registration) as the OID index for that implementor. The OID index is used in the construction of local OIDs, for which that implementor delegated registration authority, by the Maintenance Agency.

For an implementor assigned identifier 'p' by the Maintenance Agency, locally registered OIDs take the form:

{Z39-50 n 1000 p m}

where {z39-50 n} is a Z39.50 object class.

A locally registered OID may be published or private. A local OID registered by an implementor is published by the Maintenance Agency (listed in the object registry) upon request by the implementor. In that case the implementor should supply a reference to the definition.

An implementor who registers a local object need not notify the Maintenance Agency, in which case it not published; in that case the object is referred to as a local, private object.

Procedures for registration of local objects, and procedures for extensions and changes to definitions identified by local objects, are otherwise determined by the implementor who is the registration authority for the object, and these procedures need not be reported to the Maintenance Agency.

Experimental Objects

In addition to local objects, implementors may register OIDs for experimental objects. These take the form:
{Z39-50 n 2000 p m}
The procedures pertaining to experimental objects are the same as those for local object (except for the difference in the form of the OID, that is, "2000" instead of "1000").
These procedures last updated January 1999

Register of Implementors

The Maintenance Agency maintains a Z39.50 Register of Implementors.

An implementor wishing to register his/her company may send the following information via email to the Maintenance Agency:

  1. Name of company. Required. Entries in the register are companies (organizations, institutions, etc.), not individuals (although each entry must list a single individual as representative).
  2. Representative Required. The name of an individual. One and only one name may be submitted. A company must designate an individual representative, and the register does not list multiple representatives for a company. The register also does not list titles for representatives. The Maintenance Agency recommends that a company designate an individual to act as the primary point of contact for Z39.50 technical matters, rather than a corporate executive.
  3. Address, phone, fax. All optional; phone number is recommended.
  4. Email address. Required. Only a single email address may be submitted. The register will does not list multiple email addresses for a company.
  5. Web address. optional.
  6. Description of Z39.50 product or implementation. Required. The product or implementation described need not be in production; this may be a description of a planned product or implementation, or one in development. However, registration requests are not be accepted without some description, and the product or implementation described must pertain to Z39.50 (see the Z39.50 Register of Implementors for examples). Description is subject to editing by the Maintenance Agency. The Maintenance Agency makes no attempt to validate the accuracy of the description, and does not accept responsibility if false or misleading information is supplied.
Items 1, 2, 4, and 6 are required, and requests are not accepted with any of these omitted.

The company is assigned an implementor id (which it may use to define local object identifiers ).

Each entry in the register reflects the date-of-last-update and date-of-last-verification. A company may verify or update its entry at any time by sending a message via email to the Maintenance Agency either stating that the information is current, or supplying updated information. When a company verifies its entry, the date-of-last-verification is set to the current date and the date-of-last-update remains the same. When a company updates its entry both the date-of-last-verification and the date-of-last-update are set to the current date. (The date-of-last-update changes only when the description is updated.) Every company must verify or update its entry at least once-a-year, that is, the date-of-last-verification should never be older than a year.

Each month the Maintenance Agency will scan the register for entries where the date-of-last-verification is more than a year old (e.g. the date-of-last-verification is 12/98 and the current month is 1/99). The Maintenance Agency will email the listed representative, requesting verification or update, with a deadline of the end of that month. If there is no response by the end of the month, the entry will be removed from the register and placed in a separate, archive register: Unverified Z39.50 Register Entries Recently Removed. After one year, it will be dropped from the archive register.

If a company is archived or dropped from the register, the id assigned to that company will not be re-used. The company may become registered again at any time, upon request, by supplying the requisite information, and will retain the original id.

If a company changes names, it may retain its identifier, or be assigned a new identifier, as it prefers.

The register is maintained for information purposes, and the Maintenance Agency, by providing the register, does not endorse any of the companies or products listed. The Maintenance Agency does not attempt to validate the information supplied by a company, and is not responsible for errors or mis-representation. Furthermore, the Maintenance Agency does not attempt to determine who should be the legitimate representative of a company. If an individual claims to represent a company, the Maintenance Agency lists that individual (i.e. does not challenge that claim) and if a different individual subsequently claims to be the representative, the Maintenance Agency then lists the newly supplied name instead. (Thus the Maintenance Agency does not become involved in any dispute over who is the legitimate representative of a company; that is a problem for the company to resolve.)


These procedures last updated May 1998

Implementor Agreements

The Maintenance Agency maintains and provides access to Z39.50 Implementor Agreements. These agreements address cases where the Z39.50 protocol does not provide a single, unambiguous solution for a particular function (or provides, or appears to provide, multiple solutions).

An example is Linear Range Searching. In this case the problem addressed is how to formulate a search for records where the value of the specified access point is within the interval bounded by two endpoints. It is possible to develop various potential formulations (and the Z39.50 standard does not address this function at all) but for semantic interoperability, it is useful to document a single approach that the implementor community at large can agree upon, and that profiles may reference.

An implementor agreement differs from a profile; it is narrower in scope and broader in applicability. An implementor agreement might be referenced by several profiles; a profile is often referred to (informally) as "a set of implementor agreements".

Procedures for Implementor Agreements

An issue that may require an implementor agreement may be raised at a ZIG meeting or over the ZIG list. The Maintenance Agency prepares a draft Implementor Agreement to be reviewed at the next ZIG meeting. Initially the draft report is added to the 'pending' Implementor Agreement list. At the ZIG meeting when the pending agreement is reviewed, if it is endorsed by the ZIG, it is subsequently added to the 'approved' Implementor Agreement list. If not, it is either withdrawn, or retained in the 'pending' list and subsequently revised and scheduled for review at a subsequent meeting. The Z39.50 Maintenance Agency determines whether or not the ZIG endorses the agreement. The Maintenance Agency provides a list of 'pending' as well as 'approved' implementor agreements on its web page.
These procedures last updated May 1998

ZIG Commentaries

The Maintenance Agency maintains and provides access to ZIG Commentaries (otherwise referred to as "the collective wit and wisdom of the ZIG") . Their purpose is to provide guidance to implementors and to elaborate Z39.50 concepts.

Discussions of various Z39.50-related issues, at ZIG meetings or over the ZIG list, incorporate different points-of-view and often provide valuable insight into the protocol, when they can be clearly and succinctly capsulized.

A Commentary differs from a Clarification (though they are processed in a similar manner), whose intent is to clarify, in cases where the text of the standard is ambiguous or requires interpretation. A commentary addresses aspects of the standard where the related prose may be terse but not necessarily ambiguous. The text of a commentary may be much less formal than the corresponding text of the standard.

Procedures for Commentaries

A question or issue requiring a Commentary may be raised at a ZIG meeting or over the ZIG list. The Maintenance Agency prepares a draft Commentary to be reviewed at the next ZIG meeting. The Commentary includes the name of the implementor who raised the issue, the date, a synopsis of the question, a provisional response, and a status.

Each Commentary is initially assigned a status of 'pending'. At the ZIG meeting when the Commentary is reviewed, if it is endorsed by the ZIG, it is subsequently assigned a status of 'approved'. If not, it is either withdrawn, or else it is assigned a status of 'still pending' , revised, and scheduled for review at a subsequent meeting. The Z39.50 Maintenance Agency determines whether or not the ZIG endorses the Commentary. The Maintenance Agency provides a list of 'pending' as well as 'approved' Commentaries on its web page.


These procedures last updated May 1998

Hosts Available for Testing

The Z39.50 Maintenance Agency maintains and provides access to a list of Z39.50 Hosts Available for Testing .

Only hosts (i.e. servers) providing databases free-of-charge, with no pre-registration, and which the provider intends that anyone may access for interoperability testing, are listed. Any such server-provider may request that a server be listed by providing to the Maintenance Agency the following information:

Notes:
  1. Port defaults to 210, so if port is not listed, it is 210, and if port is 210, it is not listed.
  2. ''xxdefault' is the default database, so if database name is not listed, 'xxdefault' is assumed to be supported, and if 'xxdefault' is the only database supported it is not listed. A maximum of 10 databases are listed.
  3. Search and Present are the default set of services, and if these are the only features, are not listed.
  4. "no validation" is the default.

These procedures last updated May 1998

Z39.50 Software

The Z39.50 Maintenance Agency provides information via the Software Page about available Z39.50 software. Separate lists are maintained for free and commercial software.

A Z39.50 software producer or implementor may request that a product be listed by supplying to the Maintenance Agency the following information:

Applicable software may include client software, server software, toolkits, source code, object code, specific platform or platform independent software, etc. The only requirement is that the product must support Z39.50 in some manner.

Z39.50 Maintenance Agency
Network Development & MARC Standards Office
Comments on this document: z3950@loc.gov
Updated: January 10, 2000

Library of Congress
General Library of Congress Help Desk