But here are comments for ones I didn't put in the new version.
> From Keith_Carter@aussmtp.austin.ibm.com Thu Feb 20 13:41:02 1997
>
> 8. Section 5.3.2.1. notification-events. Page 22. Line
> 690.
>
> Here is an idea. It is possible that an end-user's job
> might be held or resubmitted outside the context of IPP
> 1.0. The spec could add support for "job-held" and
> "job-resubmitted" notification events or else indicate
> that these are implicit ala "job-cancelled". Opinions?
I see job-held as a job-state-reasons and not a job-state value.
It is not currently in the document because there is no way to
change its value. We have not specified whether there is a job-held
attribute or a hold/release operation.
We have not addressed whether such events are covered under an
existing event, such as job-problems, or some new event.
>
> 10. Section 5.3.3.2. job-retention-period. Page 24. Line
> 774-775.
>
> Add to the NOTE: "The requester may also specify this
> job attribute using the input parameter to the Print
> operation." Correct?
No, the job-retention-period is an attribute that accompanies a job
in the Job and Document Attributes parameter.
>
>
> 12. Section 5.3.5.2. medium. Page 30. Line 896.
>
> I recommend an additional input-tray of "automatic"
> since some printers automatically select the input tray
> based on the media requested by the end-user.
I think that "automatic" is the same as "as-is", in that it says
to use whatever is in the document data which may be nothing. So the
issue is whether to call the value "automatic" or "as is"
>
> 13. Section 5.3.6.1. document-format. Page 34. Line 975.
>
> The list of document-formats should be referenced in
> this section. Possibly include the formats in an
> appendix or reference another spec.
>
> >
> 16. Section 5.3.7.14. content-orientation. Page 36. Line
> 1046.
>
> In my opinion, content-orientation should be a Document
> Production attribute. This attribute may apply to all
> types of print jobs - not just text jobs - including
> jobs that are converted by an IPP print driver from a
> graphics API (e.g. Gpi or GDI) to a device datastream
> such as Postscript or PCL.
Please say more. I have assume that a graphics API (e.g. GDI) includes
the content orientation and for that matter the page layout, so it
doesn't make sense to specify content-orientation, which in my view
specifies the first level of page layout.
>
> 17. Section 5.3.9. Number of Documents. Page 37. Line
> 1079.
>
> Nit. How does a Printer specify there is no limit on
> the number of documents per job? By using an "*"
> (asterisk) as the upper number of the range? A large
> number?
We haven't yet specified how one end of a range is open.
But if the syntax is 'a:b', then either 'a:' or 'a:*' could mean
that the range has no upper bound.
>
> 26. Section 5.5.1. printer-name. Page 43. Line 1215.
>
> In my opinion, the spec should keep the "printer-name"
> attribute so an Administrator can provide a meaningful
> name to the Printer.
>
The printer-name attribute was renamed 'name' and moved to the common
attributes section which also contains URL.
> 27. Section 5.5.2.2. printer-type. Page 44. Line 1221.
>
> Is printer-type necessary in IPP 1.0? How does this
> help the end-user?
I agree.
>