IPP> MOD - Comments on version 1.3 of Model and Semantics spec

IPP> MOD - Comments on version 1.3 of Model and Semantics spec

IPP> MOD - Comments on version 1.3 of Model and Semantics spec

Robert Herriot Robert.Herriot at Eng.Sun.COM
Thu Feb 20 21:17:04 EST 1997


I have incorporate most of your comments, as well as those from
Roger and Tom.  I will put a new version 1.31 out on the Web tonight.


But here are comments for ones I didn't put in the new version.


> From Keith_Carter at 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.


> 



More information about the Ipp mailing list