rfc1729.txt

<VC++网络游戏建摸与实现>源代码


RFC 1729      Using the Z39.50 in the Internet Environment December 1994


   Real-world implementations need to be prepared to deal with both TCP
   ABORT and CLOSE anyway, so this approach presents no additional
   problems, other than the somewhat ambiguous nature of the type of
   association termination.

   It is expected that Z39.50 Version 3 will include a termination
   service which will involve an exchange of Z39.50 CLOSE APDUs,
   followed by an association RELEASE (which would presumably, in the
   Internet environment, be mapped to a TCP CLOSE). This new termination
   service is expected to support both graceful and abrupt termination.
   Of course, robust implementations will still need to be prepared to
   encounter TCP CLOSE or ABORT.

   Service mappings for the transmission of data by client and server
   (to the presentation layer P-DATA service) are trivial: They are
   simply mapped to TCP transmit and receive operations. TCP facilities
   such as expedited data are not used by Z39.50 in a TCP environment.

Contexts

   At the point when the TCP connection is established on TCP port 210,
   client and server should both assume that the application context
   given in Appendices A and B of the Z39.50-1992 standard are in place.
   These are the ASN.1 definitions of the Z39.50 APDUs and the transfer
   syntax defined by applying the BER to these APDUs.

   Implementations can reasonably expect that the diagnostic set BIB-1
   is supported, and, if resource control is being used, the resource
   report format BIB-1 is supported as well.

   In the absence of a presentation negotiation mechanism, clients and
   servers should be cautious about using alternative attribute sets,
   diagnostic record formats, resource report formats, or other objects
   defined by optional EXTERNALs within the Z39.50 ASN.1, such as
   authentication parameters, unless there is known to be prior
   agreement to support them. Of course, either participant in an
   association can reference such an object by object ID in an APDU, but
   there is no guarantee that the other partner in the association will
   be able to understand it. Robust implementations should be prepared
   to encounter unknown or unsupported object IDs and generate
   appropriate diagnostics. Over time, the default, commonly known pool
   of object IDs may be expanded (for example, to support authentication
   parameters).

   Implementors should refer to the document [14] issued by the Z39.50
   maintenance agency in June 1992 for more details on the assumed
   contexts and object identifiers.




Lynch                                                           [Page 5]

RFC 1729      Using the Z39.50 in the Internet Environment December 1994


   Record syntaxes present a serious practical problem. In the OSI
   environment, the partners in a Z39.50 association are assumed to
   agree, either through presentation negotiation as part of association
   establishment, or later, dynamically, as part of the PRESENT process
   (through the use of the alter presentation context function at the
   presentation layer), on which record syntaxes the two entities
   commonly know. There is a preferred record syntax parameter that can
   be supplied by the client to guide this negotiation. A number of
   registered record syntaxes exist; some are based on ASN.1 and others
   use formats such as the MARC standard for the interchange of machine
   readable cataloging records which predate ASN.1, but are widely
   implemented.  In the TCP/IP environment, if the server cannot supply
   the record in the preferred syntax, it has no guarantee that the
   client will understand any other syntax in which it might transmit
   the record back to the client, and has no means of negotiating such
   syntaxes.

   Several proposals have been suggested to solve this problem. One,
   which will likely be part of Z39.50 Version 3, is to replace the
   preferred record syntax parameter with a list of prioritized
   preferred syntaxes supplied by the client, plus a flag indicating
   whether the server is allowed to substitute a record syntax not on
   the list provided by the client. The currently proposed ASN.1 for
   this extension is upwards compatible with Z39.50 Version 2, although
   the details are still under discussion within the Z39.50
   Implementor's Group. As the Version 3 ASN.1 becomes stable in this
   area, Z39.50 servers are encouraged to accept the extended ASN.1 for
   generalized preferred record syntax. The extensibility rules for
   Z39.50 negotiation let clients and servers negotiate the use of
   Z39.50 Version 2 plus the generalized preferred syntax feature from
   Version 3. Thus, a client could support the generalized preferred
   record syntax, propose its use to any server, and, if the server
   rejects the proposal, revert to the Version 2 preferred syntax
   feature.

   A second alternative (not incompatible with the Version 3 extension)
   would be to adopt a convention for TCP/IP implementations that the
   server not return a record in a syntax not on the preferred record
   syntax list provided by the client. Instead, it would return a
   diagnostic record indicating that a suitable record transfer syntax
   was not available. This strategy could be viewed as simply
   implementing a subset of the Version 3 solution, and should be
   considered by implementors of servers as a possible interim measure.








