IPP Mail Archive: Re: IPP> Rational for IPP Arch or "Why We Shot ourselves in

Re: IPP> Rational for IPP Arch or "Why We Shot ourselves in

Scott Isaacson (SISAACSON@novell.com)
Mon, 14 Jul 1997 21:45:55 -0600

Great job Steve!

The way that it is written (covering Security, Model, Directory, and
Protocol) makes me think that it is most definitely a stand alone document.
If you had
only done section 4 I would see that being wrapped into the Protocol
document. It looks like a great FYI RFC.

As per your request about attributes and parameters:

You wrote:

-----------------------
A fully encoded request/response has a version number, an
operation (for a request) or a status (for a response),
associated parameters which are encoded Model data and,
optionally, print data following the Model data.

[ISSUE: what should be said about Parameters and Attributes]
-----------------------

I would change it to:
-----------------------
A fully encoded request/response has a version number, an
operation (for a request) or a status (for a response), an
optional
staus message,
associated parameters which are encoded Model data (and,
optionally), print data following the Model data. The operation
requests contain input parameters and the responses contain
output parameters. Some of the operation parameters contain
sets if attributes and their values.
-----------------------

I might have other comments later, but it looks great after a first cursory
read.

Scott

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson@novell.com
W: http://www.novell.com
************************************************************