Frontmatter

©February 1998, The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners.

Any comments relating to the material contained in this document may be submitted to The Open Group at:

The Open Group
Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
United Kingdom

OGSpecs@opengroup.org

Preface

The Open Group

The Open Group is the leading vendor-neutral, international consortium for buyers and suppliers of technology. Its mission is to cause the development of a viable global information infrastructure that is ubiquitous, trusted, reliable, and as easy-to-use as the telephone. The essential functionality embedded in this infrastructure is what we term the IT DialTone. The Open Group creates an environment where all elements involved in technology development can cooperate to deliver less costly and more flexible IT solutions.

Formed in 1996 by the merger of the X/Open Company Ltd. (founded in 1984) and the Open Software Foundation (founded in 1988), The Open Group is supported by most of the world's largest user organizations, information systems vendors, and software suppliers. By combining the strengths of open systems specifications and a proven branding scheme with collaborative technology development and advanced research, The Open Group is well positioned to meet its new mission, as well as to assist user organizations, vendors, and suppliers in the development and implementation of products supporting the adoption and proliferation of systems which conform to standard specifications.

With more than 200 member companies, The Open Group helps the IT industry to advance technologically while managing the change caused by innovation. It does this by:

• Consolidating, prioritizing, and communicating customer requirements to vendors

• Conducting research and development with industry, academia, and government agencies to deliver innovation and economy through projects associated with its Research Institute

• Managing cost-effective development efforts that accelerate consistent multi-vendor deployment of technology in response to customer requirements

• Adopting, integrating, and publishing industry standard specifications that provide an essential set of blueprints for building open information systems and integrating new technology as it becomes available

• Licensing and promoting the Open Brand, represented by the "X" Device, that designates vendor products which conform to Open Group Product Standards

• Promoting the benefits of the IT DialTone to customers, vendors, and the public

The Open Group operates in all phases of the open systems technology lifecycle including innovation, market adoption, product development, and proliferation. Presently, it focuses on seven strategic areas: open systems application platform development, architecture, distributed systems management, interoperability, distributed computing environment, security, and the information superhighway. The Open Group is also responsible for the management of the UNIX trademark on behalf of the industry.

The Development of Product Standards

This process includes the identification of requirements for open systems and, now, the IT DialTone, development of Technical Standards (formerly CAE and Preliminary Specifications) through an industry consensus review and adoption procedure (in parallel with formal standards work), and the development of tests and conformance criteria.

This leads to the preparation of a Product Standard which is the name used for the documentation that records the conformance requirements (and other information) to which a vendor may register a product.

The "X" Device is used by vendors to demonstrate that their products conform to the relevant Product Standard. By use of the Open Brand they guarantee, through the Open Brand Trade Mark License Agreement (TMLA), to maintain their products in conformance with the Product Standard so that the product works, will continue to work, and that any problems will be fixed by the vendor.

Open Group Publications

The Open Group publishes a wide range of technical documentation, the main part of which is focused on development of Technical Standards and product documentation, but which also includes Guides, Snapshots, Technical Studies, Branding and Testing documentation, industry surveys, and business titles.

There are several types of specification:

• Technical Standards (formerly CAE Specifications)

  The Open Group Technical Standards form the basis for our Product Standards. These Standards are intended to be used widely within the industry for product development and procurement purposes.

  Anyone developing products that implement a Technical Standard can enjoy the benefits of a single, widely supported industry standard. Where appropriate, they can demonstrate product compliance through the Open Brand. Technical Standards are published as soon as they are developed, so enabling vendors to proceed with development of conformant products without delay.

• CAE Specifications

  CAE Specifications and Developers' Specifications published prior to January 1998 have the same status as Technical Standards (see above).
  

• Preliminary Specifications

  Preliminary Specifications have usually addressed an emerging area of technology and consequently are not yet supported by multiple sources of stable conformant implementations. They are published for the purpose of validation through implementation of products. A Preliminary Specification is as stable as can be achieved, through applying The Open Group's rigorous development and review procedures.

  Preliminary Specifications are analogous to the trial-use standards issued by formal standards organizations, and developers are encouraged to develop products on the basis of them. However, experience through implementation work may result in significant (possibly upwardly incompatible) changes before its progression to becoming a Technical Standard. While the intent is to progress Preliminary Specifications to corresponding Technical Standards, the ability to do so depends on consensus among Open Group members.
  

