Subject: IPP> MOD - Questions on IPP Model and Protocol Document (model-issues-970623.pdf)

From: "Xavier D. Riley" <[email-masked]>
Date: Tue, 8 Jul 1997 07:12:46 PDT

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.

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?

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.

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.

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: [email-masked]
El Segundo, California 90245     http://www.cp10.es.xerox.com/~xriley
______________________________________________________________________

---

From: [email-masked] (Robert Herriot)
Date: Wed, 9 Jul 1997 19:56:10 -0700

> From [email-masked] Wed Jul  9 01:33:27 1997
> 
> all,

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.

> 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.

> 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.

> 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.

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 15 Jul 1997 13:05:26 -0600

Xavier,

My responses are below prefixed by SAI>.

Scott

>>> "Xavier D. Riley" <[email-masked]> 07/08 8:12 AM >>>

319    2.2.2 Parameters

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

SAI> This is a conflict, we will have to resolve it.

XDR>   It is stated that only the job originator can cancel the job. How
much 

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

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.

SAI> This typo has been fixed.

SAI> This typo has been fixed.