Subject: Re: IPP> create job IPP operation

From: [email-masked] (Robert Herriot)
Date: Thu, 12 Jun 1997 18:54:13 -0700

Option 1 (flag for last document) is the best and only reasonable solution.

Option 3 (end job operation) can be accomplished with Option 1 by
allowing a document of length zero and the last flag on for clients
that cannot figure out they are done when they send the last document.

Bob Herriot

> From [email-masked] Thu Jun 12 17:13:25 1997. 

> 
> In our current document we have a CREATE-JOB operation that specifies up
> front
> how many documents we have. Is this an unrealistic requirement for
> future IPP
> clients (or drivers) ? Will they always know how many documents are
> coming when
> they first do the CREATE-JOB?
> 
> My feeling is that the clients might not know how many documents will be
> sent, and
> if that is the case, we need a mechanism for SEND-DOCUMENT to indicate
> to
> the server that this is the last document for the job. There are at
> least 3 ways to do
> this off the top of my head:
> 
> 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a
> particular
>     request as the last document for the job.
> 
> 2. Since we are using HTTP 1.1 with persistent connections, just close
> the TCP
>     connection from client to host indicating the end of the job stream
> (or last document).
> 
> 3. Have another IPP operation called END-JOB or CLOSE-JOB that
> unambiguously
>     encapsulates the job stream within a CREATE-JOB/END-JOB pair.
> 
> Comments?
> 
> Randy
> 
> 
>

---

From: Roger K Debry <[email-masked]>
Date: Fri, 13 Jun 1997 07:47:24 -0400

I thought at one time we had agreed on sending an empty Send-Document?

The proposal that Keith Carter and I had made included an EndJob, but was
rejected.

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 06/13/97 05:41
AM ---------------------------

        ipp-owner @ pwg.org
        06/12/97 08:02 PM
Please respond to [email-masked] @ internet

To: rturner @ sharplabs.com @ internet, ipp @ pwg.org @ internet
cc:
Subject: Re: IPP> create job IPP operation

Bob Herriot

---

From: Scott Isaacson <[email-masked]>
Date: Wed, 18 Jun 1997 02:04:53 -0600

Randy,

>>> Randy Turner <[email-masked]> 06/12/97 06:10PM >>>

The model document shows this (number-of-documents) as an optional attribute
in
the Create.  If it is there, it better be correct.  If not, it is up to the
implementation
to handle as many Documents as might be thrown its way (I claim that it
might fail
after some N+1 documents).  Why include it at all if it is optional?  It
might help some
implementations with resource management.  

As other mail has indicated, we need a flag in the Send-Document
that says this is the last document.

Scott

---

From: Scott Isaacson <[email-masked]>
Date: Wed, 18 Jun 1997 01:43:30 -0600

In the Model document, there is language about a "zero length document" in a

Send-Document operation that is the "flag".  I suppose we do need a flag
since you might know the document you are sending is the last document and
it would not be efficient to require another empty Send-Document.  But we
must
allow for an empty Send-Document for the case that Bob points out where
the client does not know it is the end until there are no more documents.

Scott

>>> Robert Herriot <[email-masked]> 06/12/97 07:54PM >>>

Bob Herriot

---

From: Tom Hastings <[email-masked]>
Date: Wed, 18 Jun 1997 14:45:08 PDT

>implementations with resource management.  

In order to avoid another error condition and a requirement for the
server to check for the proper number of documents, lets delete the
"number-of-documents" input parameter.

However, we still need a read-only job attribute that the IPP server 
SHALL increment by 1 with each Send-Document operation.

If we can't agree to delete the "number-of-documents" input parameter
from Create-Job, then lets at least change the name to something like:
"expected-number-of-documents", so that it is not confused with the
read-only "number-of-documents" job status attribute which the IPP printer
increments as each Send-Document is received.  But I don't see the
need for such an input-parameter.  Lets wait to see if implementations
find a need for such an input-parameter and it can be registered later.

Ok?

>that says this is the last document.

Also from the PRO disussion yesterday, a requester must be able to
issue a Send-Document with no document data and just the flag set
to TRUE, since the requester might not have know that it was the
last document when the requester did the Send-Document with the data.

This flag is both an input-parameter of the Send-Document operation
that also sets the corresponding job attribute of the same name.

Randy's protocol document had the input parameter named as an imperitive verb:
"end-document-stream", but that isn't such a good name for the
corresonding job attribute.  How about the ISO DPA name:
"job-submission-complete" for both the input parameter and the read-only
job status attribute.

