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

Keith_Carter at aussmtp.austin.ibm.com Keith_Carter at aussmtp.austin.ibm.com
Thu Feb 20 15:37:46 EST 1997


  Model and Semantics Team,


  Here are my comments on version 1.3 of the IPP 1.0:  Model and Semantics
  spec.  I'll comment on Tom's document on printer status on 2/21.


  Enjoy!


  Keith


  1.  Section 3.2.  Job.  Page 8.  Line 302.


      Remove "This list needs updating:" from list.


  2.  Section 4.1.3.1.  Get-Attributes Request.  Page 12.
      Line 419.


      In my opinion, we should list the special attribute
      groups referred to in the subsequent sections of the
      spec so it is clear to the reader that an IPP
      application may specify these groups in a Get-Attributes
      request. These attributes groups include:


      -  identification (5.2.1)
      -  jobClient (5.3)
      -  jobTemplate (5.3)
      -  jobNotification (5.3.2)
      -  jobScheduling (5.3.3)
      -  jobProduction (5.3.4)
      -  documentProduction (5.3.5)
      -  textFormatting (5.3.7)
      -  jobSize (5.3.8)
      -  numberOfDocuments (5.3.9)
      -  jobSetByPrinter (5.4)
      -  jobOwner (5.4.1)
      -  jobStatus (5.4.2)
      -  documentData (5.4.3)
      -  printerDescription (5.5)
      -  printerStatus (5.6)
      -  printerBehavior (5.7)


  3.  Section 5.1.  User privilege level.  Page 17.  Line 530.


      The security model implied by the "User privilege level"
      tag is not clear to me.  I believe a Printer should know
      the role (i.e. end-user, operator, admin) of the user
      making a print request and should only return attributes
      that apply to a person with that role for that Printer.
      I do not believe a Printer should rely on a client to
      sort through which attributes apply to a user based on
      the client's understanding of the user's role.  See my
      notes for section 6, Security Considerations for more
      information.


  4.  Section 5.1.  File type.  Page 17.  Line 536.


      In my opinion, the "File type" tag is too complex for
      IPP 1.0.  I believe the "File type" tag implies (1) an
      IPP application must first determine the datatype of a
      document to be printed (2) the application must then
      parse through attributes returned by the Printer to pick
      out those that apply to that datatype (3) a Printer
      implementation must tag these attributes in the first
      place.  Typically, I see administrators setup a separate
      Printer for each datatype supported by a physical
      device.  For example, for a device that supports PCL and
      Postscript, there will be 2 Printers.  Each Printer has
      its own printer driver (i.e. a PCL or Postscript printer
      driver) with default job properties (i.e. job template)
      supported by the driver.


  5.  Section 5.1.  Scheduling.  Page 18.  Line 547.


      What specific attributes can have the "Scheduling" tag?
      What is a scenario that shows how this tag will be used?


  6.  Section 5.1.  no tag.  Page 18.  Line 572.


      "... this value and schedule it ..." should be "... this
      value and schedule the job when ...".


  7.  Section 5.3.2.1.  notification-events.  Page 22.  Line
      690.


      This section needs to specify the events for which an
      end-user will implicitly receive notification.  Line
      709-710 implies that an end-user will always receive a
      notification if their job is cancelled.  So, that
      explains why there is not a notification event called
      "job-cancelled".  This statement also implies a required
      behavior of a Printer.  This information might be more
      clear to the reader if it is stated in the
      notification-events section.  Here is a proposed
      paragraph:


      A Printer must notify an end-user when their job is
      cancelled and therefore will not be printed by the
      Printer.


      Or, we can decide to add a "job-cancelled" value.


  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?


  9.  Section 5.3.3.1.  job-priority.  Page 23.  Line 722.


      Please change job-priority to a positiveInteger with
      values 0-100 because: (1) this matches the Job MIB (2)
      this supports ISO DPA (3) this supports PC platforms.


  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?


  11. Section 5.3.4.2.  copies.  Page 26.  Line 844-845.


      Remove this note because files-are-one-document and
      files-are-interleaved are not defined in the spec.


  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.


  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.


  14. Section 5.3.7.  Text Formatting.  Page 34.  Line 981.


      Please consider adding the following attributes:


      *  Font Style (normal, bold, italic, bold-italic)
      *  Line Numbers (print line numbers in the left margin)
      *  Text Border (print a border around the text)
      *  Word Wrap (wrap or don't wrap long lines)
      *  Number of Columns (single or multi-column text)
      *  File Name (print file name per page)
      *  File Time (print time of file per page)
      *  File Date (print date of file per page)


  15. Section 5.3.7  Text Formatting.  Page 34.  Line 981.


      Can Document Production Attributes, such as sides, apply
      to printing Text and HTML files?  I believe so.  If so,
      then the spec should state this.


  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.


  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?


  18. Section 5.4.  Job Attributes.  Page 38.  Line 1093-1099.


      The second paragraph indicates that an IPP application
      can get the URLs of a Printer's Job Templates and
      references attribute "printer-job-templates" neither of
      which is supported in IPP 1.0.  Here is proposed text
      for that paragraph with revisions noted as <>:


      A client may use a job template associated with the
      selected <P>rinter to initialize the job.  To do so, the
      client uses the Get-Attributes operation <with the
      "jobTemplate" attribute group in the request to a
      Printer to obtain all attributes and values that an
      end-user or application may specify when printing a job
      on the Printer.>  Then the client may get the default
      attributes, <the default value for each attribute, and
      the supported values for each attribute to display this
      information to the end-user when they submit a print
      job.> <delete: "See the printer-job-templates Printer
      attribute.">  However, a client need not access the
      <j>ob <t>emplate <attributes> to issue a Print
      operation; the client can depend on the Printer to
      supply the default job attribute values as part of the
      Print operation.


  19. Section 5.4.1.1.  job-originating-user.  Page 38.  Line
      1110.


      The spec should state that job-originating-user is
      acquired by the Printer from the protocol used for the
      Print operation.  For HTTP 1.0, this would imply use of
      the Authorization request header field on a Print
      operation so the Printer can obtain the user id of the
      end-user who submits the print request.  A proposal is
      to change the word "client" at the end of the second
      sentence to "protocol".


  20. Section 5.4.1.3.  user-locale.  Page 38.  Line 1114.


      The spec should reference the source of the valid locale
      values.  The reference could be a URL or to an appendix
      in this spec.


  21. Section 5.4.2.2.  job-state.  Page 40.  Line 1137.


      In my opinion, the "Printing" job-state should only be
      set if a job is actually being printed by a device.
      This way, an IPP application can clearly show an
      end-user when their job is being printed.  I propose we
      use "pending" if the job is being spooled or has been
      queued for a device and use a job-state-reason to
      specify why the job is pending.  See comment #23 for
      more information.


  22. Section 5.4.2.2.  job-state.  Page 40.  Line 1137.


      In "Completed" remove "(2) job-discard-time has
      arrived." since job-discard-time is not supported.


  23. Section 5.4.2.2.  job-state-reasons.  Page 40.  Line
      1137.


      Please confirm/correct the following table.  An asterisk
      "*" indicates a combination I don't see in the spec.


      job state   job state reason             condition


      unknown     n/a                          n/a
  *   pending     job-spooling                 job spooling
  *   pending     sending-job-to-printer       job being sent
                                               from client or
                                               server to
                                               device
  *   pending     job-queued                   job queued
      pending     job-processing               job in printer
      pending     required-resources-not-ready paper out etc.
      pending     logfile-pending              ?
      pending     logfile-transferring         ?
  *   pending     job-held                     job held in
                                               queue or device
      printing    n/a                          job printing
      terminating cancelled-by-user            job ending
      terminating cancelled-by-operator        "
      terminating aborted-by-system            "
      retained    successful-completion        job stacked and
                                               retained
      retained    completed-with-warnings      "
      retained    completed-with-errors        "
      retained    cancelled-by-user            job cancelled
                                               and retained
      retained    cancelled-by-operator        "
      retained    aborted-by-system            "
      completed   successful-completion        job stacked
      completed   completed-with-warnings      "
      completed   completed-with-errors        "
      completed   cancelled-by-user            job cancelled
      completed   cancelled-by-operator        "
      completed   aborted-by-system            "


      In my opinion, we should replace "job-incomplete" with
      "job-spooling", "sending-job-to-printer" and
      "job-queued" so an IPP application can show the end-user
      the state of their job throughout the printing process.


  24. Section 5.4.2.5.  submission-time.  Page 41.  Line 1149.


      In the first sentence, specify that submission-time
      indicates date in addition to time.


  25. Section 5.4.2.6.  number-of-intervening-jobs.  Page 42.
      Line 1154.


      Please change "if performed" to "is performed".


  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.


  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?


  28. Section 5.5.2.3.  maximum-printer-speed.  Page 44.  Line
      1229.


      "characters per minute" should be "characters per
      second" to match "cps" in standard units.  What is the
      syntax for 10 ipm?


  29. Section 5.6.  Printer Status.  Page 44-46.


      I will comment on Printer Status in a separate note.


  30. Section 5.7.1.1.  printer-locale.  Page 47.  Line 1286.


      There is no "job-locale" attribute in the spec plus the
      locale values are not defined in the spec.  Change
      "job-locale" to "user-locale" and use the reference in
      "user-locale" as a reference to the valid locale values.


  31. Section 5.7.1.4.  end-user-acl.  Page 47.  Line 1289.


      How is "end-user-acl" used?  I believe a Printer should
      know its acl (i.e. end-user, operator, admin) for the
      end-user who makes a print operation and, based on this
      acl, determine if an operation is valid.  I do not
      believe a Printer should return acls to a client and
      then rely on a client to determine if an end-user is
      authorized to use a Printer.  Besides, I'm not sure we
      want acl information flowing across the network.  I
      propose we remove this attribute.


  32. Section 5.7.1.4.  scheduling-algorithm.  Page 47.  Line
      1297.


      How does this attribute help the end-user?  I propose we
      remove this attribute from IPP 1.0.  I believe we
      removed a similar attribute from the Job MIB.


  33. Section 5.7.1.  Printer Behavior.  Page 47.  Line 1283.


      Please keep "document-formats-supported".  This
      attribute will help an IPP printer driver determine the
      valid formats for a Printer so that the printer driver
      can send the most efficient format possible to the
      Printer.  For example, OS/2 supports a metafile format
      as well as device formats such as PCL and Postscript.
      It is more efficient to send a metafile across the
      network if a Printer supports this format in addition to
      a device format.


  34. Section 6.  Security Considerations.  Page 48.  Line
      1319-1320.


      Remove sentence "The authentication mechanism built into
      HTTP ..." since the spec does not specify a protocol and
      therefore should not specify HTTP.


  35. Section 6.  Security Considerations.  Page 48.  Line
      1319-1320.


      How is an end-user's identity known by the Printer for
      operations such as CancelJob and GetAttributes?  Does
      IPP assert that the underlying protocol provides the
      identity of the end-user on print operations?  If so,
      the spec should state so.  For HTTP 1.0, this would
      imply use of the Authorization request header field on
      such requests (hopefully after the initial logon, the
      client will cache the user id and password so as not to
      prompt the end-user to logon for every subsequent print
      operation).


      Here is proposed text for this section with revisions
      noted as <>:


      This <specification> does not identify any new
      authentication mechanisms.  <This specification relies
      on the underlying protocol to identify an end-user
      (possibly using a user id and password) to a Printer for
      each print operation.  Furthermore, this specification
      relies on the Printer to authorize each print operation
      and to only return attributes for which an end-user is
      authorized to view and specify.>


      <delete 2nd and 3rd paragraphs>



More information about the Ipp mailing list