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: papowell at sdsu.edu