Subject: IPP> Option Negotiations

From: Patrick Powell <[email-masked]>
Date: Mon, 28 Apr 1997 11:03:59 -0700 (PDT)

I have been away for the last three weeks,  and have missed much of the
discussion on the IPP news groups.  (I have 984 unread mail messages... groan).

Before I left, there was some discussion about job options and informing users/client
software what options were available.  I happened to be looking at the PPP Protocol
RFC 1661 and 1662.

In these protocols they describe the 'Options Negotiation' method used by PPP.
In summary, it is as follows:

1. One end of the connection sends a 'negotiation message' with ALL of the
   requested options in it.  Options can be binary, or value options.

2. If the other end accepts the options,  it replies with an ACK message,
   with a copy of the original options,  in the same order that they were sent.

3. If the other end rejects some of the options,  it responds with a Nack
   message,  and the message contains the options and/or values that were
   rejected. Here is the wording from the RFC:
% 
% .... <packet descriptions> ...
% 
%       Configure-Nak packets are used to refuse a Configuration Option
%       value, and to suggest a new, acceptable value.  Configure-Reject
%       packets are used to refuse all negotiation about a Configuration
%       Option, typically because it is not recognized or implemented.
%       The use of Configure-Nak versus Configure-Reject is more fully
%       described in the chapter on LCP Packet Formats.
% 
% ..... <detailed descriptions> .....
% 
% 5.3.  Configure-Nak
% 
%    Description
% 
%       If every instance of the received Configuration Options is
%       recognizable, but some values are not acceptable, then the
%       implementation MUST transmit a Configure-Nak.  The Options field
%       is filled with only the unacceptable Configuration Options from
%       the Configure-Request.  All acceptable Configuration Options are
%       filtered out of the Configure-Nak, but otherwise the Configuration
%       Options from the Configure-Request MUST NOT be reordered.
% 
%       Options which have no value fields (boolean options) MUST use the
%       Configure-Reject reply instead.
% 
%       Each Configuration Option which is allowed only a single instance
%       MUST be modified to a value acceptable to the Configure-Nak
%       sender.  The default value MAY be used, when this differs from the
%       requested value.
% 
%       When a particular type of Configuration Option can be listed more
%       than once with different values, the Configure-Nak MUST include a
%       list of all values for that option which are acceptable to the
%       Configure-Nak sender.  This includes acceptable values that were
%       present in the Configure-Request.
% 
%       Finally, an implementation may be configured to request the
%       negotiation of a specific Configuration Option.  If that option is
%       not listed, then that option MAY be appended to the list of Nak'd
%       Configuration Options, in order to prompt the peer to include that
%       option in its next Configure-Request packet.  Any value fields for
%       the option MUST indicate values acceptable to the Configure-Nak
%       sender.
% 
%       On reception of a Configure-Nak, the Identifier field MUST match
%       that of the last transmitted Configure-Request.  Invalid packets
%       are silently discarded.
% 
%       Reception of a valid Configure-Nak indicates that when a new
%       Configure-Request is sent, the Configuration Options MAY be
%       modified as specified in the Configure-Nak.  When multiple
%       instances of a Configuration Option are present, the peer SHOULD
%       select a single value to include in its next Configure-Request
%       packet.
% 
%       Some Configuration Options have a variable length.  Since the
%       Nak'd Option has been modified by the peer, the implementation
%       MUST be able to handle an Option length which is different from
% 
% 
Comments:

   I rather like this approach - it appears to make sense on HOW to do
option negotion and specification.

Any comments from the rest of the mailing list?

Prof. Patrick Powell
Dept. Electrical and Computer Engineering,
San Diego State University,
San Diego, CA 92182-1309
Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577
email: [email-masked]

---

From: JK Martin <[email-masked]>
Date: Mon, 28 Apr 1997 15:02:37 -0400 (EDT)

We (Underscore) have some field experience with a slightly different
approach to option discovery/negotiation:

  1.  The cient sends the server its list of options and values.

  2.  The server returns a set of options for which the server understands,
      as well as the values acceptable to the server; if the server does
      not understand a particular option submitted by the client, then that
      option is not present in the response to the client.

  3.  The client parses the options returned by the server, then decides
      whether further communication is desired/possible.  If the client finds
      that one of its submitted options was not in the set returned by the
      server, then the client considers that option to be "unsupported" by
      the server (using some of the latest IPP terminology); similarly, the
      client evaluates the values returned by the server for those options
      that are supported by the server, and decides whether those values are
      acceptable for the subsequent target communications activities.

This is not terribly different that what Patrick has submitted wrt the PPP
approach.  However, the above technique allows such option negotiation to
happen within the context of a "Start Session" message, thereby killing
two birds with one stone:  initialize communications for a target purpose,
and setup the parameters for that communications session.

The above technique has been in use in the field for about 3 years now,
supporting certain management facilities for a family of network printers.

Just our 2 cents worth on this topic.  There are lots of ways to accomplish
the same goal.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------