[nfsv4] extensions to callbacks and replies

[David Noveck <[e-mail]>]

This is my response to the discussion of the open issue that Tom cited
regarding extensions to the set of callbacks, which was extended by Bruce
to cover extensions to replies as well.

I think the discussion uncovered significant issues which should be
addressed in draft-haynes-nfsv4-versioning-02 (or
draft-ietf-nfsv4-versioning-00).  Here's some proposed changes for people
to comment on.  I hope I've addressed all the issues that people brought
up.  Let me know if I've missed something.


The penultimate unbulleted paragraph of section 5.1 (the one now at the top
of page 8) is modified.  Strike the final "In particular:" and add a new
paragraph after that which reads as follows:

Because the receiver of a message may be unaware of the
existence of a specific extension, certain compatibility
rules need to be observed.  In some cases (e.g addition of
new operations or callbacks or addition of new arms to an
existing switched union) older clients or servers may be
unable to do XDR parsing on an extension of whose existence
they are unaware.  In other cases (e.g. error returns) there
are no XDR parsing issues but existing clients and servers
may have expectations as to what may validly be returned.
Detailed discussion of these compatibility issues appears below:


   o Issues related to messages sent to the server are discussed
     in section 5.1.1.

   o Issues related to messages sent to the client are discussed
     in section 5.1.2.

Begin a new section at this point:  The beginning should read;

*  5.1.1.   Compatibility issues for messages sent to servers.*

This section deals with compatibility issues that relate to
messages sent to the server, i.e. requests and replies to callbacks.
In the case of requests, it is the responsibility of the client to
determine whether the server in question supports the extension in
question before sending a request containing it for any purpose
other than determining whether the server is aware of the extension.
In the case of callback replies, the server demonstrates its awareness
of proper parsing for callback replies by sending the associated callback.


Regarding the handling of requests:


The existing bulleted list follows with the following modifications:

   - For the second bullet, add the following new sentence at the end:

Clients need to do this before attempting to use attributes
defined in an extension since they cannot depend on the
server returning NFS4ERRATTRNOTSUPP for requests which
include a mask bit corresponding to a previously unspecified
attribute number (as opposed to one which is defined but
unsupported).



   - Delete the third bulleted  item  as it now belongs in section 5.1.2.


   - In the fifth bulleted item, 'in a request" after "union".


   - Delete the last bulleted item.


Add after the end of the existing section 5.1 the following additional
paragraph:

Regarding the handling of responses to callbacks:

  o Error values returned to the server for all callbacks that do not

    use new features will only be those previously allowed.  Only when
    the server uses a new callback extension feature can a previously

    invalid error value be returned.


  o Callback replies may only include a new arm of an existing switched

    union when the server, typically in the callback being responded to,

    has used a feature element associated with the feature that defined

    the new switched union arm.


At this point the other new section begins:

*  5.1.2.   Compatibility issues for messages sent to clients.*

This sections deals with compatibility issues that relate to messages
sent to clients, i.e. request replies and callbacks.  In both cases,
extensions are only sent to clients that have demonstrated awareness
of the extensions in question by using an extension associated with
the same feature.


Regarding the handling of request replies:

  o Error values returned to the client for all requests that do not

    use new features will only be those previously allowed.  Only when

    the server uses a new callback extension feature can a previously

    invalid error value be returned.


  o Replies may only include a new arm of an existing switched union
    when the server, typically in the request being responded to,
    has used a feature element associated with the feature that defined
    the new switched union arm.


Regarding the handling of callbacks, the server needs to be sure that
it only sends callbacks to those prepared to receive and parse them.

  o In most cases, the new callback will be part of a feature that
    contains new (forward) operations as well.  When this is the case,
    the feature specification will specify the operations whose receipt
    by a server is sufficient to indicate that the client issuing them
    is prepared to accept and parse the associated callbacks.

  o For callbacks associated with features that have no new operations
    defined, the feature specification should define some way for a
    client to indicate that it is prepared to accept and parse
    callbacks that are part of the extension.  For example, a
    flag bit in the EXCHANGE_ID request may serve this purpose.

    o In both of the above cases, the ability to accept and parse the
    specified callback is considered separate from support for the
    callback.  The feature specification will indicate whether support
    for the callback is required whenever the feature is used by the
    client.  In cases in which support is not required, the client is
    free to return NFS4ERR_NOTSUPP upon receiving the callback.