April 14-15, 1999

Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics:

• Verify suggested resolution texts for issues where we have agreements
• Discuss and (hopefully) resolve any open issues remaining for IPP/1.0
• Discuss and (hopefully) resolve any open issues remaining for IPP/1.1
• IPP testing – do we want to start work on an IPP test specification?
• Other IPP activities – are we ready to start discussing a multi-vendor demo?
• Discuss a plan for further IPP extensions, such as notifications
• JMP and IPP attributes correlation

Mike Moldovan of Genoa presented some slides on IPP/1.0 compliance testing. Genoa is interested in developing a test suite that would be sold/licensed for general use in the industry. Genoa has developed test suites for other protocol specifications, including 1284, IrDA, TWAIN, and JetSend. As an initial step, Genoa would like to develop a test specification (based on the IPP/1.0 specification documents.) Genoa’s approach is to include the appropriate standards group in the review process of the test specification, and would like the IPP WG to participate in the specification effort.

Genoa is currently planning to concentrate on Server testing, but suggests that Client tests could also be defined.

Mike briefly reviewed the testing methodology used by Genoa, and provided some examples of possible tests that would probably be included in the suite.

He suggested that a first draft specification could be available by July and, depending on IPP participation, a final draft could be available as early as August. Genoa’s assumptions are based on a 200-test case estimate. Carl-Uno commented that he believes an August delivery schedule is very ambitious.

When the group was asked for volunteer participants, very few people raised their hands. However, no one objected to the suggested proposal.

Harry Lewis proposes that five of the Job MIB attributes should be added to IPP:

• sheetCompletedCopyNumber
• sheetCompletedDocumentNumber
• jobCollationType
• impressionsInterpreted
• impressionsCompletedCurrentCopy

Harry will develop a proposal for adding support of these attributes as extensions to IPP. The group will review the details of his proposal and discuss it on the e-mail reflector.

Tom Hastings referenced the latest "Issues" document and led a review of the remaining open issues. (This document is available at "ftp://ftp.pwg.org/pub/pwg/ipp/Issues/issues-raised-at-bake-off2.pdf".)

At the last IETF IPP Session, it was suggested that the IPP/1.1 specification documents could be written to include information describing the differences between IPP/1.0 and IPP/1.1. (This information could include any "bug fix" results that are applied to IPP/1.0 problems. Or should this be called "IPP/1.0a"?) The primary benefit of doing this would be to consolidate all the information for both versions of the standard in one place—and enable us to obsolete the Experimental RFCs that describe IPP/1.0.

A proposed method for enhancing the IPP/1.1 specification has been suggested, and was reviewed by the group:

Tom identified 12 different items for which the conformance requirements differ between IPP/1.0 and IPP/1.1. The group reviewed and discussed each of the items, resulting in the following list:

1. IPP/1.1 clients MUST be able to issue both IPP/1.1 and IPP/1.0 requests and accept both IPP/1.1 and IPP/1.0 responses.
   à Some people in the group suggested that this requirement should not be included in IPP/1.1. It should be an implementation decision to be interoperable with IPP/1.0 devices or not. This item will be removed from the specification and discussed in the Implementer’s Guide.
2. IPP/1.1 Printers MUST accept and support both IPP/1.1 and IPP/1.0 requests and responses.
   à As with item 1 above, it was suggested that this item should not be included in the specification, but should be discussed in the Implementer’s Guide. However, the group was not able to reach agreement.
3. IPP/1.1 clients and Printers MUST support the IPP scheme; it is OPTIONAL for IPP/1.0. IPP/1.0 clients and Printers MUST support the HTTP scheme. IPP/1.1 Printers MUST support the HTTP scheme.
4. IPP/1.1 clients SHOULD support TLS and non-TLS access; it is OPTIONAL for IPP/1.0. IPP/1.0 clients SHOULD support SSL3 and non-SSL3 access; it is OPTIONAL for IPP/1.1.
5. Printers MAY support SSL3 access, access without SSL3 or both. In addition, IPP/1.1 Printers SHOULD support TLS access, MAY support access without TLS, or MAY support both means of access; it is OPTIONAL for IPP/1.0.
6. Possible resolution of OPEN ISSUE 32: IPP/1.1 clients and Printers MUST support Digest; it is OPTIONAL for IPP/1.0.
7. IPP/1.1 Printers MUST return "document-format=xxx" in the Unsupported Attributes Group; it is UNSPECIFIED for IPP/1.0. See Issue 11.
8. IPP/1.1 Printers implemented as a forwarding server that can't get status from the device or print system (such as LPD) that it forwards jobs to, MAY put the job into the 'completed' state after forwarding the job. However, such implementations MUST support the "job-state-reasons" attribute with the 'queue-in-device' value when it puts the job into the 'completed' state, as an indication that the job is not necessarily completed; it is UNSPECIFIED for IPP/1.0 forwarding servers. See Issue 14.
9. Possible resolution of OPEN ISSUE 17: IPP/1.1 Printers MUST support dateTime for the new or existing Job attributes; it is OPTIONAL for IPP/1.0.
   à The group decided that this item is dependent on the resolution of ISSUE 17.
