IPP> ADM - Minutes from PWG IPP Phone Conference on 970924

IPP> ADM - Minutes from PWG IPP Phone Conference on 970924

IPP> ADM - Minutes from PWG IPP Phone Conference on 970924

Tom Hastings hastings at cp10.es.xerox.com
Fri Sep 26 17:03:02 EDT 1997


Bob has another solution that would keep the "document-name" attribute
as an operational attribute:  drop the returning of the "job-name"
attribute on a Print-Job or Create-Job response, so that the Printer
could wait until the first Send-Document/Send-URI operation to form
the "job-name" if the client didn't supply the "job-name".


So a job might not have a job-name between the Create-Job operation
and the first Send-Document/Send-URI operation, which would usually
be a very short time.


On the other hand, what was wrong with mandating the client supplying
the "job-name" which the client could get from the first document?


Either approach is fine with me.


Tom


At 13:27 09/25/97 PDT, Robert Herriot wrote:
>
>> From hastings at cp10.es.xerox.com Thu Sep 25 11:04:40 1997
>> 
>> 2. If the client doesn't/can't supply a "document-name" in the Create-Job
>> operation, the Printer doesn't want to wait for the first Add-Document 
>> to get the "document-name" or "document-uri" attribute in order to default
>> the "job-name" attribute.  Not returning a "job-name" on Create-Job 
>> response seems a problem too (since it is MANDATORY to return it).
>
>Why MUST the server return the "job-name" for Print-Job and Create-Job?
>If we didn't have such a rule, the server could wait until it received
>the first document before setting an unspecified job-name from the
>document-name or document-URI.
>
>Then we could keep the simple rule of using the first document's
>document-name or document-URI to set job-name. We came up with these
>rules originally because we noted that this is what current print
>systems do.
>
>



More information about the Ipp mailing list