Z39.50 Maintenance Agency Procedures
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:
- a perceived technical error or ambiguity in the standard, inadvertently introduced during
drafting or publication, which could lead to incorrect application of the standard; or
- a clerical error inadvertently introduced during drafting or publication.
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:
- editorial defects (ambiguity in the wording of the standard);
- technical defects (technical error);
- clerical defects (typographical, spelling, minor grammatical errors, etc.).
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:
- 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.
- 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).
- 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.
- Report Concerning
This indicates ISO 23950, and the affected services, etc.
- Type of Defect
Technical, editorial, or clerical.
- Reference in Document
Page number, clause, etc.
- 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.
- 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.
- 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:
- the ZIG might endorse the profile;
- the ZIG might stipulate endorsement if specific changes are made;
- the ZIG may decline to endorse the profile, suggesting areas that need to be re-worked; or
- 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.
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:
- A standard attribute set is one which is defined within the text of the Z39.50 standard: bib-1, exp-1, and ext-1.
- A public attribute set is one which is not standard and not a local set. It has an OID of the form {Z39-50 3 m}.
- A locally defined attribute set has an OID of the form {Z39-50 3 1000 n m} where n is the identifier of a registered Z39.50 Implementor, and m is a number assigned by the implementor.
Registration and maintenance of attribute sets involves the following:
- Changes to definitions of standard attribute sets.
These are done via amendment or defect report.
- 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:
- endorse the proposed extensions;
- endorse the proposed extensions subject to specific modifications;
- defer the proposed extensions, pending further discussion; or
- reject the proposed extensions.
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.
- 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.
- 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).
- 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.
Abstract Record Syntaxes
Procedures for maintenance of abstract record syntaxes bear similarity to procedures for attribute set definitions 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. Access Control Formats
Procedures for maintenance of access control formats are similar to the procedures for attribute set definitions. 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. Element Specification Formats
Procedures for maintenance of element specification formats are similar to the procedures for attribute set definitions. Variant Set Definitions
Procedures for maintenance of variant set definitions are similar to the procedures for attribute set definitions. Schema Definitions
Procedures for maintenance of schema definitions are similar to the procedures for attribute set definitions. Tag Set Definitions
Procedures for maintenance of tag set definitions are similar to the procedures for attribute set definitions.
Negotiation Definitions
The process of negotiation is partially described in the user information format Negotiate OIDs, however the development of this process and the procedures for maintenance of negotiation format are still in development.
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:
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:
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 October 2006
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:
- Name of company. Required. Entries in the register are companies,
not individuals (although each entry must list a single individual as representative).
- Representative Required. The name of an individual. 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 - someone that the Maintenance Agency can easily contact.
- Address, phone, fax. All optional.
- Email address. Required.
Important Note:
The individual who registers the company,
by registering, implicitly assumes responsibility for ensuring that the Maintenance
Agency
will be able to contact the company representative, even though that representative
may change. In particular the representative agrees that if the email
address changes, the Maintenance Agency will be notified. If the representative
leaves the company or for any reason is no longer the Z39.50 representative,
the Maintenance Agency will be notified who
the new representative is and the new email address.
- Web address. optional.
- 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 will not be accepted without some description,
and the product or implementation described must pertain to Z39.50 (see the Register 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
(and in addition, date-of-entry for more recent entries). 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. Change of contact information does not constitute an update.
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 or so the Maintenance Agency will scan the register for entries where
the date-of-last-verification is more than a year old. 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. (Eventually 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:
- contact (individual) including email address;
- host address;
- host port (see note 1);
- databases available for testing; (see note 2);
- a brief list of services and features (see note 3);
- any required validation, such as userId/password (see note 4);
- and optionally:
- a link (url) to any additional information, such as attribute sets, syntaxes, etc;
- brief additional information to be provided directly in the list, in lieu of a separate file.
Notes:
- Port defaults to 210, so if port is not listed, it is 210, and if port is 210, it is not
listed.
- ''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.
- Search and Present are the default set of services, and if these are the only features, are not listed.
- "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:
- the name of the product;
- a brief (1-3 line) synopsis (subject to editing), indicating, for example: is it client software, server software (or both); platform; services; etc.
- whether it is free or commercial software (or includes both, in which case different synopses should be included);
- url pointing to additional information;
- a contact (individual).
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.
Network Development & MARC Standards Office
Comments on this document: z3950@loc.gov
Updated: October 2006
Library of Congress
Library of Congress Help Desk