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

From: [email-masked]
Date: Fri, 21 Feb 1997 09:01:21 -0500

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@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@localhost) by lists.underscore.com (8.7.5/8.7.3) id
  VAA
   Date: Thu, 20 Feb 1997 18:17:04 -0800
   From: [email-masked] (Robert Herriot)
   Message-Id: <[email-masked]>
   To: [email-masked], [email-masked]
   Subject: Re: IPP> MOD - Comments on version 1.3 of Model and Semantics spec
   X-Sun-Charset: US-ASCII
   Sender: [email-masked]

   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 [email-masked] 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 <<<<