IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE

IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE

IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE

Keith_Carter at aussmtp.austin.ibm.com Keith_Carter at aussmtp.austin.ibm.com
Fri Feb 21 09:01:21 EST 1997


  Bob,


  Thanks for editing the IPP model and semantics spec and your response.
  My response noted inline as KC>>


  Keith
  To:       Keith Carter
  cc:
  From:     DELEGATE @ AUSVMR
  Date:     02-20-97 08:23:52 PM
  Subject:  RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS
            SPE






  To: KCARTER --AUSNOTES


  From: DELEGATE
  Subject: RE: IPP> MOD - COMMENTS ON VERSION 1.3 OF MODEL AND SEMANTICS SPE
   +--------------------------------------------------------------------------+
   H  The following note is being forwarded from KCARTER at AUSVMR.           H
   H  DO NOT USE the F6 REPLY function to reply to this note. You must        H
   H  contact the sender directly if you wish to reply, and not DELEGATE.     H
   +--------------------------------------------------------------------------+


   ---------------------------- Note:    -------------------------------------
   Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with
      Thu, 20 Feb 97 21:21:04 EST
   Received: from localhost (daemon at localhost) by lists.underscore.com
  (8.7.5/8.7
   Received: by pwg.org (bulk_mailer v1.5); Thu, 20 Feb 1997 21:19:34 -0500
   Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id
  VAA
   Date: Thu, 20 Feb 1997 18:17:04 -0800
   From: Robert.Herriot at Eng.Sun.COM (Robert Herriot)
   Message-Id: <199702210217.SAA16024 at woden.eng.sun.com>
   To: ipp at pwg.org, Keith_Carter at aussmtp.austin.ibm.com
   Subject: Re: IPP> MOD - Comments on version 1.3 of Model and Semantics spec
   X-Sun-Charset: US-ASCII
   Sender: ipp-owner at pwg.org


   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.


  KC>>  It sounds like we should postpone this until IPP 2.0.
  KC>>  There are LAN printing solutions that post events
  KC>>  to end-users when their job is held or resubmitted because
  KC>>  the end-user might not always have a Printer icon open on
  KC>   their desktop to view their job's status.


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


  KC>>  I understand and agree.


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


  KC>>  Agreed.  I think "automatic" is clearer but "as-is" is fine if
  KC>>  we state its meaning in the spec.  I didn't see "as-is" nor
  KC>>  "automatic" in version 1.3.1 of the spec.


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


  KC>>  You're correct.  My mistake - too many margaritas.
  KC>>  Let's leave content-orientation asis.


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


  KC>>  Ok.  The spec should specify the syntax.  We should decide this
  KC>>  very quickly at our telecon today.  I vote for 'a:*'.


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


  KC>>  I understand and agree.  Thanks.


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


  KC>>  Sounds like we both tend to agree this isn't necessary for
  KC>>  IPP 1.0.  Let's discuss at the telecon today.


   >


  >>>> DO NOT REPLY TO THIS NOTE <<<<



More information about the Ipp mailing list