HOME - Z39.50 Resources - Z39.50 Document - Related Specifications
Object Identifiers - Implementor Register - Z39.50 Profiles - ZIG Meetings - Site Index

Z39.50 Maintenance Agency Procedures

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

• Defect Reports
• Amendments
• Clarifications
• Profiles

As Registration Authority, formal responsibilities include maintenance of:

• Objects and External Definitions

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

• Register of Implementors
• Implementor Agreements
• ZIG Commentaries
• Hosts Available for Testing
• Information Regarding Availability of Z39.50 Software
• As well as other, miscellaneous information.

Defect Reports

These procedures last updated May 1998

• 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.

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

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

Format of Defect Report

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

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

Amendment Procedures

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

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

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.

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

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.

Application Context Definitions

Abstract Syntax for APDUs

Attribute Set Definitions

• 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.

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:
   • 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.

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

Abstract Record Syntaxes

Transfer Syntax for Non-bibliographic Records

Resource Report Formats

Access Control Formats

Extended Service Definitions

User Information Formats

Element Specification Formats

Variant Set Definitions

Schema Definitions

Tag Set Definitions

Negotiation Definitions

These procedures last updated February 2000

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

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

{Z39-50 n 2000 p m}

These procedures last updated January 1999

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.

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

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

These procedures last updated May 1998

ZIG Commentaries

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

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

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.

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

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).