Subject: typos/spellos

From: Jim Rees <[email-masked]>
Date: Fri, 30 Aug 2002 13:07:54 -0400

After adding the tenth item to my typo list, I decided to spellcheck the
draft.

Here are a couple of issues to decide:

Mount point, one word or two?  We do it both ways, should probably strive
for consistency.

I changed all "requestors" to "requesters."  Ok?

--- rfc3010bis-05.txt	Mon Aug 12 13:38:40 2002
+++ rfc-ispell	Fri Aug 30 13:06:06 2002
@@ -502,7 +502,7 @@
    Instead of using the older MOUNT protocol for this mapping, the
    server provides a ROOT filehandle that represents the logical root or
    top of the filesystem tree provided by the server.  The server
-   provides multiple filesystems by glueing them together with pseudo
+   provides multiple filesystems by gluing them together with pseudo
    filesystems.  These pseudo filesystems provide for potential gaps in
    the path names between real filesystems.
 
@@ -1050,7 +1050,7 @@
              x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
 
         The suffix "p1.p2" is the service port, and is computed the same
-        way as with univeral addresses for TCP and UDP over IPv4. The
+        way as with universal addresses for TCP and UDP over IPv4. The
         prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form
         for representing an IPv6 address as defined in Section 2.2 of
 
@@ -1451,7 +1451,7 @@
 
    For AUTH_NONE, there are no principals, so this is a non-issue.
 
-   AUTH_SYS has no notions of mutual authentation or a server principal,
+   AUTH_SYS has no notions of mutual authentication or a server principal,
    so the callback from the server simply uses the AUTH_SYS credential
    that the user used when he set up the delegation.
 
@@ -1700,7 +1700,7 @@
    filehandle comparisons only to improve performance, not for correct
    behavior.  All clients need to be prepared for situations in which it
    cannot be determined whether two filehandles denote the same object
-   and in such cases, avoid making invalid assumpions which might cause
+   and in such cases, avoid making invalid assumptions which might cause
    incorrect behavior.  Further discussion of filehandle and attribute

@@ -2607,10 +2607,10 @@
    the corresponding time_access_set attribute is another way to modify
    the time_access attribute.
 
-   Whenever the file object resides on a writeable filesystem, the
+   Whenever the file object resides on a writable filesystem, the
    server should make best efforts to record time_access into stable
    storage.  However, to mitigate the performance effects of doing so,
-   and most especially whenever the server is satisifying the read of
+   and most especially whenever the server is satisfying the read of
    the object's content from its cache, the server MAY cache access time
    updates and lazily write them to stable storage.  It is also
    acceptable to give administrators of the server the option to disable
@@ -2817,8 +2817,8 @@
    is encountered where the requester's access still has unALLOWED bits
    in common with the "access_mask" of the ACE, the request is denied.
    However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT
-   ACE types do not affect a requestor's access, and instead are for
-   triggering events as a result of a requestor's access attempt.
+   ACE types do not affect a requester's access, and instead are for
+   triggering events as a result of a requester's access attempt.
    Therefore, all AUDIT and ALARM ACEs are processed until end of the
    ACL.
 
@@ -3052,7 +3052,7 @@
    ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
    (ALARM) ACE types. If during the processing of the file's ACL, the
    server encounters an AUDIT or ALARM ACE that matches the principal
-   attempting the OPEN, the server notes that fact, and the prescence,
+   attempting the OPEN, the server notes that fact, and the presence,
    if any, of the SUCCESS and FAILED flags encountered in the AUDIT or
    ALARM ACE. Once the server completes the ACL processing, and the
    share reservation processing, and the OPEN call, it then notes if the
@@ -3800,7 +3800,7 @@
    used to detect client reboots. Only if the verifier is different from
    that the server has previously recorded the client (as identified by
    the second field f the structure, id) does the server start the
-   process of cancelling the client's leased state.
+   process of canceling the client's leased state.
 
    The second field, id is a variable length string that uniquely
    defines the client.