• Consortium and Technology Specifications

  The Open Group publishes specifications on behalf of industry consortia. For example, it publishes the NMF SPIRIT procurement specifications on behalf of the Network Management Forum. It also publishes Technology Specifications relating to OSF/1, DCE, OSF/Motif, and CDE.

  Technology Specifications (formerly AES Specifications) are often candidates for consensus review, and may be adopted as Technical Standards, in which case the relevant Technology Specification is superseded by a Technical Standard.

In addition, The Open Group publishes:

• Product Documentation

  This includes product documentation-programmer's guides, user manuals, and so on-relating to the Pre-structured Technology Projects (PSTs), such as DCE and CDE. It also includes the Single UNIX Documentation, designed for use as common product documentation for the whole industry.

• Guides

  These provide information that is useful in the evaluation, procurement, development, or management of open systems, particularly those that relate to the Technical Standards or Preliminary Specifications. The Open Group Guides are advisory, not normative, and should not be referenced for purposes of specifying or claiming conformance to a Product Standard.

• Technical Studies

  Technical Studies present results of analyses performed on subjects of interest in areas relevant to The Open Group's Technical Program. They are intended to communicate the findings to the outside world so as to stimulate discussion and activity in other bodies and the industry in general.

Versions and Issues of Specifications

As with all live documents, Technical Standards and Specifications require revision to align with new developments and associated international standards. To distinguish between revised specifications which are fully backwards compatible and those which are not:

• A new Version indicates there is no change to the definitive information contained in the previous publication of that title, but additions/extensions are included. As such, it replaces the previous publication.

• A new Issue indicates there is substantive change to the definitive information contained in the previous publication of that title, and there may also be additions/extensions. As such, both previous and new documents are maintained as current publications.

Corrigenda

Readers should note that Corrigenda may apply to any publication. Corrigenda information is published on the World-Wide Web at http://www.opengroup.org/corrigenda.

Ordering Information

Full catalogue and ordering information on all Open Group publications is available on the World-Wide Web at http://www.opengroup.org/pubs.

This Document

This document describes XNFS, the X/Open NFS Specification. This document supersedes the previous X/Open publication Protocols for X/Open Interworking, XNFS, Version 3, Document Number C525, August 1996. The previous version was aligned with Sun's NFS Version 3 (RFC 1813). This revised version (XNFS, Version 3W) incorporates the Sun WebNFS^TM; optional extensions (RFCs 1738, 1808, 2054, 2055).

The process of accessing remote files and directories as though they were part of the local file system hierarchy is commonly known as "transparent file access" (TFA). The most widely used heterogeneous TFA architecture is the Network File System (NFS), originally developed by Sun Microsystems.

XNFS provides a means of access to files and directories that are physically stored on remote systems, by extending the semantics of local system interfaces so that applications and end users can (as far as possible) ignore the distinctions between local and remote objects.

NFS has been implemented on a wide range of architectures, from personal computers to mainframes and supercomputers. The specifications for the protocols associated with NFS have been published, and there have been several independent implementations.

With the XNFS specification, X/Open offers the market a temporary but complete solution to the problem of transparent file access between X/Open-compliant systems. Temporary, because X/Open recognises the TFA standardisation effort ongoing within the IEEE P1003.1f committee, and X/Open intends to be compliant with 1003.1f TFA at such time as it becomes an IEEE standard. Complete, because X/Open now offers both protocols for interoperability (via this XNFS specification) and interfaces for application/user portability (via the XSI specifications, in conjunction with the semantic differences defined in the appendices to this document).

This specification is based in part on the X/Open (PC)NFS Specification.

The X/Open (PC)NFS Specification defines the protocols for communication between a PC client running DOS or OS/2 and an X/Open-compliant server.

The XNFS specification defines:

