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