@@ -3812,7 +3812,7 @@
         present the same string. The consequences of two clients
         presenting the same string range from one client getting an
         error to one client having its leased state abruptly and
-        unexpectedly cancelled.
+        unexpectedly canceled.
 
    o    The string should be selected so the subsequent incarnations
         (e.g. reboots) of the same client cause the client to present
@@ -3902,7 +3902,7 @@
    Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has successfully
    completed, the client uses the short hand client identifier, of type
    clientid4, instead of the longer and less compact nfs_client_id4
-   structure.  This short hand client identfier (a clientid) is assigned
+   structure.  This short hand client identifier (a clientid) is assigned
    by the server and should be chosen so that it will not conflict with
    a clientid previously assigned by the server.  This applies across
    server restarts or reboots.  When a clientid is presented to a server
@@ -4084,7 +4084,7 @@
    "mandatory lock bit" on the mode attribute such that if set, record
    locks are required on the file before I/O is possible).  When record
    locks are advisory, they only prevent the granting of conflicting
-   lock requests and have no effect on READ's or WRITE's.  Mandatory
+   lock requests and have no effect on READs or WRITEs.  Mandatory
    record locks, however, prevent conflicting I/O operations.  When they
    are attempted, they are rejected with NFS4ERR_LOCKED. Assuming an
    operating environment like UNIX that requires it, when the client
@@ -4133,23 +4133,23 @@
    OPEN_DOWNGRADE), or by a LOCK-type operation (i.e. LOCK or LOCKU),
    defines an access mode for the file (i.e. READ, WRITE, or READ-WRITE)
    as established by the original OPEN which began the stateid sequence,
-   and as modified by subsequent OPEN's and OPEN_DOWNGRADE's within that
+   and as modified by subsequent OPENs and OPEN_DOWNGRADEs within that
    stateid sequence.  When a READ, WRITE, or SETATTR which specifies the
    size attribute, is done, the operation is subject to checking against
    the access mode to verify that the operation is appropriate given the
    OPEN with which the operation is associated.
 
