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: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------