Here is a combined reply to Bob Herriot and Hiroyuki Sato on my original
comments.
My comments don't have any > before them.
Tom
>Return-Path: <robert.herriot at eng.sun.com>
>Date: Thu, 21 Nov 1996 19:23:13 PST
>From: robert.herriot at eng.sun.com (Robert Herriot)
>To: Scott_Isaacson at novell.com, hastings at cp10.es.xerox.com>Subject: Re: Some Comments on ipp92.doc - the issues we didn't get to
> address
>Cc: ipp at pwg.org>X-Sun-Charset: US-ASCII
>>>>>> Most of these comments are on the ISSUES listed in the document that
>> we didn't get time to address.
>>>> 1. 6.1 Attribute syntaxes
>>>> Need to add explanation of the notation in side the parens:
>>>> "#" in front of a data syntax means zero or more values
>> "1#" in front of a data syntax means one or more values
>>>>* means zero or more items, # means 0 or more items in a list, each
separated by a comma ",".
>The syntax is defined in rfc 822 and rfc 1945. We should just lift it all,
word
>for word.
So 1# means one or more items in a list, each separated by a comma?
Here is the complete text from RFC 822 on #RULE: LISTS:
2.7. #RULE: LISTS
A construct "#" is defined, similar to "*", as follows:
<l>#<m>element
indicating at least <l> and at most <m> elements, each separated
by one or more commas (","). This makes the usual form of lists
very easy; a rule such as '(element *("," element))' can be shown
as "1#element". Wherever this construct is used, null elements
are allowed, but do not contribute to the count of elements
present. That is, "(element),,(element)" is permitted, but
counts as only two elements. Therefore, where at least one ele-
ment is required, at least one non-null element must be present.
Default values are 0 and infinity so that "#(element)" allows any
number, including zero; "1#element" requires at least one; and
"1#2element" allows one or two.
NOTE that an empty value, e.g., ,, doesn't count.
Therefore, it may be that such an empty value does not mean anything
and that we should avoid allowing empty values to have any significance
in either job or printer attributes.
(I haven't had time to read all of rfc822).
Therefore, we need distinguished values when we want nothing, such as "none".
We already have a "none" value for (should be 6.2.5.1) job-sheets and 6.4.26
job-sheet-supported.
In fact I think that 6.4.26 job-sheets-supported (#type3EnumState)
should be changed to (1#type3Enum) in order to require at least one value.
Otherwise we have to specify what the meaning is of no values supported
(and our conformance requires that all attributes be supported).
Also what are all the type2EnumState and type3EnumState syntaxes supposed
to mean as opposed to type2Enum and type3Enum?
>>>>> 2. 6.1 Attribute syntaxes
>>>> Get rid of the TBDs
>>>>>> 3. 6.2.4.2 printer-assigned (name)
>>>> ISSUE: Get rid of it. Not needed for our model.
>>>> But maybe change it to local-output-device-name-used.
>> As the text indicates, this will help a user find the output if
>> the user has to do it himself/herself.
>>If xxx-used have a special meaning, I suggest not calling it
local-output-device-name-used.
I agree. I made a confusing suggestion.
xxx-used atributes all mean "used by the program that created the PDL",
not used by the Printer to print the job.
How about local-output-device-assigned (analogous to ISO DPA printers-assigned)?
>>>>>> 4. 6.2.6.1 notification-events
>>>> ISSUE:
>> Need to add a notification-address URL which allows the user or
>> the client to specify mail:// or http://
>>Is 'mail://' defined in some rfc?
Hiroyuki Sato wrote:
>If 'mail' means smtp, 'mailto' is a right one.
>More precise definition is 'mailto:End-User-Address at domain'.
What rfc should we cite?
>>>>> We have an 6.3.2 operation-notification-address that the client software sets
>> automatically. But if the end-user needs to be able to choose between
>> mail and http, we may need to add a notification method or a notification-
>> address that the user can supply.
>>>>>> 5. 6.2.7.4 job-retention-period
>>>> ISSUE:
>> Ok to delete for version 1.0. It will come back when we do ResubmitJob
operation
>> but that is when we need it, not now. Same for 6.4.31
>> maximum-job-retention-period. But keep the retained state (even though
>> not user affected in version 1.0), since its hard for client when the
>> servers add states.
>>>>I am not sure I agree with the deletion of this feature.
Neither did Hiroyuki Sato who wrote:
>This maximum-job-retention-period/number is useful from a End user's
>point of view and our Salutation prototype experience.
So lets keep the job-retention-period job attribute and the
maximum-job-retention-period printer attribute.
>>>>> 6. 6.2.8.2 number-up
>>>> ISSUE:
>> A simpler way to allow end-users to turn of embellishments, is to have
>> a distinguised value that turns it off. ISO DPA has "0", but a more
>> user friendly value would be "none". Then any other value, like "1",
>> or "2", or "4" is free to have any embellishments on it.
>>I am trying to avoid arbitrary distinguished values that only IPP gurus
know about.
>The question is whether a user would expect that number-up = 1 gives normal
printing
>with essentially no number-up.
No, I was suggesting that any value, except none, is free to include
emblishments, such as borders, pages numbers, title lines, etc., including
"1". So "1", "2", "4" all are free to include emblishments depending on
the site policy.
So "1" is just a way for a submitter to override some default that the
system administrator set up, say "2", because the SA is concerned about
saving trees.
I think that it is an important design principle that when a system
administrator can specify defaults that users have explicit ways to
specify all values, especially the value ("1" in the case of number-up)
that normally is used when neither the submitter supplies a value nor
the SA defines a default).
So the purpose of having a "none" value is for a submitter to be able
to force no emblishments.
Here is the current spec for number-up:
6.2.8.2 number-up (positiveInteger)
This attribute specifies the number of source page images to impose upon a
single side of an instance of a selected medium.
In general, only certain numeric values are valid for this attribute,
depending upon the Printer implementation to which the print request is
directed. Typical supported values are 2 and 4. If this attribute is
unspecified or has a value of 1, then the Printer does not apply any
number-up transformation to the pages.
This attribute primarily controls the translation, scaling and rotation of
page images, but a site may choose to add embellishments, such as borders to
each logical page.
ISSUE: should there be a separate attribute to control embellishments,
especially for the 1-up case?
Bob,
If you think allowing an implementor/SA to define emblishments as part of
the semantics of "1", "2", and "4" is a bad idea, then maybe we should have
another job attribute which controls emblishments, as suggested by the ISSUE.
Maybe something like:
embelishments (1#type3Enum)
This attribute specifies the emblishments that are to be imposed upon a
single side of an instance of a selected medium.
Standard values are: "none", "borders", "impression numbers", "title".
When used in combination with number-up, the "borders" emblishment
means a border around each logical page that is imposed on a side of the
medium.
The "impression numbers" value means number each impression outside
the area on which the logical pages are imposed.
The "title" value means put the document name at the top of each impression
outside the area on which the logical pages are imposed.
Comments?
>>>>>>> 7. 6.2.12.1 document-format
>>>> ISSUE:
>> Yes, make version optional. The problem is that if a driver says
>> PostScript level 2, but doesn't use any level 2 features, then a
>> level 1 printer is probably going to reject when it could have printed
>> the document. This is a tough problem.
>>>>>> 8. 6.3.2 operation-notification-address
>>>> ISSUE:
>> Keep, it cannot be inferred from the operation-user-name and
operation-host-name
>> in call cases.
>>>>>> 9. Additional job attributes:
>>>> add number of intervening jobs, so that you can see your position in
>> the queue, even if the site policy is not to let you see any other jobs.
>>>This attribute is a 'maybe'.
Why is this attribute a maybe? We decided to have it for the Job Monitoring
MIB in New Orleans. And other commentors suggested it too. If you list
just your jobs, it would be helpful to also know the likely number
of job ahead of you for each job.
>>>> 10. Additional printer attributes:
>>>> a. add number of jobs waiting to be printed or being printed
>>>> b. add scheduling algorithm with values: first-come-first-served and
>> shortest-job-first
>>We haven't addressed the issue of schedulers yet.
Some other commentor suggested that it would be helpful to be able to
find out what type of scheduler the Printer object used. In my experience
the two most common scheduling is FCFS and SJF. Of course the job-priority
attribute is factored into these policies.
Perhaps a better name for the printer attribute would be:
job-scheduling-policy
>>>>>> 11. Explain that the term Printer and the Printer object need not be
>> restricted to printing, but can be used to represent other kinds of
>> output processing.
>>>> Tom