10. IPP/1.1 Printers MUST support "compression" and "compression-supported" attributes with at least the 'none' value. IPP/1.0 Printers MUST at least check for the "compression" attribute being present and reject the create request, if they don't support "compression" and "compression-supported". Not checking is a bug, since the data will be unintelligible.
    à It was suggested that the second sentence of item 10 should be moved to the Implementer’s Guide.
11. IPP/1.1 Printers MUST support "queued-job-count"; RECOMMEND for IPP/1.0.
12. Possible resolution of OPEN ISSUE 30: IPP/1.1 Printers MUST support "job-state-reasons" and "printer-state-reasons"; it is OPTIONAL for IPP/1.0.

After much discussion, the group was unable to come to any general agreement about incorporating the 12 items in the specification, so the topic was deferred.

It was noted that a source for "network time" cannot always be guaranteed (e.g., implementations operating on a LAN). Because of this, it was suggested that the support of absolute time should only be mandated if an arbitrary value could be substituted for those environments that do not have network time available.

Tom reviewed several possible alternatives that are identified in the Issues document. During the review, a few additional alternatives were also considered.

The group agreed that the specification should clarify that the "time-at-xxx" attributes can be negative if an IPP Printer is re-booted while jobs remain.

The group agreed to add to the IPP/1.1 Model and Semantics document OPTIONAL job description attributes: "date-time-at-creation (dateTime)", "date-time-at-processing (dateTime)", and "date-time-at-completion (dateTime)".

At the first straw poll vote, 7 people voted for both attributes being required; 2 were against. 12 voted for printer-state-reasons being required; 0 against. After more discussion, 13 people voted for job-state-reasons being required; 1 was against.

Three alternatives were being considered: job stays in 'processing', job moves to 'pending', job moves to 'pending-held' job states. Any of the alternatives MAY use a new 'waiting-to-print' job state reason to indicate that the job has been ripped but is waiting for the marker in a high-end system. The 'pending-held' state is used by systems where the Operator explicitly does a Release-Job to schedule the next job to be marked, while the 'pending' state is used by systems that choose the next job to mark automatically. The 'processing' state is used by systems that tend not to have much time between ripping and marking.

There was a long discussion about the general intent of the Issue, and how the Printer model might be expanded. The group considered the support of different job state reasons, and settled on "queued-for-marker".

Carl-Uno opened the day’s discussion with some background information on the IETF perspective and the differences between "defacto" standards and IETF Standards. He drew a parallel between HTTP/1.0 vs. HTTP/1.1 and the current IPP e-mail discussion about SSL3 vs. TLS. Essentially, because the IESG has rejected SSL3, he informed the IPP WG that we should no longer discuss SSL3 as a consideration for our specification of IPP/1.1. Similarly, the discussion of Basic vs. Digest for authentication should not continue either. Basic (alone) will not be accepted by the IESG.

To meet the IESG authentication requirement, Carl-Uno identified that the simplest approach would be to use Digest. Other alternatives include using the TLS authentication. He noted that "TLS + Basic" (which means TLS negotiation without TLS authentication + Basic authentication) and "TLS + Digest" (TLS negotiation without TLS authentication + Digest authentication) would both be acceptable by the IESG.

The group launched into yet another long, heated, and frustrating discussion about how the IETF rules do not seem to be consistent with the Printer Working Group member’s consumer-oriented goals. In response, Carl-Uno attempted to review the historical decisions and advice received from the Area Directors—but it did not seem to lessen the group’s frustration. Several people expressed their feelings that the IESG "official point of view" seems to change unpredictably—sometimes appearing to be almost whimsical.

Further discussion included a reference to the "administrative nightmare" associated with Digest—and an observation that most administrators would probably turn off Digest-capable features. Also, it was noted that several implementers would prefer to use SSL3 + Basic (although this is not acceptable to the IESG.)