Lynch                                                           [Page 6]

RFC 1729      Using the Z39.50 in the Internet Environment December 1994


Other Interoperability Issues

   Version 3 will include an "other" data field in each APDU, which can
   be used to carry implementation-specific extensions to the protocol.
   A number of implementations are already employing this field, and
   interoperable implementations might be wise to include code which at
   least ignores the presence of such fields rather than considering
   their presence an error (in contravention of the standard).

References

   [1] National Information Standards Organization (NISO). American
       National Standard Z39.50, Information Retrieval Service
       Definition and Protocol Specifications for Library Applications
       (New Brunswick, NJ: Transaction Publishers; 1988).

   [2] ANSI/NISO Z39.50-1992 (version 2) Information Retrieval Service
       and Protocol: American National Standard, Information Retrieval
       Application Service Definition and Protocol Specification for
       Open Systems Interconnection, 1992.

   [3] ISO 10162 International Organization for Standardization (ISO).
       Documentation -- Search and Retrieve Service Definition, 1992.

   [4] ISO 10163 International Organization for Standardization (ISO).
       Documentation -- Search and Retrieve Protocol Definition. 1992.

   [5] ISO 8822 - Information Processing Systems - Open Systems
       Interconnection - Connection Oriented Presentation Service
       Definition, 1988.

   [6] ISO 8649 - Information Processing Systems - Open Systems
       Interconnection - Service Definition for the Association Control
       Service Element, 1987. See also ISO 8650 - Information Processing
       Systems - Open Systems Interconnection - Protocol Specification
       for the Association Control Service Element, 1987.

   [7] Rose, M., and D. Cass, "ISO Transport Layer Services on Top of
       the TCP, Version 3", STD 35, RFC 1006, Northrop Research and
       Technology Center, May 1987.

   [8] Registry of Z39.50 Implementors, available from the Z39.50
       Maintenance Agency (Ray Denenberg, [e-mail])








Lynch                                                           [Page 7]

RFC 1729      Using the Z39.50 in the Internet Environment December 1994


   [9] To subscribe to the Z39.50 Implementor's Workshop list send the
       message: SUB Z3950IW yourname to: [e-mail]
       (or NERVM.BITNET).  Current drafts of the Version 3 Protocol
       document are available through the Library of Congress GOPHER
       server, MARVEL.LOC.GOV.

  [10] ISO 8824 - Information Processing Systems - Open Systems
       Interconnection - Specifications for Abstract Syntax Notation One
       (ASN.1), 1987

  [11] ISO 8825 Information Processing Systems - Open Systems
       Interconnection - Specification of Basic Encoding Rules for
       Abstract Syntax Notation One (ASN.1) 1987

  [12] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       USC/Information Sciences Institute, October 1994.

  [13] WAIS Profile of Z39.50 Version 2, Revision 1.4, April 26, 1994,
       available from WAIS Inc.

  [14] Registration of Z39.50 OSI Object Identifiers (Z39.50-MA-024),
       available from the Z39.50 Maintenance Agency (Ray Denenberg,
       [e-mail]).

Security Considerations

   This document does not discuss security considerations. However, it
   should be noted that the Z39.50 protocol includes mechanisms for
   authentication and security that implementors should review.

Author's Address

   Clifford A. Lynch
   University of California, Office of the President
   300 Lakeside Drive, 8th Floor
   Oakland, CA 94612-3550

   Phone: [phone]
   EMail: [e-mail]












Lynch                                                           [Page 8]