Randy
on@lexmark.com wrote:
> I have placed the August meeting minutes on the ftp server as
>
> ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0897.txt
> ftp://ftp.pwg.prg/pub/pwg/ipp/minutes/ipp-0897.pdf
>
> Additionally, I have attached these minutes in text format
> below.
>
> Don
>
> **********************************************
> * Don Wright don@lexmark.com *
> * Manager, Strategic Alliances and Standards *
> * Lexmark International *
> * 740 New Circle Rd *
> * Lexington, Ky 40550 *
> * 606-232-4808 (phone) 606-232-6740 (fax) *
> **********************************************
>
> --------
> Internet Printing Project Meeting Minutes
> August 6-7, 1997
> Redmond, WA
>
> The meeting started on August 6, 1997 at 9:10 AM led by Carl-Uno Manros.
> These
> minutes were recorded by Don Wright. The attendees were:
>
> * Lee Farrell - Canon
> * Don Wright - Lexmark
> * Steve Zilles - Adobe
> * Scott Isaacson - Novell
> * Bob Pentecost - HP
> * Tom Hastings - Xerox
> * Carl-Uno Manros - Xerox
> * Stuart Rowley - Kyocera
> * Peter Zehler - Xerox
> * Greg LeClair - Epson
> * Andy Davidson - Tektronix
> * Rick Landau - Digital
> * Jasper Wong - Xionics
> * Jeff Rackowitz - Intermec Corp
> * Theresa Rhoades - HP
> * Bob Herriot - Sun
> * Robert Tonkin - Kinkos
> * Paul Moore - Microsoft
> * Dave Kuntz - HP
> * Roger deBry - IBM
> * Ron Bergman - Dataproducts
> * Harry Lewis - IBM
> * Xavier Riley - Xerox
> * Monte Johnson - Intel
> * Philip Thambidurai - Okidata
> * Zuyi Sacchi - Japan Computer Industry
> * Yasuo Bato - Japan Computer Industry
> * Atsushi Uchino - Seiko-Epson
> * Dave Kellerman - Northlake Software
> * Cal Brabrandt - Intel
> * Bill Wagner - Osicom/DPI
>
> Carl-Uno Manros reviewed the agenda for the two days.
>
> Scott Isaacson began the technical part of the meeting with a review of
> comments
> and feedback concerning the model document.
>
> 1) "best-efforts" - currently a parameter, not an attribute. Discussion on
> the
> meaning of "best-efforts", what it means, is it granular enough, what about
> a
> pre-existing file of PDL? How does "PDL-override" interact with
> "best-efforts"?
> There was a significant number of participants believe that we would never
> be
> able to strictly define all the boundaries of "best-efforts" or
> "PDL-override"
> and that the details would be implementation dependent. We will have two
> values
> for "pdl-override" -- "attempted" and "not-attempted". For "best-efforts",
>
> "TRUE" and "FALSE" will remain the values. The intent is that
> implementation
> will do the best job as possible. "n-up" was identified as one of the
> attributes that would be very difficult to override with an IPP attribute.
> We
> decided to change "best-efforts" to be called "fidelity" and we reversed
> the
> meaning of TRUE and FALSE. TRUE means that the printer will do a really
> good
> job of guaranteeing fidelity or will reject the job. FALSE will mean that
> the
> printer has more flexibility in going ahead in printing if all the IPP
> attributes cannot be guaranteed. We removed the "best-efforts-supported"
> attribute. We will not provide a finer granularity for these
> attributes/parameters for version 1.0. Now the discussion moved to whether
>
> "Fidelity" should be a parameter or an attribute. As a result of this
> discussion, we decided to remove the "Get-Operations Request" and added a
> printer attributed called "Operations-supported" which can be requested and
> is a
> list of the supported operations. The discussion then moved to whether we
> should distinguish between parameters and attributes. At first, there was
> no
> general consensus as to whether we needed to differentiate these two
> values.
> Some wanted to keep a separate set of operation parameters and to allow
> them to
> be found and parsed first. Others felt we could just specify an order of
> the
> attributes. Eventually, the group came around to an agreement that there
> was no
> reason to have a separate set of items called parameters. Instead, we will
>
> define the order in which "operation attributes" will appear and that
> "operation
> attributes" will preceded "job template attributes" which will precede
> "document
> attributes."
>
> Carl-Uno suggested that we create a flow-chart or something similar that
> would
> explain the interaction of "fidelity" and "pdl-override" and put it in the
> appendix of the model document.
>
> 2) "job-problems" & "printer-problems" some editorial changes are being
> made to
> 4.2.2. The issue of what the content of the notification message was
> raised.
> This of course raised issues of internationalization and whether the
> information
> should be human readable or machine readable or both. This issue was not
> resolved at this time but is listed as one of the open problems.
>
> 3) Compression - leave it alone but add some references and perhaps add
> some
> additional compression types. We also decided that if compression is
> supported
> by the device, then "zip" must be supported. Because of the various
> versions of
> "zip" we decided that the "inflate/deflate" versions of "zip" would be
> adopted.
>
> 4) job-k-octets, job-impressions, and job-media-sheets - the issue is when
> is
> this data supplied? For example is the data is not provided by the client,
> when
> is this information supplied by the printer? -- is it counted when the
> job is
> submitted? -- when the job is complete? -- something else? If this
> information is not available, the printer should respond with a negative
> integer
> meaning unknown (-2). Additionally, these will be added as optional
> document
> attributes "document-k-octets", etc. These values, when queried, shall
> return
> the best available value as known by the printer. Therefore if the client
> tells
> the printer that the job is 1 byte and after the job has been received is
> actually 100 bytes, at that point, the printer will respond with 100 bytes
> rather than 1 byte. "job-k-octets" and the rest of these objects will not
> be
> multiplied by any copies value. The exact definitions of these will match
> the
> definitions in the Job MIB. As a side issue, we talked about creating
> separate
> attributes for collated-copies and uncollated-copies. Roger deBry will
> report
> on this proposal.
>
> 5) In the job object created when a job is created, we added job-name as
> mandatory and made the three objects "time-since-*" as optional and also
> made
> "number-of-intervening-jobs" optional. We will add two new attributes:
> "printer-current-time" and "printer-up-time". "printer-current-time" is
> DATE/TIME and "printer-up-time" is in ticks. We changed the three
> "time-since-
> *" attributes to "time-at-*". We also changed the units to seconds rather
> than
> milliseconds.
>
> 6) Should we make a statement about which attributes should be localized?
> Any
> keywords are not localized. Scott will be cleaning up some of the
> language in
> the document. Job-name and Document-name will be returned just as provided
> by
> the client. After a long and tiring discussion, the group decided to keep
> a
> human-language attribute on a job, delete all attributes that reference a
> character set, and mandate UTF-8.
>
> 7) New wording will be incorporated for processing as per Scott's
> documented
> proposal. Additional job-state-reasons will be included as collected in
> the
> meeting. Scott will attempt to match a reasonable set of job-states and
> associated job-state-reasons.
>
> 8) Remove logfile-pending and logfile-transferring as job-state-reason
>
> 9) number-of-intervening jobs is an optional attribute that will simply
> return
> the number of jobs ahead of a specified job.
>
> 10) Remove print-uri-user and better define the printer-more-info and other
>
> similar attributes. We came to no conclusion so we will leave this as an
> open
> issue and expect comments on the mailing list.
>
> 11) A long discussion was held about to deal with job identifiers and job
> uri's
> and how they would be used? -- how they would be mapped back to existing
> applications? -- what is the format of a job identifier? -- is it just an
> opaque string? -- should a cancel operation be directed to a printer uri or
> to a
> job uri? The group consensus was that the a job would be identified by two
>
> entities: the printer URI and a 32-bit integer that identifies the job.
>
> Roger deBry reviewed the plans for the Analysts briefing.
>
> The group reviewed the agenda for Thursday prioritizing the Protocol and
> Rational document before moving back to the model document.
>
> The meeting recessed at 6PM.
>
> The meeting resumed at 8:45AM on Thursday.
>
> The meeting started with a review of the Rationale document by Steve
> Zilles. No
> significant issues were raised or discussed.
>
> Xavier Riley reviewed an open issue relating to identification of the user.
> One
> option is to use a login name; the other is to use the user name obtained
> from
> the security credentials. The group reviewed John Wenn's recent note to
> the
> mailing list on this subject.
>
> The consensus of the group was that the Security document does not need to
> exist
> as a separate document. Rather, the "what" and "why" content of the
> document
> should be folded into the Model document and the "how" content should be
> folded
> into the Protocol document. There was a discussion on what is the minimum
> security that is required for an implementation to support.
>
> Paul Moore strongly expressed that he believed we should simply state that
> IPP
> requires whatever HTTP/1.1 requires. Steve Zilles wants IPP to specify a
> requirement for support Basic and Digest Authentication. IPP is not going
> to
> invent security; rather IPP will depend upon the underlying security of the
>
> protocol. The document will clearly identify the security mappings and
> usage in
> the document as examples and not requirements. A draft addition to the
> model
> document will be created by Scott Isaacson to talk about how user names
> will be
> obtained and used.
>
> Mid-morning break.
>
> After the break, we began reviewing the protocol document. We discussed
> the
> changes that were made to the model that affect the protocol:
>
> 1) Elimination of parameters in favor of attributes in the protocol
>
> 2) The effects of the change in job uri and job id from the model
> discussion on
> Wednesday needs to be incorporated into the protocol.
>
> Additional topics of discussion
>
> 1) Synchronize or eliminate the two lists of error codes in the model
> document
> and the protocol document - we will only have the list in the model
> document.
>
> 2) Tag type additions will be type 2. If there are additional types
> identified
> now that need to be added, they should be written up and presented at the
> September meeting in Atlanta.
>
> 3) Paul Moore will look at the HTTP header information contained in the
> protocol
> document and make sure it is correct. One area that is unclear is in the
> ACCEPT
> HEADER and CHARSET.
> Several other editorial comments were brought up will be included in the
> next
> revision.
>
> Lunch break at noon.
>
> After lunch, Steve Zilles reviewed the agenda plan for the Munich meetings.
>
> Scott Isaacson resumed reviewing the open issues with the model document.
>
> 1) Conditionally Mandatory is not sufficiently well defined in the model
> document. The group discussed a number of alternatives including
> defaulting
> certain values. The group looked at a number of attributes to see if
> default
> behavior or default values could be assigned.
> - priority = 50
> - number-up = 0
> - multiple documents = single
> - sides = 1
> - print quality = standard
> - finishing = none
> - copy = 1
>
> After long discussion, the group decided that the printer attributes (xxx-
> supported, xxx-default) will be optional. Scott will update the model
> document
> to reflect this direction.
>
> Scott will add text to the model document explaining that defaults are the
> default at the time the job is processed/printed not the default at the
> time of
> job submission.
>
> 2) MIME types - should we include more standardization of document formats
> as
> MIME type rather than an enumerated list of document formats and some kind
> of
> version numbering. Because there was no real solution to completely
> identifying
> the version of a document format, the group decided not to try to tackle
> this
> issue at this time.
>
> 3) Scott will write a section describing how the IPP model matches up with
> the
> Job MIB and Printer MIB.
>
> 4) For all transmission failures, the system should act as if a cancel was
> received at the point of the transmission failure.
>
> 5) A null document is a valid document both when it is flagged as "not the
> last
> document" and when it is flagged as the last document.
>
> 6) Registering of new attributes will use a type 2 process.
>
> 7) Changes to the order of the attributes, syntax of existing attributes or
> the
> "mandatoriness" of attributes would change the major version number.
> Changes to
> the model would be reflected by minor version number changes and changes to
> the
> protocol encoding would be reflected by the major version number. This
> will be
> written up in the model document.
>
> 8) The "dictionary" attribute type proposed by Tom Hastings will be written
> up
> and presented with the other new types in Atlanta.
>
> 9) Job-originating-user is determined by the server, job-user-label is
> supplied
> by the client.
>
> 10) Leave color as a boolean and consider the extensions for version 2 or
> for
> vendor extensions.
>
> 11) Rather than using the multi-valued job attributes to represent the
> attributes of the document as described in the model document in 3.2.6 Get-
> Attributes Operation, the document attributes will be group together with
> all
> the attributes for a single document will be grouped together. This new
> methodology will impact both the model and protocol. This will remain an
> open
> issue and will be worked.
> 12) We need to add an attribute document-charset attribute which indicates
> the
> charset of the document.
>
> 13) Add Optional filtering in Get-Jobs operation ---- no way!
>
> 14) Add job-started-processing as an enum value event to notify-events
> attribute
> that could cause a notification.
>
> 15) job-account-name would be a vendor extension and not a part of the IPP
> model.
>
> 16) PDF and HTML should be registered as document formats. (EMF will also
> be
> added by Roger deBry.)
>
> 17) Roger deBry requested the Validate-Job be made optional. Paul Moore
> explained the reason he wanted it was to prevent sending a large job only
> to
> find out that the server needed authentication and returning a
> www.authenticate.
> The group consensus was to leave validate-job as mandatory.
>
> 18) The list of operations supported will be a type 2 enum. A range of
> enums
> will include an experimental range that cannot be registered.
>
> 19) in 3.2.6, remove the "none" group.
>
> 20) 3.2.7.2 specifies the order of the jobs returned. Should we specify
> these
> or make them as implementation dependent? There was no obvious consensus
> so
> this issue was left open.
>
> 21) IBM requested additional attributes; these will be written up by Roger.
>
> "page-range" to allow selected a starting and ending page number
> "orientation" to change or force a specific orientation
> allow the client to define what the "assigned-printer" is so the
> server can rip the job and return it to the client's printer
> add the ability to specify what is to be printed on the separator
> sheet using the "job-sheets" attribute.
> Specify printer-location as hierarchical - no that is administrator
> specified
> We specify toner-low as a job state reason -- should that be more
> general - yes, Scott will write up.
> Roger proposed to add a media-ready attribute in addition to the
> media-supported attribute to be able to distinguish between media
> that could be loaded versus what is installed in the printer.
>
> Carl-Uno wrapped up the meeting with a reminder of the next meeting on
> September
> 17&18 in Atlanta. Written documents for that meeting should be made
> available
> by September 10th. These documents will not be released to the IETF until
> after
> they are reviewed and updated after the Atlanta meeting. These dates need
> to be
> e-mailed out and placed on the WEB page.
>
> The meeting adjourned at 6:00 PM.
> --------