The discussion ended with a proposal for support of TLS + Basic by both client and Printer as the least offensive compromise available. A more formal proposal describing the details that will specifically constitute TLS negotiation still needs to be written.

After a break, the group wanted to discuss whether the support of TLS + Basic should be MANDATORY or OPTIONAL. However, Carl-Uno pointed out that the IESG will not endorse any IPP protocol that does not require security support as MANDATORY.

Several of the attendees said they would like the opportunity to discuss the security issues directly with Keith Moore, the IETF Area Director. Although Carl-Uno has represented Keith’s directives as best he could, some of the group would still like the opportunity to have Keith participate at the next meeting—either directly or via teleconference. It is generally felt that such interaction is much more productive than e-mail communication.

Later in the day, Harry Lewis shared the content of a private e-mail that he received during the break from Keith Moore. In essence, Keith re-confirmed that IPP MUST require that all implementations support authentication. There were many more details in the e-mail message, and Harry will copy it to the reflector for general reference.

After hearing Keith’s response, Hugo Parra made a new proposal: Clients must support TLS + Basic AND Digest; Printers must support TLS + Basic OR Digest. The group acknowledged that this is a modification to the previous agreement, but consensus was reached to adopt Hugo’s new proposal. A more formal proposal describing the details will be distributed for review.

If an IPP Printer supports both authenticated and unauthenticated access, there is currently no method for a client to force itself to be authenticated, i.e., be in identified mode, since it is the server that forces authentication by issuing a challenge to the client. It is very useful for a client to be able to get into identified mode as soon as possible. Today you have to wait to be challenged by the server, which may never happen – or happens at an unpredictable time. The security conformance requires that the authentication for operations be the same for all operations. So for authenticated Cancel-Job, the Print-Job has to be authenticated as well.

This Issue was submitted by Paul Moore (not present at the meeting), and during the discussion it was apparent that different people interpreted his issue differently. Some individuals were not convinced that there is a real problem that even needs to be addressed.

After reviewing the possible alternatives listed in the Issues document, the group agreed on the following solution:

Two specific items were raised for further clarification:

• Should all operations be challenged if any one of them is?
• Consider the use of "uri-authentication-supported" + SLP

A more detailed proposal will be submitted to the e-mail list for review and confirmation that Paul’s concerns have sufficiently been addressed.

The group agreed to the suggested proposal contained in the Issue document. If the HTTP compression can be used, it could be removed from the IPP layer.

Carl-Uno asked if there was any interest in coordinating a demonstration of multi-vendor interoperability. He estimated that something could be organized to occur some time in autumn. It was suggested that the marketing organizations of the member companies should be consulted.

Perhaps the Seybold or Xplor conference would be an appropriate venue?

Carl-Uno suggested that we should begin to re-explore the requirements for Notifications soon. There was general agreement with this suggestion. Tom Hastings suggested that a separate sub-group should be organized to address the topic. He believes that it would be more efficient to generate a draft proposal that would then be submitted for review by the whole group.

Tom Hastings, Harry Lewis, Ron Bergman, and Hugo Parra all volunteered to coordinate on this effort.

Some suggestions for additional extensions to IPP were identified:

• Set attribute operation
• The authentication section of the model document should be fixed
• Administration capability

Interested individuals are invited to generate draft proposals for requirements lists on the above items.

Tom Hastings led a review of the solutions identified for each of the remaining items in the Issues document. The group agreed to the solutions, with the following modifications:

• Issue 4 – change the wording to SHOULD instead of MUST
• Issue 5 – change the wording to SHOULD instead of MUST
• Issue 7 – the Implementer’s Guide should only describe what Microsoft has done rather than recommend its usage. Also, do not attempt to further define the term "make".
• Issue 11 – change "MUST" to "NEED NOT". Remain silent about IPP/1.0.
• Issue 18 – add OPTIONAL "date-time-at-xxx", and clarify that "time-at-xxx" can be negative after a reboot
• Issue 19 – add that op admin can do send_document
• Issue 21 – add "uri-authentication-supported" attribute
• Issue 26 – do not impose order of additional groups
• Issue 33 – [no clear consensus was reached on this issue, but many individuals suggested that an informative annex should identify the differences between IPP/1.1 and the Experimental RFCs]

Carl-Uno wants to have the complete list of Issues identified by the end of April. He hopes to submit a set of documents to the IETF that will define IPP/1.1 in May.

IPP meeting adjourned.