• The transparent file access service provided by XNFS

• The protocols that support this service between X/Open-compliant machines, which can take the role of either servers or clients

• The differences in semantics of the X/Open System Interfaces and Headers Specification (see reference XSH) and the X/Open Commands and Utilities Specification (see reference XCU) when they are used "transparently" using XNFS rather than locally

Since many of the protocols used are the same for PC and X/Open-compliant system clients, there is obviously a great deal of overlap between these specifications.

In the event of any inconsistency or disagreement between the two documents, this document is to be treated as authoritative. At some future date, the X/Open (PC)NFS Specification will be revised to include only those elements which are specific to PC clients, such as the pcnfsd protocol, filename and attribute mapping, and the transmission analysis.

Intended Audience

The second audience is the developers of X/Open CAE applications. This group relies upon the semantics of the XSI as defined in the X/Open System Interfaces and Headers Specification (see reference XSH) and the X/Open Commands and Utilities Specification (see reference XCU) and needs to be aware of any semantic changes which the use of XNFS may introduce. These changes are described in Semantic Difference Summary for File Access , Open-System Interface Semantics over XNFS and Open System Utilities Semantics over XNFS . Obviously an XNFS implementor must be aware of this material so that their implementation does not behave in an unexpected manner.

Structure

• Introduction introduces the context for NFS.

• XNFS Service Model describes the basic XNFS Service Model, in terms of abstract objects and operations which are implementation-independent.

• XDR Protocol Specification specifies the subset of the XDF protocol used by XNFS.

• Remote Procedure Calls: Protocol Specification specifies a message protocol (using XDR language) used in implementing an RPC package.

• RPC Interface to UDP Transport Services explains how protocols defined as part of XNFS interface with the underlying transport.

• Port Mapper Protocol describes the port mapper protocol, which maps RPC program and version numbers to transport-specific port numbers.

• XNFS: Protocol Specification, Version 2 specifies the NFS protocol that Sun Microsystems, Inc. and others use to provide transparent remote access to shared file systems over local area networks.

• Mount Protocol specifies the Mount protocol, which is separate from but related to the NFS protocol.

• File Locking over XNFS defines the Network Lock Manager (NLM) and Network Status Monitor (NSM) which together provide stateful services for NFS.

• Network Lock Manager Protocol defines the NLM protocol.

• Network Status Monitor Protocol defines the NSM protocol.

• XNFS: Protocol Specification, Version 3 specifies the additional NFS, Version 3 protocol which must be supported in addition to that specified in XNFS: Protocol Specification, Version 2 . It includes a summary of the changes introduced in the Version 3 protocol.

• Mount Protocol, Version 3 specifies an additional Mount, Version 3 protocol which must be supported in addition to that specified in Mount Protocol .

• Network Lock Manager Protocol, Version 4 specifies an additional NLM, Version 4 protocol which must be supported in addition to that specified in Network Lock Manager Protocol in order to support NFS, Version 3.

• Semantic Difference Summary for File Access summarises semantic differences for access of files on remote systems using XNFS.

• Open-System Interface Semantics over XNFS describes semantic differences for system interfaces and headers (XSH) which operate differently when used with XNFS.

• Open System Utilities Semantics over XNFS describes semantic differences for commands and utilities (XCU) which operate differently when used with XNFS.

• Open Systems Transmission Analysis gives a general description of how a system interface (XSH) function is executed by a sequence of RPCs.

• WebNFS Extensions describes the WebNFS extensions to the NFS protocol.

XNFS Version 2 -> Version 3 Changes

A summary of these changes follows:

• Referenced Documents updated.

• Section 1.2 (Scope), 2nd paragraph extended to add:
  

  Protocols corresponding to both NFS Version 2 and NFS Version 3 are specified. Systems conforming to this document must support both protocol sets.

  
  

• Section 1.4 (Protocol Stacks and Conformance), first bullet list extended to add:

  • NFS Version 3 (see XNFS: Protocol Specification, Version 3 )

  • Mount Version 3 (see Mount Protocol, Version 3 )

  • NLM Version 4 (see Network Lock Manager Protocol, Version 4 )