-   In the case of WRITE-type operations (i.e. WRITE's and SETATTR's
+   In the case of WRITE-type operations (i.e. WRITEs and SETATTRs
    which set size), the server must verify that the access mode allows
    writing and return an NFS4ERR_OPENMODE error if it does not.  In the
    case, of READ, the server may perform the corresponding check on the
    access mode, or it may choose to allow READ on opens for WRITE only,
    to accommodate clients whose write implementation may unavoidably do
    reads (e.g. due to buffer cache constraints).  However, even if
-   READ's are allowed in these circumstances, the server MUST still
+   READs are allowed in these circumstances, the server MUST still
    check for locks that conflict with the READ (e.g. another open
-   specify denial of READ's).  Note that a server which does enforce the
-   access mode check on READ's need not explicitly check for conflicting
+   specify denial of READs).  Note that a server which does enforce the
+   access mode check on READs need not explicitly check for conflicting
    share reservations since the existence of OPEN for read access
    guarantees that no conflicting share reservation can exist.
 
@@ -4872,7 +4872,7 @@
    Servers may avoid this complexity, at the cost of less complete
    protocol error checking, by simply responding NFS4_OK in the event of
    a CLOSE for a deallocated stateid, on the assumption that this case
-   must be caused by a retranmitted close.  When adopting this approach,
+   must be caused by a retransmitted close.  When adopting this approach,
    it is desirable to at least log an error when returning a no-error
    indication in this situation.  If the server maintains a reply-cache
    mechanism, it can verify the CLOSE is indeed a retransmission and
@@ -4888,7 +4888,7 @@
    OPEN.  The result is that there is one open file, as far as the
    protocol is concerned, and it includes the union of the access and
    deny bits for all of the OPEN requests completed.  Only a single
-   CLOSE will be done to reset the effects of both OPEN's.  Note that
+   CLOSE will be done to reset the effects of both OPENs.  Note that

 Expires: February 2003                                         [Page 83]
@@ -4897,21 +4897,21 @@

    the client, when issuing the OPEN, may not know that the same file is
-   in fact being opened.  The above only applies if both OPEN's result
-   in the OPEN'ed object being designated by the same filehandle.
+   in fact being opened.  The above only applies if both OPENs result
+   in the OPENed object being designated by the same filehandle.
 
    When the server chooses to export multiple filehandles corresponding
    to the same file object and returns different filehandles on two
-   different OPEN's of the same file object, the server MUST NOT "OR"
+   different OPENs of the same file object, the server MUST NOT "OR"
    together the access and deny bits and coalesce the two open files.
-   Instead the server must maintain separate OPEN's with separate
-   stateid's and will require separate CLOSE's to free them.
+   Instead the server must maintain separate OPENs with separate
+   stateids and will require separate CLOSEs to free them.
 
    When multiple open files on the client are merged into a single open
    file object on the server, the close of one of the open files (on the
    client) may necessitate change of the access and deny status of the
    open file on the server.  This is because the union of the access and
-   deny bits for the remaining open's may be smaller (i.e. a proper
+   deny bits for the remaining opens may be smaller (i.e. a proper
    subset) than previously.  The OPEN_DOWNGRADE operation is used to
    make the necessary change and the client should use it to update the
    server so that share reservation requests by other clients are
@@ -4966,7 +4966,7 @@
    The server's lease period configuration should take into account the
    network distance of the clients that will be accessing the server's
    resources.  It is expected that the lease period will take into
-   account the network propogation delays and other network delay
+   account the network propagation delays and other network delay
    factors for the client population.  Since the protocol does not allow
    for an automatic method to determine an appropriate lease period, the
    server's administrator may have to tune the lease period.
@@ -4978,8 +4978,8 @@
    to a new server (migration) or the client chooses to use an alternate
    server (e.g. in response to server unresponsiveness) in the context
    of file system replication, the appropriate handling of state shared
-   between the client and server (i.e. locks, leases, stateid's, and
-   clientid's) is as described below.  The handling differs between
+   between the client and server (i.e. locks, leases, stateids, and
+   clientids) is as described below.  The handling differs between
    migration and replication.  For related discussion of file server
    state and recover of such see the sections under "File Locking and
    Share Reservations"
@@ -5001,9 +5001,9 @@
    new server.  This must be done in a way that is transparent to the
    client.  This state transfer will ease the client's transition when a
    filesystem migration occurs.  If the servers are successful in
-   transferring all state, the client will continue to use stateid's
+   transferring all state, the client will continue to use stateids
    assigned by the original server.  Therefore the new server must
-   recognize these stateid's as valid.  This holds true for the clientid
+   recognize these stateids as valid.  This holds true for the clientid
    as well.  Since responsibility for an entire filesystem is
    transferred with a migration event, there is no possibility that
    conflicts will arise on the new server as a result of the transfer of
@@ -5041,7 +5041,7 @@
 
    Since client switch-over in the case of replication is not under
    server control, the handling of state is different.  In this case,
-   leases, stateid's and clientid's do not have validity across a
+   leases, stateids and clientids do not have validity across a
    transition from one server to another.  The client must re-establish
    its locks on the new server.  This can be compared to the re-
    establishment of locks by means of reclaim-type requests after a
@@ -5529,7 +5529,7 @@
    server if the revalidation procedure shows that the data which the
    client possesses may not be valid.
 
-   The data that is written to the server as a pre-requisite to the
+   The data that is written to the server as a prerequisite to the
    unlocking of a region must be written, at the server, to stable
    storage.  The client may accomplish this either with synchronous
    writes or by following asynchronous writes with a COMMIT operation.
@@ -5948,7 +5948,7 @@
         modified at the client and most likely will be modified at the
         server at a future time.  The server then uses the current time
         to construct attributes values for change and time_modify and
-        returns those values to the requestor.
+        returns those values to the requester.
 
    o    In the case that the file attribute size is different than the
 
@@ -7158,7 +7158,7 @@
 
    NFS4ERR_RESOURCE      For the processing of the COMPOUND procedure,
                          the server may exhaust available resources and
-                         can not continue processing operationss within
+                         can not continue processing operations within
                          the COMPOUND procedure.  This error will be
                          returned from the server in those instances of
                          resource exhaustion related to the processing
@@ -9952,7 +9952,7 @@
                            If it does support CLAIM_DELEGATE_PREV,
                            SETCLIENTID_CONFIRM MUST NOT remove the
                            client's delegation state, and the
-                           server MUST support the DELEGEPURGE
+                           server MUST support the DELEGPURGE
                            operation.

@@ -9996,7 +9996,7 @@
      When an OPEN is done and the specified lockowner already has the
      resulting filehandle open, the result is to "OR" together the new
      share and deny status together with the existing status.  In this
-     case, only a single CLOSE need be done, even though multiple OPEN's
+     case, only a single CLOSE need be done, even though multiple OPENs
      were completed.  When such an OPEN is done, checking of share
      reservations for the new OPEN proceeds normally, with no exception
      for the existing OPEN held by the same lockowner.
@@ -10105,19 +10105,19 @@
      do this, the server must return NFS4ERR_INVAL.
 
      Based on the access value (READ, WRITE, or BOTH) the client should
-     check that the requestor has the proper access rights to perform
+     check that the requester has the proper access rights to perform
      the specified operation.  This would generally be the results of
      applying the ACL access rules to the file for the current
-     requestor.  However, just as with the ACCESS operation, the client
+     requester.  However, just as with the ACCESS operation, the client
      should not attempt to second-guess the server's decisions, as
      access rights may change and may be subject to server
      administrative controls outside the ACL framework.  If the
-     requestor is not authorized to READ or WRITE (depending on the
+     requester is not authorized to READ or WRITE (depending on the
      access value), the server must return NFS4ERR_ACCESS.  Note that
      since the NFS version 4 protocol does not impose any requirement
-     that READ's and WRITE's issued for an open file have the same
+     that READs and WRITEs issued for an open file have the same
      credentials as the OPEN itself, the server still must do
-     appropriate access checking on the READ's and WRITE's themselves.
+     appropriate access checking on the READs and WRITEs themselves.
 
      If the component provided to OPEN is a symbolic link, the error
      NFS4ERR_SYMLINK will be returned to the client.  If the current
@@ -10403,7 +10403,7 @@
      no longer has a record of the open_owner4, the server needs ensure
      that this is a new OPEN and not a replay or retransmission.
 
-     Servers must not require confirmation on OPEN's that grant
+     Servers must not require confirmation on OPENs that grant
      delegations or are doing reclaim operations.  See section "Use of
      Open Confirmation" for details.  The server can easily avoid this
      by noting whether it has disposed of one open_owner4 for the given
@@ -10447,7 +10447,7 @@

      open_owner4 within the lease period.  In this case, the OPEN state
-     is cancelled and disposal of the open_owner4 can occur.
+     is canceled and disposal of the open_owner4 can occur.

    ERRORS
@@ -10542,14 +10542,14 @@
      This operation is used to adjust the access and deny bits for a
      given open.  This is necessary when a given lockowner opens the
      same file multiple times with different access and deny flags.  In
-     this situation, a close of one of the open's may change the
+     this situation, a close of one of the opens may change the
      appropriate access and deny flags to remove bits associated with
-     open's no longer in effect.
+     opens no longer in effect.
 
      The access and deny bits specified in this operation replace the
      current ones for the specified open file.  The access and deny bits
      specified must be exactly equal to the union of the access and deny
-     bits specified for some subset of the OPEN's in effect for current
+     bits specified for some subset of the OPENs in effect for current
      openowner on the current file.  If that constraint is not
      respected, the error NFS4ERR_INVAL should be returned.  Since
      access and deny bits are subsets of those already granted, it is
@@ -10650,7 +10650,7 @@
      Replaces the current filehandle with the filehandle provided as an
      argument.
 
-     If the security mechanism used by the requestor does not meet the
+     If the security mechanism used by the requester does not meet the
      requirements of the filehandle provided to this operation, the
      server MUST return NFS4ERR_WRONGSEC.
 
@@ -12040,7 +12040,7 @@

      methodology used for LOOKUP when evaluating the name.  Therefore,
-     if the requestor does not have the appropriate access to LOOKUP the
+     if the requester does not have the appropriate access to LOOKUP the
      name then SECINFO must behave the same way and return
      NFS4ERR_ACCESS.
 
@@ -12281,7 +12281,7 @@
      should allow the operation to succeed if the current owner of the
      object matches the value specified in the request.  Some servers
      may be implemented in a way as to prohibit the setting of the owner
-     attribute unless the requestor has privilege to do so.  If the
+     attribute unless the requester has privilege to do so.  If the
      server is lenient in this one case of matching owner values, the
      client implementation may be simplified in cases of creation of an
      object followed by a SETATTR.
@@ -12337,7 +12337,7 @@
      If the server does not support an attribute as requested by the
      client, the server should return NFS4ERR_ATTRNOTSUPP.
 
-     A mask of the attibutes actually set is returned by SETATTR in all
+     A mask of the attributes actually set is returned by SETATTR in all
      cases.  That mask must not include attributes bits not requested to
      be set by the client, and must be equal to the mask of attributes
      requested to be set only if the SETATTR completes without error.
@@ -12699,7 +12699,7 @@
      is a value of type clientid4, and s is a value of type verifier4
      corresponding to the setclientid_confirm field.
 
-     As with SETCLIENTID, SETCLIENTID_CONFIRM is a nonidempotent
+     As with SETCLIENTID, SETCLIENTID_CONFIRM is a non-idempotent
      operation, and we assume that the server is implementing the
      duplicate request cache (DRC).
 
@@ -12790,7 +12790,7 @@
      higher than the server's lease time period. Consider that leases
      need to be renewed before the lease time expires via an operation
      from the client.  If the client cannot issue a SETCLIENTID_CONFIRM
-     after a SETCLIENTID before a perod of time equal to that of a lease
+     after a SETCLIENTID before a period of time equal to that of a lease
      expires, then the client is unlikely to be able maintain state on
      the server during steady state operation.
 
@@ -12814,7 +12814,7 @@
      that state does not include existing delegations, the server MUST
      allow the client a period of time no less than the value of
      lease_time attribute, to reclaim, (via the CLAIM_DELEGATE_PREV
-     claim tpe of the OPEN operation) its delegations before removing
+     claim type of the OPEN operation) its delegations before removing
      unreclaimed delegations.

@@ -13587,7 +13587,7 @@
      failed.
 
      For the definition of the "tag" field, see the section "Procedure
-     1:  COMPOUND - Compound Operatoins".
+     1:  COMPOUND - Compound Operations".
 
      The value of callback_ident is supplied by the client during
      SETCLIENTID.  The server must use the client supplied
@@ -14125,7 +14125,7 @@
            NFS4ERR_NOTSUPP         = 10004,/* operation not supported */
            NFS4ERR_TOOSMALL        = 10005,/* buffer too small        */
            NFS4ERR_SERVERFAULT     = 10006,/* undefined server error  */
-           NFS4ERR_BADTYPE         = 10007,/* type invalide for CREATE*/
+           NFS4ERR_BADTYPE         = 10007,/* type invalid for CREATE*/
            NFS4ERR_DELAY           = 10008,/* file "busy" - retry     */
            NFS4ERR_SAME            = 10009,/* nverify says attrs same */
            NFS4ERR_DENIED          = 10010,/* lock unavailable        */
@@ -14155,7 +14155,7 @@
            NFS4ERR_RECLAIM_BAD     = 10034,/* reclaim error at server */
            NFS4ERR_RECLAIM_CONFLICT = 10035,/* conflict on reclaim    */
            NFS4ERR_BADXDR          = 10036,/* XDR decode failed       */
-           NFS4ERR_LOCKS_HELD      = 10037,/* file lcoks held at CLOSE*/
+           NFS4ERR_LOCKS_HELD      = 10037,/* file locks held at CLOSE*/

 Expires: February 2003                                        [Page 240]