> From xriley at cp10.es.xerox.com Wed Jul 9 01:33:27 1997
>> all,
> Clarification on the following would be appreciated. I'm trying
> to tie the new Protocol document (ipp970702.doc) to the Model
> document. My comments are preceded by "XDR>".
>>> 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.
I am gradually tightening up the language in the protocol document. The
version of 7/8.97 does a better job. Briefly, the model document
names explicit parameters and collections of attribute for transmission
within operations. We have tried to distinguish these two. Generally the
parameter are most important for the operation and attribute provide
additional information.
>>> 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?
I've noticed that contradiction. We intended that it is possible for
a Print-Job to have no parameters/attributes -- just Document data.
>>> 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?
>>> 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.
Yes. This is still a dangling issue and involves security.
>>> 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.
We cannot guarantee what attributes will be returned because some
printer may consider the return of certain attributes to be a security
violation. As a result a client may see different attributes coming
from different printers or even different jobs on the same printer.
>>> 1068 4. If the client supplies an attribute group keyword that is
> not unsupported, ...
> XDR> Did you really mean to use "not unsupported" ?
>>> 1248 ... the "printer-job-template" group in order to get the
> XDR> Should "printer-job-template" be printer "job-template" ?
>>> ______________________________________________________________________
> Xavier Riley
> Xerox Corp. Voice: 310-333-8329 / 8*823-8329
> Corp. Research & Tech. Fax: 310-333-6618 / 8*823-6618
> 701 S. Aviation Blvd ESAE-231 Email: xriley at cp10.es.xerox.com> El Segundo, California 90245 http://www.cp10.es.xerox.com/~xriley> ______________________________________________________________________
>>>