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.