My responses are below prefixed by SAI>.
Scott
>>> "Xavier D. Riley" <xriley@cp10.es.xerox.com> 07/08 8:12 AM >>>
319 2.2.2 Parameters
323 attributes, some do not. All parameters are defined in section 5.
XDR> Its not clear to me what are "parameters" in section 5. There are
XDR> not explicitly identified. The protocol document mentions
XDR> "parameter groups" which are not mentioned in the Model document.
SAI> The newest 970714 version of the model document does a better
SAI> job of defining parameters. Operation request include input parameters
SAI> and operation responses include output parameters.
SAI> In the 970623 document parameters were introduced in section 2.2.2
723 5.1.2.1 Print Job Request
XDR> It is stated that the "document-name" is MANDATORY. Line 735 states
XDR> that the simplest Print-Job request consists of just the Document
XDR> Content and nothing else. Is this a conflict?
SAI> This is a conflict, we will have to resolve it.
974 5.1.8 Cancel Job Operation
XDR> It is stated that only the job originator can cancel the job. How
much
XDR> credibility are you placing in the validity of the
XDR> "job-originating-user" value. This validity should be tied into the
XDR> different security methods used and the differences should be stated.
XDR> In order to truly accomplish this, the user has to be authenticated,
XDR> which leads you down the path to talking about security issues.
Question,
XDR> should this be moved to the IPP Security document?
SAI> I am hoping the latest version of the security document should help to
SAI> answer this. We are assuming that "job-orginating-user" is set by the
SAI> system after authentication through the security protocols happen
SAI> This is not settable by the end user.
1043 "The requested attributes of the object with their current
valuesSHALL"
XDR> I'm not sure you meant to have "SHALL" at the end of this sentence.
SAI> This typo has been fixed
1051 A Printer MAY be configured, for security reasons, not
to return all attributes that a client requests. It may
1052 even return none of the requested attributes. In such
cases, the status returned is the same as if the Printer
1053 had returned all requested attributes. The client cannot
tell by such a response whether the requested
1054 attribute was present or absent on the Printer.
XDR> What is the rationale behind this policy of not
XDR> guaranteeing a return? It would be nice to guarantee this
XDR> return so the client could dynamically build the UI querying
XDR> for all of the supported attributed on a printer.
SAI> We guarantee a return (a response from the operation) but in a ultra
SAI> secure environment we must allow for the fact that just returning
SAI> the fact that a job exists might be revealing too much information.
SAI> In most (many, all?) of the environements, all requested attributes
will
SAI> be returned.
1068 4. If the client supplies an attribute group keyword that is
not unsupported, ...
XDR> Did you really mean to use "not unsupported" ?
SAI> This typo has been fixed.
1248 ... the "printer-job-template" group in order to get the
XDR> Should "printer-job-template" be printer "job-template" ?
SAI> This typo has been fixed.