Tom

---

From: [email-masked] (Robert Herriot)
Date: Wed, 18 Jun 1997 16:53:56 -0700

I agree with Tom that we should delete "number-of-documents" because 
we have added a new parameter to Send-Document called  (I propose) 
"last-document" which is Boolean.

I don't agree with Tom's suggestion of to have a number-of-documents
that the Printer increments.  I would rather allow the user to query
document-name and get back a set of n document names.

Bob Herriot

Tom's proposal of adding
> From [email-masked] Wed Jun 18 15:14:53 1997

---

From: Tom Hastings <[email-masked]>
Date: Thu, 19 Jun 1997 10:41:20 PDT

>"last-document" which is Boolean.

The problem with "last-document" as a name for the input-parameter,
is that the corresponding job attribute would have to be different,
say, "job-submission-complete".  I think that as a principle, the
names of the input parameters and the names of the job attributes
that the input parameters set should be the same.

Using the same names for input parameters as the corresponding job
attributes (when there are both) will also make the encoding more 
understandable, since we don't have any separate buckets for input 
parameters in the encoding, but have just a single set of attribute 
representations as input parameters.

Or were you prosing that we don't need a Boolean job attribute
that indicates whether the job is complete or not?  Since we have
the "job-state-reasons" 'job-incoming' value, perhaps that is enough to indicate
to a requester in a Get-Attrbutes request that the job is not yet
complete?  If we don't also need a "job-submission-complete" job attribute,
then the input-parameter name "last-document" Boolean is fine.
Not having the "job-submission-complete" job attribute makes it more
mandatory that an implementation that supports Create-Job and Send-Document
also support the 'job-incoming' reason in the "job-state-reasons" attribute.

>document-name and get back a set of n document names.

I can agree that we don't really need a "number-of-documents" job
attribute, since the requester can find the number of documents by
requesting a document attribute, such as "document-name"

But that brings up the need for a clarification of how the Get-Attributes
operation returns document attributes.

The Get-Attributes operation for document attributes needs a lot of 
clarification. Currently the model document has only 3 document attribtes:
"document-name", "document-format", and "document-uri".

I had thought that the document attributes would come back in groups,
one group for each document if and only if the requester requests a
document attribute, such as "document-name".  I thought this, because the 
document has been made an object (but with no operations on it).

Bob might be suggesting that the Printer returns a single multi-valued 
attribute "document-format", with a separate value for each document.  

If a requester supplies:
  Create-Job(...)
  Send-Document( 
     "document-format" = 'application/postscript'
     "document-name" = 'Monthly Slides' )
  Send-Document(
     "document-format" = 'application/vnd.hp-PCL'
     "document-name" = 'Monthly Report'

Get-Attributes with "requested-attributes" = 'document-format', 'document-name';
input parameter would return:

Result Attributes:
     "document-format" = 'application/postscript', 'application/vnd.hp-PCL'
     "document-name" = 'Monthly Slides', 'Monthly Report'

I had assumed that the result would group document attributes with some
specified document attribute as the indicator that the next set of
document attributes were following.  Either we pick "document-name"
or make up a new read-only status attribute, say, "document-sequence-number" 
(as in DPA) that is set by the Printer.  I prefer the latter:

Result Attributes:
     "document-sequence-number" = '1'
     "document-format" = 'application/postscript'
     "document-name" = 'Monthly Slides'
     "document-sequence-number" = '2'
     "document-format" = 'application/vnd.hp-PCL'
     "document-name" = 'Monthly Report'
     
Comments?

Tom

---

From: [email-masked] (Robert Herriot)
Date: Thu, 19 Jun 1997 12:41:58 -0700

I was proposing that "last-document" be an operation parameter with
no corresponding concept in the job object.  Therefore, I infer that
you agree with the name of "last-document".

For Get-Attributes and GetJobs of document attributes, such as document-name,
I was trying to keep things simple by saying that in a job with 2 or more
documents, the value of each such attribute is a set of the document values.
For example, if I submit a job with two documents whose document-name
attributes are "foo" and "bar", then Get-Attributes with document-name
requested shall return in protocol syntax

   "document-name 3 foo 3 bar" 

This is the syntax for a set of values for document-name.

This solution does not solve the problem of document-attributes that
are multi-valued, but we don't have any yet. So we can defer the solution.

Bob Herriot

> From [email-masked] Thu Jun 19 11:31:30 1997
>