• Section 1.4 (Protocol Stacks and Conformance), XPG3/XPG4 Compliance description extended to read:
  

  This specification applies to Issue 3, Issue 4 and Issue 4, Version 2 of XPG, except where explicitly stated otherwise.

• New section (Hyper Integer and Unsigned Hyper Integer) added after section 3.2.2, with subsequent sections renumbered accordingly.

• Section 3.3.3 (Syntax Information), in the BNF grammar, add:

   
  
   | [ "unsigned" ] "hyper"
  
  
  

• Section 3.3.4 (Syntax Note), first bullet point, add "hyper" to the list of keywords which cannot be used as identifiers.

• Section 4.4 (Authentication Protocols), in the first paragraph, change:

   
  
  two "flavours" of authentication.
  
  

  to

   
  
  four "flavours" of authentication.
  
  

• Section 4.4 (Authentication Protocols), add:

   
  
  AUTH_DES     = 3,
  AUTH_KERB    = 4,
  
  
  

  to the auth_flavor definition.

• After section 4.4.2, add a new subsection (4.4.3 DES and Kerberos Authentication).

• Section 7.3.2 (Basic Data Types), clarify the meaning of the "blocks" and "blocksize" fields in the fattr structure.

• Section 7.5.6 (NFSPROC_READLINK Specification), change the Return Code NFSERR_NXIO to NFSERR_INVAL (to match existing server practice).

• Section 10.2.2 (Basic Data Types for Locking), add to the description for nlm_holder:
  

  The "oh" field is an opaque object that identifies the host, or a process on the host, that is holding the lock.

• Section 10.2.2 (Basic Data Types for Locking), replace the sentence which describes "fh" and "oh" with:
  

  The "fh" field identifies the file to lock. The "oh" field is an opaque object that identifies the host, or a process on the host, that is making the request.

• Add Chapter 12 "Network File System: Protocol Specification, Version 3".

• Add Chapter 13 "Mount Protocol, Version 3".

• Add Chapter 14 "Network Lock Manager Protocol, Version 4".

• Appendix A is expanded to include description of those semantic differences for interfaces, commands and utilities which were previously included in man page descriptions in Appendices B and C.

• Appendix B is reduced to listing those functions which show no semantic differences (that is, behave the same) when running in a local file system environment, and also those which may show a semantic difference when invoked in an XNFS environment. The man page definitions which described these differences are deleted, since Appendix A now covers these differences.

• Appendix C is reduced to listing those commands and utilities that show no semantic differences (that is, behave the same) when running in a local file system environment, and also those which may show semantic differences when invoked in an XNFS environment. The man page definitions which described these differences are deleted, since Appendix A now covers these differences.

• Appendix D revision for NFS Version 3 is represented by an additional bullet item (Version 2 versus Version 3) in Section D.1.

XNFS Version 3 -> Version 3W Changes

Trade Marks

AT&T® is a registered trademark of AT&T in the U.S.A. and other countries.

Diablo® is a registered trademark of Xerox Corporation.

Ethernet® is a registered trademark of Xerox Corporation.

IBM® is a registered trademark of International Business Machines Corporation.

LAN Manager^TM; is a trademark of Microsoft Corporation.

MS-DOS® is a registered trademark of Microsoft Corporation.

NFS® is a registered trademark and Network File System^TM; is a trademark of Sun Microsystems, Inc.

OS/2® is a registered trademark of International Business Machines Corporation.

PC-NFS^TM; is a trademark of Sun Microsystems, Inc..

Postscript® is a registered trademark of Adobe Systems Incorporated.

VAX® is a registered trademark of Digital Equipment Corporation.

VMS® is a registered trademark of Digital Equipment Corporation.

Motif,® OSF/1,® UNIX,® and the "X Device"® are registered trademarks and IT DialTone^TM; and The Open Group^TM; are trademarks of The Open Group in the U.S. and other countries.

WebNFS^TM; is a trademark of Sun Microsystems, Inc.

Referenced Documents

Open Group Documents

BSFT

