Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference on 970924 [problems with adding "document-name" operation attribute]

From: Tom Hastings <[email-masked]>
Date: Thu, 25 Sep 1997 11:02:28 PDT

While I was in favor of adding the "document-name" as an operational
attribute at the telecon yesterday, Carl-Uno and I have discovered 
several problems and we have a simple solution.

The problems are:

1. Does Create-Job operation also allow a "document-name" operational
attribute?  Then Create-Job continues to be the same as Print-Job,
except that no data can be supplied.  Also the defaulting rules that
Bob wrote up can be applied by the Printer in Create-Job.  

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

3. If we keep the semantics that the Printer defaults the "job-name" from
the "document-name" and "document-uri",  I think that the "document-name"
should have more priority than "document-uri", since document-uri is
usually less user friendly and is sometimes algorithmically generated
(digits).

Rather than solving the above problems, Carl-Uno and I suggest the following:

1. Do NOT have a "document-name" operational attribute at all in any
operation (same as we agreed in Atlanta).

2. Since the "job-name" attribute is MANDATORY for a Printer to support,
lets also require that the client supply the "job-name" operational
attribute.  Then we don't need any defaulting rules for the Printer
for the "job-name" attribute. It is up to the client to determine
the "job-name" either algorithmically from the (first) document content or
allowing the end-user to supply and to ALWAYS supply something in
Print-Job, Print-URI, and Create-Job.

Comments?

Tom

At 17:45 09/24/97 PDT, Robert Herriot wrote:
>Scott, 
>
>Here is some new wording for job-name initialization that relates to
>the discussion item from today's teleconference, as described in the
>minutes (see excerpt below).
>
>The following change should be made to section 4.3.4, line 1625 of your
>9/3/97 document. I have changed a MAY to a SHOULD because I think that
>it more what we intended.
>
>Existing sentence preceding the change:
>
>If, however, it [the job-name] is not supplied by the client in the
>create request, the Printer, on creation of the Job SHALL generate a
>name.  
>
>New Sentence:
>
>The printer SHOULD generate the value of the job-name from the
>first of the three following sources that produces a value: 1)
>"document-URI" of the first (or only) document, 2) "document-name" of
>the the first (or only) document, 3) some piece of Job specific
>information.
>
>Removed Sentence:
>
>The printer MAY choose to use the value of the "document-name" of the
>first (or only) document (or any piece of Job specific information) as
>a basis for generating a job name.
>
>Additional comment
>
>The description for "document-name" does not state whether it can be
>present when a "document-URI" is present, but my recollection is that
>we said it could be.  That is, it is not necessarily the file name of 
>the document.
>
>
>> From [email-masked] Wed Sep 24 16:24:50 1997
>> 
>> 
>> 1) Consequences of Atlanta proposal to take out document level attributes.
>> 
>> Of Bob Herriot's earlier listed 3 alternatives, alternative 2) seems to get
>> most support both from the DL and the participants in the call.
>> 
>> The general proposal for resolution include the following:
>> a) Keep the Print-URI and Send-URI operations.
>> b) The actual URIs are operational attributes. They are not stored on the
>> job object and cannot come back in a Get-Attributes operation.
>> c) Add back document-name as an operational attribute on Print-Job,
>> Print-URI, and Send-Document operation requests.  It is not stored on the
>> job or document objects and cannot come back in a Get-Attributes operation. 
>> d) Describe algorithm of how to populate job-name from first document-name
>> in the job, if not supplied by requestor.
>> 
>> Bob Herriot to write draft text and send to the DL.
>> 
>
>
>

---

From: [email-masked] (Robert Herriot)
Date: Thu, 25 Sep 1997 13:27:06 -0700

> From [email-masked] Thu Sep 25 11:04:40 1997
> 

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.

---

From: Tom Hastings <[email-masked]>
Date: Fri, 26 Sep 1997 14:03:02 PDT

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

---

From: [email-masked] (Robert Herriot)
Date: Fri, 26 Sep 1997 14:25:43 -0700

> From [email-masked] Fri Sep 26 14:21:05 1997
> 
> 

We have said that we want a client to be able to send document-data only.
If we mandate job-name, we violate that requirement.  If job-name
is optional, it has a default, and we should use the same defaulting
rules that other print systems have.