Subject: Upcoming draft-07 for NFSv4

From: Spencer Shepler <[email-masked]>
Date: Fri, 07 Apr 2000 12:05:22 -0500

Vern Paxson, our (ex)area advisor, has completed his review
of draft-ietf-nfsv4-06.txt and supplied the authors with
his comments (I have included them below).  Nothing major but
the document does need to be updated. 

I will be working on that update and intend to have it completed
as soon as possible.  Since the document will receive and update,
I will take the opportunity to add the couple of error codes that
are missing and update the VERIFY/NVERIFY ops to remove the
redundant bitmap.  I will keep the WG updated as to my changes
and progress.

Spencer

p.s. Also included below are David Robinson's response to some
of Vern's original issues.

-------------------------
[Vern's original comments]

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>    Lease     An interval of time defined by the server for which the
>              client is irrevokeably granted a lock.  At the end of a

typo, irrevocably

>              All leases granted by a server have the same fixed
>              interval.

Why is this?  (It may be explained later, but I don't recall.  If so,
perhaps it would help to add here "(for reasons explained in section X.Y)".

>         This data type is used to pass time and date information.  A
>         server converts to and from local time when processing time
>         values, preserving as much accuracy as possible. If the

It's easy to misread this sentence as saying something about time zones
(i.e., presuming that the server stores time in the local time zone).
Perhaps fixed with somethiung like "to and from its local representation
of time"?

>         set time values.  If set_it is SET_TO_SERVER_TIME4, then the
>         server uses its local time for the time value.

(same here)

>    If TCP is used as the transport, the client and server SHOULD use
>    persistent connections.  This will prevent the weakening of TCP's
>    congestion control via short lived connections.

It also improves performance (no SYN handshake required), a major win
over a WAN.

>    a filehandle for another file system object.  If the server needs to
>    reuse a filehandle value, the time elapsed before reuse SHOULD be
>    large enough that it is likely the client no longer has a cached copy
>    of the reused filehandle value.

What's a recommended value for "large enough"?

>    FH4_VOLATILE_ANY
>         The filehandle may expire at any time and will expire on during

expire on -> expire

>    Servers which provide volatile filehandles should deny a RENAME or
>    REMOVE that would effect an OPEN file or any of the components

effect -> affect

>    cansettime         15   boolean        READ     Whether or not this
>                                                    object's file system
>                                                    can fill in the times
>                                                    on a SETATTR request
>                                                    without an explicit
>                                                    time.

It's not clear what this means ("without an explicit time").

>    case_insensitive   16   boolean        READ     Are filename
>                                                    comparisons on this
>                                                    file system case
>                                                    insensitive?
> 
>    case_preserving    17   boolean        READ     Is filename case on
>                                                    this file system
>                                                    preserved?

Are these well-defined for non-ASCII character sets?

>    homogeneous        26   boolean        READ     Whether or not this
>                                                    object's file system
>                                                    is homogeneous, i.e.
>                                                    whether pathconf is
>                                                    the same for all file
>                                                    system objects.

"pathconf" is not defined.

>    numlinks           35   uint32         READ     Number of links to
>                                                    this object.

Might clarify that these are hard links.

>    owner_group        37   utf8<>         R/W      The string name of
>                                                    the group of the
>                                                    owner of this object.

This is confusing - it sounds like it's the owner's group, but instead
it should be the group associated with the object, right?

>    rawdev             41   specdata4      READ     Raw device
>                                                    identifier.

What is this used for?  Things like "df" output?

>    time_access        47   nfstime4       READ     The time of last
>                                                    access to the object.
> 
>    time_access_set    48   settime4       WRITE    Set the time of last
>                                                    access to the object.
>                                                    SETATTR use only.
> 
>    time_backup        49   nfstime4       R/W      The time of last
> ...
>    time_create        50   nfstime4       R/W      The time of creation
>                                                    of the object. This

How come there aren't _set forms for backup and create?  Seems both
are needed, particularly time_backup.

>    quota_avail_soft
>         The value in bytes which represents the amount of additional
>         disk space that can be allocated to this file or directory
>         before the user may reasonably be warned.  It is understood that
>         this space may be consumed by allocations to other files or
>         directories though there is a rule as to which other files or
>         directories.

What does it matter that there's a rule regarding which other files?

>    quota_avail_hard
>         The value in bytes which represent the amount of additional disk
>         space beyond the current allocation that can be allocated to
>         this file or directory before further allocations will be
>         declined.  It is understood that this space may be consumed by

"declined" reads more easily as "refused", otherwise it can be confused
with lowering the quota.

>    ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
> 
>    ACL4_FAILED_ACCESS_ACE_FLAG
> 
>    Both indicate for AUDIT and ALARM which state to log the event.  On
>    every ACCESS or OPEN call which occurs on a file or directory which
>    has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or
>    ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the
>    ace4mask of these ACLs. If the access is a subset of ace4mask and the
>    identifier match, an AUDIT trail or an ALARM is generated.  By
>    default this happens regardless of the success or failure of the
>    ACCESS or OPEN call.

The last sentence is confusing.  If it happens "regardless of the success
or failure of the ACCESS or OPEN call", then why are there "SUCCESSFUL" and
"FAILED" variants?

>    The bitmask constants used to for the flag field are as follows:

used to for -> used for

>    DELETE                 Permission to Delete the File

downcase "File"

>    SYNCHRONIZE            Permission to access file locally at the
>                           server with synchronous reads and writes

This needs some elaboration.  Why does it matter whether the local access
is synchronous or asynchronous?  Is there any ACE associated with the latter?

>    The bitmask constants used to for the access mask field are as

used to for -> used for

>    Who                    Description
>    _______________________________________________________________
>    "OWNER"                The owner of the file.
>    "GROUP"                The group associated with the file.
>    "EVERYONE"             The world.
>    "INTERACTIVE"          Accessed from an interactive terminal.
>    "NETWORK"              Accessed via the network.
>    "DIALUP"               Accessed as a dialup user to the server.
>    "BATCH"                Accessed from a batch job.
>    "ANONYMOUS"            Accessed without any authentication.
>    "AUTHENTICATED"        Any authenticated user (opposite of
>                           ANONYMOUS)
>    "SERVICE"              Access from a system service.

These smack of legacy support.  If so, it would be helpful to identify
which systems are being supported.

>    If the client requests more attributes than fs_locations, the server

Reads easier if it's "more attributes than [just] fs_locations"

>    The server implementor needs to be careful in developing a migration
>    solution.  The server must consider all of the state information
>    clients may have outstanding at the server.  This includes but is not
>    limited to locking/share state, delegation state, and asynchronous
>    file writes which are represented by WRITE and COMMIT verifiers.  The

Are there any others known besides the "includes but is not limited to" list?
It's the "not limited to" that threw me ...

>    properly.  However with the support of multiple security mechanisms

Comma after However

>         systems have the same address.  In this case, the result is
>         a switched union that returns in addition to
>         NFS4ERR_CLID_INUSE, the network address (the rpcbind netid

Add comma: "returns, in addition"

>         the request is returned in error.  For more discussion of
>         crash recovery semantics, see the section on "Crash
>         Recovery"

Add period.

>         To mitigate retransmission of the SETCLIENTID operation,
>         the client and server use a confirmation step.  The server
>         returns a confirmation verifier that the client then sends
>         to the server in the SETCLIENTID_CONFIRM operation.  Once
>         the server receives the confirmation from the client, the
>         locking state for the client is released.

The need for the confirmation needs to be clarified using an example.

>    receives a NFS4ERR_STALE_STATEID error using a stateid derived from
>    its current clientid since this also indicates a server reboot which

add comma after clientid

>    If the server determines that the client holds no associated state
>    for its clientid and no activity from that client has been received
>    some long period of time, the server may choose to release the

Need advice on the suggested "long period of time".

>    clients.  If the client contacts the server after the this release,

the this -> this

>    locked range, the stateid (previously returned by the server) must be
>    used to indicate that appropriate lock (record or share) is held.  If

that the appropriate lock

>    Locking is different than most NFS operations as it requires "at-
>    most-one" semantics that are not provided by ONCRPC.  In the face of

Mention here that even if over TCP, retransmissions can occur due to
failed-and-then-reestablished TCP connections.

>    If a request with a previous sequence number (r < L) is received, it
>    is rejected with the return of error NFS4ERR_BAD_SEQID.  Given a
>    properly-functioning client, the response to (r) must have been
>    received before the last request (L) was sent.  If a duplicate of

Can't there in principle be concurrent RPCs, which means that a response
might not have been received before the last request was sent?

>    The client is discouraged from coalescing adjacent ranges since the
>    server may not support sub-range requests and for reasons related to

Not clear what it means here to coalesce an adjacent range.

>    The server should take care in the length of delay in the event the
>    client retransmits the request.

This shouldn't happen when using TCP, other than for TCP connection failure,
which takes many minutes to occur.

>    Clients should be prepared for the return of NFS4ERR_GRACE errors for
>    non-reclaim lock and I/O requests.  In this case the client should
>    employ a backoff and retry mechanism for the request.  Timeout

Need more specifics explaining how the backoff should work.  (Should it
be exponential?)

>    In the event of a network partition with a duration extending beyond
>    the expiration of a client's leases, the server MUST employ a method
>    of recording this fact in its stable storage.  Conflicting locks

How can the server know if there's a network partition?  It looks the same
as the client being down, from its perspective.

>    by the client.  As a result of revocation, the client will receive an
>    error of NFS4ERR_EXPIRED and the error is received within the lease
>    period for the lock.  In this instance the client may assume that

Seems there's a race here - "within the least period of the lock" isn't
tightly defined.  This is worth commenting on even if it really shouldn't
come up in practice (in which case, that's part of the comment).

>    The LOOKUP operation is preserved and will return a filehandle

Unclear what "preserved" means here.

>    In the event the client reboots or restarts, the failure to renew
>    leases will result in the revocation of record locks and share
>    reservations.  Delegations, however, may treated a bit differently.

may treated -> may be treated

>    with these delegations will need to wait.  This behavior is
>    consistent with the normal recall process may take significant time
>    because of the client's need to flush state to the server.  This

"This behavior" sentence is quite hard to parse.

>         achieve its purpose.  The other aspect to flushing the data
>         before close is that the data must be committed to stable
>         storage before the CLOSE operation is requested by the client.

It's unclear whether this means committed to stable storage *locally at
the client* or *on the server*.  Presumably, it's the latter, since the
client might not have any stable storage.  This occurs again later:

>    The data that is written to the server as a pre-requisite to the
>    unlocking of a region must be written to stable storage.  The client

>    the request using the client's validated cache.  If an appropriate
>    file lock is not held for the range of the read or write, the read or
>    write request must not be satisfied by the client's cache and the
>    request sent to the server for processing.  When a read or write

"request [must be] sent to the server ..."

>    o    For a write open delegation, if, at the time of recall, if the
>         file is not open for write, all modified data for the file must
>         be flushed to the server.  If the delegation had not existed,

"if ... if" in the first sentence scans awkwardly.

>         ... If the delegation had not existed,
>         the client would have done this data flush before the CLOSE
>         operation.

This is at odds with the last bullet:

>    o    Any modified data for the file needs to be flushed to the the
>         server.

which sounds like the flush is done anyway.

Also, "the the" -> "the"

>    In the case of modified data existing in the client's cache, that
>    data must be removed from the client without it being written to the
>    server.

Explain why this is necessary.

>    open file or on the close.  Where the methods available to a client
>    to make such notification impossible because errors for certain

"to make" -> "make"

>    READDIR operations.  Just as in the cases of attribute and name
>    caching inconsistencies may arise among the various client caches.

add comma after "caching"

>    To mitigate the effects of these inconsistencies and given the
>    context of typical file system APIs, the following rules should be
>    followed:

Add comma after "inconsistencies"

>    are are consecutively allocated), and normalize their offsets to a

are are -> are

>    table that fits in 7 bits.  Thus it is determined that "lower case
>    alpha" is in the same position as "upper case a" in the US-ASCII
>    table, and "upper case alpha" is in the same position as "lower case
>    a" in the US-ASCII table.

Is it really backwards as this sentence says, that lower case alpha is
in the same position as *upper* case a, and vice versa?

>    If the NFS version 4 protocol used a universal 16 bit or 32 bit
>    character set (or a encoding of a 16 bit or 32 bit character set into

a encoding -> an encoding

>    UTF       UCS transformation format.

Explain what this means.

>    a status code (normally zero).  If an operation results in a non-zero
>    status code, the status will be encoded and evaluation of the
>    compound sequence will halt and the reply will be returned.

(You might add that this is even for de facto "non error" conditions,
such as NFS4ERR_SAME.)

>    When an operation is successfully completed at the server, the client
>    can depend that any data associated with the request is now on stable
>    storage.  This implies that any previous operations within the same

Need to qualify this with the possibility of doing an UNSTABLE4 write.
Otherwise the reader wonders whether all writes have to be synchronous.

>      series of operations.  This is useful in operating systems (such as
>      UNIX) where permission checking is done only when a directory is
>      opened.  The intent is to make the behavior of opening a remote
>      file more consistent with the behavior of opening a local file.

I didn't understand the comment about permission checking; perhaps because
I have only the UNIX model in my head, so it might help to add an example
from another OS.

>      This operation should also be used by clients which do have
>      delegation information on stable storage after doing all of
>      delegation recovery that is needed.  Using DELEGPURGE will prevent

I found this sentence confusing.

> 14.2.1.  Operation 3: ACCESS - Check Access Rights

It doesn't say what happens to the current file handle for a call to ACCESS.
There are some others for which this is missing, I believe, too.

>      Operations that change the current filehandle like LOOKUP or CREATE
>      do not automatically return the new filehandle as a result.  For

(why don't they?  Because the old filehandle is often handy to still have
around?)

> 14.2.9.  Operation 11: LINK - Create Link to a File

There shoud probably be a cross-pointer here to CREATE and symbolic links.

>      In the case that the lock is denied, the the owner, offset, and

the the -> the

>              PUTFH  (directory filehandle)
>              LOOKUP "pub"
>              GETFH
>              LOOKUP "foo"
>              GETFH
>              LOOKUP "bar"
>              GETFH

Explain why the GETFH's are needed.

>      directory is a server mountpoint.  Unix clients that detect a
>      mountpoint crossing will need to mount the server's filesystem.

Explain why they need to - seems the server will happily continue serving
them even though they've crossed a mountpoint.

>      In the case that a client issues an OPEN operation and the server
>      no longer has a record of the nfs_lockowner, the server needs
>      ensure that this is a new OPEN and not a replay or retransmission.
> 
>      A lazy server implementation might require confirmation for every
>      nfs_lockowner for which it has no record.  However, this is not
>      necessary until the server records the fact that it has disposed of
>      one nfs_lockowner for the given clientid.

It would help to explain exactly what problem we're trying to avoid here
(what might happen).

>      first one is a replay.  The server cancels the OPEN state of the
>      first OPEN requests, establishes an unconfirmed OPEN state for the

requests -> request

>    The access and deny bits speicifed in this operation replace the

speicifed -> specified

>    are subsets of those already granted, it is is not possible for this
>    request to denied because of conflicting share reservations.

is is -> is
to denied -> to be denied

>      If the read ended at the end-of-file (formally, in a correctly
>      formed READ request, if offset + count is equal to the size of the
>      file), eof is returned as TRUE; otherwise it is FALSE. A successful
>      READ of an empty file will always return eof as TRUE.

This sounds like the case of attempting read beyond the end of the file
(offset + count > size of the file) will return EOF as FALSE.  Is
that right??

>      data. If the server returns less than the count requested and eof
>      set to FALSE, the client should issue another READ to get the

eof set -> eof is set
        reads more clearly

>      several circumstances. The file may have been truncated by another
>      client or perhaps on the server itself, changing the file size from
>      what the requesting client believes to be the case. This would

Another possibility is that the client hasn't bothered to computed exactly
what size reads it should issue to precisely consume the file, right?

>      This value is the XDR encoded length of the name of the directory
>      entries and the cookie value for the entries.  The server may

It's easy to misread this sentence as saying "the value is itself XDR
encoded, and it's a length" rather than "the value is a length of an
XDR-encoded object"

>      On successful return, the server's response will provide a list of
>      directory entries.  Each of these entries contains the name of the
>      directory entry, a cookie value for that entry, and the associated

Each entry has a cookie?  Why?  So the client can pick up reading at
any one of them?  Is that indeed needed?

>      Ideally, the cookie value should not change if the directory is
>      modified.

Explain why - what happens if it does?

>      response.  To enable some client environments, the cookie values of
>      0, 1, and 2 are to be considered reserved.  For READDIR arguments,

How can the client care about these magic cookie values, when it's already
stated that they're opaque to the client?  It sounds like something more
is going on here (i.e., a particular legacy feature/hack is being supported),
and it would be helpful to spell it out.

>      Since the server will not be returning "." and ".." entries as has

Since the server -> Since some servers

>      The READLINK operation is only allowed on objects of type, NF4LNK.

Delete comma

>      resources (disk space, directory entry, and so on.) formerly

Delete period

>      the file will still be accessible. The usual mechanism used is to
>      use RENAME to rename the file from its old name to a new hidden
>      name.

This would read more easily if "use RENAME to rename" -> "RENAME"

>      The stateid is necessary for SETATTRs that change the size of file

size of file -> size of a file

>      The principal or principal to user identifier mapping is taken from

This reads awkwardly.

>      existing clientids.  If the client is a traditional host based

host based -> host-based

>      the host credential.  If the client is a user level client or light
>      weight client, the credential used may be the end user's

light weight -> lightweight

>      The client must use the SETCLIENTID_CONFIRM operation to confirm
>      its use of client identifier.  Once the server receives the valid
>      confirmation, all state previously held by the client (if
>      applicable) is kept until the receipt of the SETCLIENTID_CONFIRM is
>      successful.  Upon successful confirmation the server will release

This is confusing - it sounds like "once the server receives the valid
SETCLIENTID_CONFIRM confirmation, it keeps all state until it receives
a SETCLIENTID_CONFIRM", but of course it just did ...

>      struct WRITE4resok {
>              count4          count;
>              stable_how4     committed;
>        verifier4writeverf;
>      };

Is this last supposed to be indented and given a name "verf"?  That's
what appears to be the case from the text.

>      Some implementations may return NFS4ERR_NOSPC instead of
>      NFS4ERR_DQUOT when a user's quota is exceeded.

Why is that?

> 15.2.  Procedure 1: CB_COMPOUND - Compound Operations
> 
> ...
>    ERRORS
> 
>      All errors defined in the protocol

(actually, it can't return them all, or even close ...)

>      The client returns attrbits and the associated attribute values
>      only for attributes that it may change (change, time_modify,
>      object_size).  It may further limit the response to attributes that
>      it has in fact changed during the scope of the delegation.

Why would it bother limiting the response to just those that have
changed?  Surely this is a very minor savings ... ?

>    via an information RFC.  This will provide for interoperability where

an information -> an Informational

>            NFS4ERR_STALE           = 70,
>            NFS4ERR_BADHANDLE       = 10001,

Why the skip in numbering between these two?

>    /*
>     * ACE4_GENERIC_WRITE -- defined as combination of
>     *      ACE4_READ_ACL |
>     *      ACE4_WRITE_DATA |
>     *      ACE4_WRITE_ATTRIBUTES |
>     *      ACE4_WRITE_ACL |
>     *      ACE4_APPEND_DATA |
>     *      ACE4_SYNCHRONIZE
>     */
>    const ACE4_GENERIC_WRITE = 0x00160102;

The constant is missing ACE4_APPEND_DATA, it should be 0x00160106.

-------------------------
[David's responses]

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >              All leases granted by a server have the same fixed
> >              interval.
> 
> Why is this?  (It may be explained later, but I don't recall.  If so,
> perhaps it would help to add here "(for reasons explained in section X.Y)".

This was discussed on the alias over a year ago.  While it is in theory
possible to have variable length leases it would greatly complicate
the protocol.  The basis of the recovery mechanism is that the
server has to maintain very little state about who has what files
open. If a different lease interval was given out to different clients
or different files, the server would need to maintain a list of all
files and clients with each lease interval in order to ensure that
all clients can reclaim their lease before granting any new leases.
To maintain such a record requires a stable writing on every lease
based operation which can be expensive.  If all that state is not maintained
then the server must wait until the longest possible lease interval
before granting any new leases.  So in the interest of performance and
simplicity leases are all fixed.  A very smart server could maintain
different degrees of state in non-volatile storage, at the extreme
it maintains all state and requires no grace period and just restarts.
Again, this allows a simple implementation but doesn't prohibit
complex performanance enhancements.

[Spencer, let me know if you need help clarifying the text on this.]

> >    rawdev             41   specdata4      READ     Raw device
> >                                                    identifier.
> 
> What is this used for?  Things like "df" output?

No. Unix device major/minor node information.

> >    Locking is different than most NFS operations as it requires "at-
> >    most-one" semantics that are not provided by ONCRPC.  In the face of
> 
> Mention here that even if over TCP, retransmissions can occur due to
> failed-and-then-reestablished TCP connections.

You are correct. Spencer, how about adding "ONCRPC over a reliable
transport is not sufficient because a sequence of locking requests may
span multiple TCP connections."

> >    If a request with a previous sequence number (r < L) is received, it
> >    is rejected with the return of error NFS4ERR_BAD_SEQID.  Given a
> >    properly-functioning client, the response to (r) must have been
> >    received before the last request (L) was sent.  If a duplicate of
> 
> Can't there in principle be concurrent RPCs, which means that a response
> might not have been received before the last request was sent?

Yes there may be concurrent RPCs, but there will never be concurrent
lock requests outstanding by the same lock owner.  There are no know
operating systems that allow multiple concurrent outstanding lock requests on
the same file by the same process. If one is found it could probably
be finessed by a synchronization in the client.

> >    The client is discouraged from coalescing adjacent ranges since the
> >    server may not support sub-range requests and for reasons related to
> 
> Not clear what it means here to coalesce an adjacent range.

"The client is discouraged from combining multiple independant
locking ranges that happen to be adjacent into a single request
since the server may not..."

> >    The server should take care in the length of delay in the event the
> >    client retransmits the request.
> 
> This shouldn't happen when using TCP, other than for TCP connection failure,
> which takes many minutes to occur.

The standard requires TCP, but the protocol is designed for UDP
and other unreliable transports. So minutes can easily be seconds.

> >    Clients should be prepared for the return of NFS4ERR_GRACE errors for
> >    non-reclaim lock and I/O requests.  In this case the client should
> >    employ a backoff and retry mechanism for the request.  Timeout
> 
> Need more specifics explaining how the backoff should work.  (Should it
> be exponential?)

Exponential or at least wording to state a backoff algorithm that will
not cause lock step retries and failures.

> >    In the event of a network partition with a duration extending beyond
> >    the expiration of a client's leases, the server MUST employ a method
> >    of recording this fact in its stable storage.  Conflicting locks
> 
> How can the server know if there's a network partition?  It looks the same
> as the client being down, from its perspective.

You are correct.  The text is confusing, better would be to change
it to be "If the server continues to hold locks beyond the expiration ..."
Why it holds it is not important.

> >    by the client.  As a result of revocation, the client will receive an
> >    error of NFS4ERR_EXPIRED and the error is received within the lease
> >    period for the lock.  In this instance the client may assume that
> 
> Seems there's a race here - "within the least period of the lock" isn't
> tightly defined.  This is worth commenting on even if it really shouldn't
> come up in practice (in which case, that's part of the comment).

Since it is expected that a client will have frequent communication
with the server, being outside a lease period should be very rare.
But clarification might help.

> >    The LOOKUP operation is preserved and will return a filehandle
> 
> Unclear what "preserved" means here.

My suggestion is to remove "is preserved and" as it refers to
previous versions and is not really needed in this text.

> >              PUTFH  (directory filehandle)
> >              LOOKUP "pub"
> >              GETFH
> >              LOOKUP "foo"
> >              GETFH
> >              LOOKUP "bar"
> >              GETFH
> 
> Explain why the GETFH's are needed.

Change "or" to be "or, if the client wishes to obtain the intermediate
file handles"

        -David

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Apr 2000 05:25:23 -0700 (PDT)

> Are these well-defined for non-ASCII character sets?

I suggest adding near the discussion of the case_* attributes this:

Each UCS-4 character (which UTF-8 encodes) has a "long descriptive name"
[RFC1345] which may or may not included the word "CAPITAL" or "SMALL". The
presence of SMALL or CAPITAL allows an NFS server to implement unambiguous and
efficient table driven mappings for case insensitive comparisons, and
non-case-preserving storage.

> How come there aren't _set forms for backup and create?  Seems both

As noted in column 4,
time_access is read-only, time_access_set is write-only, whereas time_backup
and time_create are read/write.

> in the same position as *upper* case a, and vice versa?

Yes for the greek7-old code set as described in RFC 1345.
> >    UTF       UCS transformation format.

Suggest  changing the above to:

UTF	UTF is an abbreviation of the term "UCS transformation format" and is
used in naming with various standards for encoding of UCS characters as described below.

----

BTW, Vern's comments on why GETFH was needed or not, reminds me that
it is an absolute disaster if the client fails include an GETFH after
an OPEN. The reason is that even without the GETFH, the state established by
OPEN remains established each time the client does an operation causes
all leases to be renewed, including the one for the file it has to no
file handle for. At minimum, section 14.2.15.  "Operation 18: OPEN - Open a Regular File" should discuss this, but I'm wondering if a COMPOUND that
has an OPEN without an corresponding GETFH should cause an implicit CLOSE
to be done. This could actually be useful for COMPOUNDs like:

	putrootfh, open "a" "b" "c" ; read 0 512 ;

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Apr 2000 09:05:13 +0100

>non-case-preserving storage.

Danger !

         RFC-1345 is known to be broken and should not be used as a reference
for this purpose (or, to be blunt, for any purpose relating to
any character sets using any encoding).  If I were writing code, I would
also avoid referencing RFC-1345 because it would lead to my implementation
not conforming with all the applicable character set standards.  I'm
afraid there is no substitute for actually getting a real copy of ISO-10646,
ISO-646, and whichever other specs are referenced.

         The above text is trying to define a "normalisation procedure"
for multilingual text strings.  At present, ISO has no standards for
normalisation.  The Unicode Consortium does have such standards.
IAB has formally requested that ISO take action in this space very
rapidly.

         It is HIGHLY undesirable for NFS WG to specify something without
prior coordination with other related WGs and the ADs.  For example, it
would be very bad if NFS WG specified a normalisation procedure for its
filename strings and the FTPEXT WG specified a _different_ normalisation
procedure for its filename strings.

         IESG guidance on normalisation of ISO-10646 characters is probably
what is really needed, not only for NFS WG but also for other WGs.  I believe
that the IESG is aware of the issue (IAB is definitely aware of this issue).

>Yes for the greek7-old code set as described in RFC 1345.

         Again, RFC-1345 has various bugs inside it and is known to be broken.
Please do NOT use RFC-1345.  Please go back and actually check the
root standards to verify the facts.

>used in naming with various standards for encoding of UCS characters as 

Ran
[email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Apr 2000 06:46:35 -0700 (PDT)

> >presence of SMALL or CAPITAL allows an NFS server to implement unambiguous
> and >efficient table driven mappings for case insensitive comparisons, and
> for this purpose (or, to be blunt, for any purpose relating to any character
> sets using any encoding).  If I were writing code, I would also avoid
> referencing RFC-1345 because it would lead to my implementation not
> conforming with all the applicable character set standards.  I'm afraid
> there is no substitute for actually getting a real copy of ISO-10646,

The problem with depending on ISO standards is that they aren't free, and
so inhibit implementation. Thus I believe the nfsv4 i-d is careful to
use rfc1345 in ways that aid implementation, and refers to the relevant up to
date iso and unicode specifications where necessary. 

I don't believe RFC 1345 is broken in the area of case given that unicode.org
uses long descriptive names that have the word CAPITAL or SMALL in them.

RFC 1345 is a handy reference for understanding the basic differences between
the various UCS variants, and the UTF variants, and I similarly don't believe
it is broken in that area either.

> IAB has formally requested that ISO take action in this space very

My understanding is that normalization and case comparison are distinct
things. And the nfsv4 spec is pretty clear that it is agnostic on normalization.

My suggested text doesn't mandate a procedure for managing case, it merely
suggests a procedure. The fact is that there are file systems that support
case insensitive, case preserving semantics, and they work over unicode.  In
absence of a defined method for dealing with case, implementors of nfsv4
servers of such file systems are going to deal with it. And even if IESG
defines a method, if it is at odds with how say NTFS deals with it, then
expect plenty of "non-compliant" nfs v4 servers. So mandating a procedure
for dealing with case is a bad thing. Explaining the UCS-4 has case is good
thing.

>          Again, RFC-1345 has various bugs inside it and is known to be
> broken. Please do NOT use RFC-1345.  Please go back and actually check the

The context of the discussion in the nfsv4 i-d is to explain why per-language
charsets => bad, universal character sets => good. That upper case alpha may
or may not be where lower case ASCII a and not where upper case ASCII A is
beside the point. The point is that the example charset has no ASCII A at all
making it impossible to represent names that both greek7-old and ASCII
characters, unless one uses UCS or Unicode. The greek7-old charset example in
RFC 1345 demonstrates the issue, regardless how similar it is to greek7-old
charset in ISO. 

If may very well be the case that RFC 1345 is all wet, and that ISO doesn't
define charset's at all. That's both fine and irrelevent to the point.

	-mre

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Apr 2000 20:43:10 +0100

>uses long descriptive names that have the word CAPITAL or SMALL in them.

I believe it is.  For openers, consider the date of 1345 and realise
that the UNICODE and ISO-10646 standards themselves have changed since the
publication date of 1345.  That aside, MIME implementers learned the hard
way that there are a number of bugs spread around 1345.

>it is broken in that area either.

Again, it might be useful for orientation, but a number of the underlying
specifications have changed since 1345 was published.  The author of 1345
had a pretty definite private agenda, which impacted the content of the RFC,
sadly enough.

>for dealing with case is a bad thing. Explaining the UCS-4 has case is good

It would be helpful if the NTFS facts could get documented.  My guess is
that they have implemented the UNICODE normalisation (including case folding)
process, but I'm not at all certain.

>define charset's at all. That's both fine and irrelevent to the point.

Referencing 1345 in the manner the draft does creates avoidable confusion.
There must be alternatives.

Ran
[email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Apr 2000 19:25:15 -0700 (PDT)

"RJ Atkinson" <[email-masked]> wrote
> >I don't believe RFC 1345 is broken in the area of case given that
> unicode.org >uses long descriptive names that have the word CAPITAL or SMALL
> in them.
> 
> I believe it is.

Well I looked at the character set tables on unicode.org today and I don't
believe I stand corrected. But if you of a specific counter example, it
would be good to identify it.

> Referencing 1345 in the manner the draft does creates avoidable confusion.

If it's not clear that the references are intended to be for orienting the
reader to the topic, versus the normative references the i-d makes to
the ISO standards, then I agree the text in the i-d should be clarified.
Since I wrote much of the i18n section, I'm probably not the best one
suggest altered text that would make this clearer.

	-mre

	-mre