CAE Specification, December 1991, Byte Stream File Transfer (BSFT) (ISBN: 1-872630-27-8, C194), published by The Open Group.

Internationalisation Guide

Guide, July 1993, Internationalisation Guide, Version 2 (ISBN: 1-859120-02-4, G304), published by The Open Group.

(PC)NFS

Developers' Specification, August 1990, Protocols for X/Open PC Interworking: (PC)NFS (ISBN: 1-872630-00-6, D030), published by The Open Group.

XBD, Issue 4, Version 2

CAE Specification, August 1994, System Interface Definitions, Issue 4, Version 2 (ISBN: 1-85912-036-9, C434), published by The Open Group.

XCU, Issue 4, Version 2

CAE Specification, August 1994, Commands and Utilities, Issue 4, Version 2 (ISBN: 1-85912-034-2, C436), published by The Open Group.

XNS (Networking Services, Issue 4)

CAE Specification, August 1994, Networking Services, Issue 4 (ISBN: 1-85912-049-0, C438), published by The Open Group.

XPG3

X/Open Specification, 1988, 1989, February 1992 (ISBN: 1-872630-43-X, T921); this specification was formerly X/Open Portability Guide, seven volumes, January 1989 (ISBN: 0-13-685819-8, XO/XPG/89/000).

XSH, Issue 4, Version 2

CAE Specification, August 1994, System Interfaces and Headers, Issue 4, Version 2 (ISBN: 1-85912-037-7, C435), published by The Open Group.

International Standards

ISO 8859-1

ISO 8859-1:1987, Information Processing - 8-bit Single-byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1.

ISO/IEC 9945-1

ISO/IEC 9945-1:1990, Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language] (identical to IEEE Std 1003.1-1990).

Access to IETF RFCs

 

http://www.isi.edu/rfc-editor/
http://ds.internic.net/ds/rfc-index.html/

RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK, FTP.NCREN.NET, FTP.SESQUI.NET, FTP.NIC.IT, or FTP.IMAG.FR, using the FTP username anonymous and the FTP password guest For further information about Internet Protocols in general, please contact:

 

USC - Information Sciences Institute,
4676, Admiralty Way,
Marina del Rey, CA 90292-6695,
USA

Tel: (+1) 213-822-1511

Internet Protocol Suite RFCs

RFC 1140 - IAB Official Protocol Standards

IETF RFC 1140 gives the state of standardisation of protocols used in the Internet as determined by the Internet Activities Board (IAB). RFC 1140 was published in May 1990; this document is reissued on a regular basis, and the reader should obtain the current version as described above.

RFC 1011 - Official Internet Protocols

IETF RFC 1011 is the authoritative reference as to which document defines each protocol. RFC 1011 was published in May 1987; this document is reissued on a regular basis, and the reader should obtain the current version as described above.

The descriptions which follow are derived from RFC 1011.

RFC 791 - Internet Protocol (IP)

Status: Standard. IETF RFC 791 is the universal protocol of the Internet. This datagram protocol provides the universal addressing of hosts in the Internet.

RFC 792 - Internet Control Message Protocol (ICMP)

Status: Standard. IETF RFC 792 describes the control messages and error reports that go with the Internet Protocol.

Note:

ICMP is defined to be an integral part of IP. An implementation of IP is incomplete if it does not include ICMP.

RFC 768 - User Datagram Protocol (UDP)

Status: Standard. IETF RFC 768 provides a datagram service to applications. It adds port addressing to the IP services.

RFC 793 - Transmission Control Protocol (TCP)

Status: Standard. IETF RFC 793 provides a reliable end-to-end data stream service. Note that RFC 1011 includes many additions and clarifications to RFC 793, and refers to additional RFCs which go into greater detail on certain topics.

RFC 950 - Internet Subnet Protocol

Status: Standard. IETF RFC 950 specifies procedures for the use of subnets, which are logical sub-sections of a single Internet network.

RFC 826 - Address Resolution Protocol (ARP)

Status: Standard. IETF RFC 826 is a procedure for finding the network hardware address corresponding to an Internet Address.

RFC 997 - Internet Numbers

IETF RFC 997 describes the fields of network numbers and autonomous system numbers that are assigned specific values for actual use, and lists the currently assigned values.

RFC 1060 - Assigned Numbers

Status: Historic. IETF RFC 1060 describes the fields of various protocols that are assigned specific values for actual use, and lists the currently assigned values.

RFC 894 - Internet Protocol on Ethernet Networks

Status: Standard. IETF RFC 894 describes the representation of Internet Protocol services on Ethernet networks.

RFC 1011 (includes) Internet Protocol on IEEE 802

IETF RFC 1011 includes description of the latest policy on the transmission of IP datagrams on IEEE 802 networks.

All of the preceding material should be interpreted in accordance with the following two documents, which provide an authoritative policy on the way in which the various protocols should be implemented and administered:

RFC 1122 - Requirements for Internet Hosts - Communication Layers

IETF RFC 1122, R T Braden, October 1989. Status: Standard.

RFC 1123 - Requirements for Internet Hosts - Application and Support

IETF RFC 1123, R T Braden, October 1989. Status: Standard.

In addition, XDR, RPC and NFS are described in the following RFCs:

RFC 1014 - XDR: External Data Representation Standard

IETF RFC 1014, Sun Microsystems, June 1987.

RFC 1057 - RPC: Remote Procedure Call Protocol Specification, Version 2

IETF RFC 1057, Sun Microsystems. June 1988, Status: Informational.

RFC 1094 - NFS: Network File System Protocol Specification

IETF RFC 1094, Sun Microsystems. Mar-01-1989, Status: Informational.

RFC 1813 - NFS: Network File System Prococol, Version 3 Specification

IETF RFC 1813, B Callaghan, B Pawlowski & P Staubach, June 1995. Status: Informational.

RFC 1831 - RPC: Remote Procedure Call Protocol Specification Version 2

IETF RFC 1831, R Srinivasan, August 1995. Status: Proposed Standard.

RFC 1832 - XDR: External Data Representation Standard.

IETF RFC 1832, R Srinivasan, August 1995. Status: Proposed Standard.

RFC 1833 - Binding Protocols for ONC RPC Version 2

IETF RFC 1833, R Srinivasan, August 1995. Status: Proposed Standard.

WebNFS-relevant RFCs

RFC 1738 - Uniform Resource Locators (URL)

IETF RFC 1738, T Berners-Lee, L Masinter & M McCahill. December 1994, Status: Proposed Standard. This document describes the syntax and semantics of absolute Uniform Resource Locators, which can be used for the location and access of resources via the Internet.

RFC 1808 - Relative Uniform Resource Locators

IETF RFC 1808, R Fielding. June 1995, Status: Proposed Standard. This document describes the syntax and semantics of relative Uniform Resource Locators. Relative URLs can be used for the location and access of resources relative to an absolute URL.

RFC 2054 - WebNFS Client Specification

IETF RFC 2054, B Callaghan. October 1996, Status: Informational. This document describes the procedure that a WebNFS client uses to access an NFS server.

RFC 2055 - WebNFS Server Specification

IETF RFC 2055, B Callaghan, October 1996, Status: Informational. This document describes the features that are required of a WebNFS server.

RFC 2224 - NFS URL Scheme

IETF RFC 2224, B Callaghan, October 1997, Status: Informational. This document describes a URL scheme used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738.

Other Documents

Andrew D. Birrell and Bruce Jay Nelson, Implementing Remote Procedure Calls, XEROX CSL-83-7, October 1983.

Danny Cohen, On Holy Wars and a Plea for Peace, IEEE Computer, October 1981.

Courier: The Remote Procedure Call Protocol, XEROX Corporation, XSIS 038112, December 1981.

Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, Bell Laboratories, Murray Hill, New Jersey, 1978.

J. Postel, Transmission Control Protocol - DARPA Internet Program Protocol Specification, RFC 793, Information Sciences Institute, September 1981.

J. Postel, User Datagram Protocol, RFC 768, Information Sciences Institute, August 1980.

Disk Operating System Technical Reference, IBM part no. 6138536.