Minutes IETF IPP WG Meeting, 97/12/10, Washington DC 1-3PM, Executive Meeting Room These minutes were taken by Steve Zilles. Carl-Uno Manros began the meeting with an overview of the documents and the agenda for the meeting: Review suggested resolution of existing issues on: - Model and Semantics document, presented by Scott Isaacson - Protocol Specification document, presented by Bob Herriot In the recording below, issues and their suggested resolution are recorded as presented (sometimes with some expansion for clarity). In most cases there was no discussion and the proposed solution was accepted as presented. If there was a discussion, this is recorded after the presented solution and if a different decision was made, this is recorded after the discussion as a decision. Model Document Issues, Scott Isaacson 1. Major/Minor Versioning Rules Mandate common encoding across all versions All elements added in a new minor version can be ignored New major version indicates new support requirements 2. Allow empty attribute groups Be conservative in what is sent; send an empty group Be liberal in what is received; allow missing group on reception 3. ALL operations MAY return "Unsupported Attributes" 4. Define protocol value-size upper bounds for URIs, charsets, natural languages, identifiers, ... 5. MUST-implement requirements for text and name strings; each string has a maximum length specification: some 63 octets, others 127 or 1023 octets Clarified validation checks for operation processing Non-secure implementation client supplies "requesting-user-name" If client does not supply a name, the printer will generate one (which need not be unique) Discussion: Is an authenticated mode required of all Printers Keith Moore would like to have this be true; without it the protocol will not be interoperable; that is, two implementations of the spec may not be able to find a common (authenticated) communication path Keith asserts that the current rules require this, because use of an Internet accessible printer will require authentication; Keith believes that submitting it as documented will cause kick back from the IESG. But, for interoperability, it is not the case that both client and server must do all the mechanisms as long on one or the other must do all; that means that requiring all clients to do the secure solution is enough to meet Keith's understanding of the rules Jim Gettys: HTTP has an issue raised by Lotus to multiple servers, serving a single site; It appears that Digest Authentication (with a few tweaks based on an idea of Paul Leach) may meet this need.(and that Microsoft and Netscape may be likely to implement Digest) Details on this discussion will play-out on the HTTP mailing list over the next few weeks. Keith Moore: Whether Digest Authentication is enough is not an issue of whether it is secure enough, but whether this solution is sufficiently scalable (Jim G asserts that Paul Leach's solution may solve the scalability issue) Keith points out that Diffie-Hillman is a (now) unencumbered mechanism for key exchange and should be relatively easy to implement. It is noted that there are two different classes of interoperation over the Internet: (1) remote access to a private resource (such as the printer on my desk) versus (2) providing a service to all comers (such as a Kinko's service) over the Internet. Scalability is not an issue in the first case. It was suggested that we identify the basic mode as "authenticated" mode (because Digest Authentication is already mandated for all HTTP/1.1 clients) and the full TLS based mode as secure mode. Decision: Digest authentication is already mandated for all HTTP/1.1 clients IPP will mandate TLS for all clients 8. Removed "copies-collated" attribute 9. Identified sources for all text and name valued attributes: end user device vendor, operator administrator allow any natural language for non-generated strings name change to "generated-natural-languages-supported" 10. Keep "charset-supported" 11. Clarified semantics of "page-range" attribute 12. Support for Media attributes If supporting "media-default", then MANDATORY If supporting "media-supported", then MANDATORY If supporting "media-ready", then OPTIONAL 13. Added missing status codes "server-error-not-accepting-jobs" "server-error-version-not-supported" 14. Asserted that IPP is already aligned with <draft-iesg-iana-considerations-01.txt> 15. Made "application/ipp" a "common usage" media type added "request ID" to allow matching of responses to corresponding request for protocols other than HTTP (e.g. SMTP) included all parameters, including the target object URI, within the application/ipp body 16. Security Allow for "non-secure", really "authenticated" servers If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows Decision: rename "non-secure" to "authenticated" rename "secure" to "private and authenticated" (or something similar Discussion: WEBDAV has been asked to not allow basic authentication. 17. Provide input to the SVRLOC Printer Scheme I-D 18. Register all the SNMP printer languages as a (MIME) media types with cross references to the SNMP enums 19. Register "application/ipp" as a media type Keith said the preferred method for handling the MIME type registration is to put the registration text (as per RFC2048) into the standards track RFC that uses/defines it. IANA should then automatically add it to the registry within a few days of the publication of the RFC. New Issues: 20. Should we register new ports for IPP use Keith Moore: a reason for a separate port number is to allow firewalls to be configured to allow or block the printing port. But, Keith observes that firewall usage is typically to block all access except to particular servers and if HTTP is not allowed, then it is likely that printing would also not be allowed so this is not a big issue. Hence, Keith is neutral on registering a port for IPP. IESG has made TLS remove creation of new ports for other protocols than HTTP. Ones that are already deployed were kept, but no new ones. Therefore, we should not have a separate new port for IPP over TLS. Other than the port discussion, no new issues were raise Protocol Document Issues since August 1997, Bob Herriot 1. Attribute Group Tags Sender (of request or response) SHOULD send attribute group tag with no following attributes with the exception of the unsupported-attributes-tag which SHOULD be omitted. Recipient (of request or response) MUST accept as equivalent representations of an empty attribute group: - attribute group tag with no following attributes - expected but missing attribute tag 2. Identified a subset of the tag types (0-0xf) as being attribute group tags (some of which have not yet be assigned); these should be handled like attribute tags by any application/ipp recipient. The subset of tag types (0x10-oxff) are "value tags". 3. A recipient of a request or response MAY skip all attributes in an unknown group. 4. Printer-uri and job-uri MUST be on HTTP request line MUST also be in operation attributes 5. Job operations MUST be supported with both job-uri target printer-uri target with job-id attribute 6. Create-job operation returns job-uri and job-id 7. Handling of localized text and names Added two new data types: localized text localized name both of these are represented as an octet string with four fields: length of natural language identification natural language identification (per RFC length of text/name content of text/name 8. Request ID added to all requests and responses server returns received request-id in the response to the request that had the request-id client may match response with requests using the request-id; client is responsible for management of request id numbering space; in HTTP, the client can always use 0 as the request-id because HTTP guarantees responses in the order requests are made. 9. Renamed 'data-tag' to 'end-of-attributes' tag 10. Added new out-of-band values for no-value unknown 11. Definition of status codes and operations moved to model document No new issues were raised at the meeting Mapping between LPD to IPP, Bob Herriot, the document was updated as follows: 1. added statement that this is informational and its intent is to help implements of gateways between IPP and LPD 2. job-id now both job-id and job-uri are available allows job-id to be same as LPD job-id in relevant cases 3. job-originating-host was removed from IPP model; IPP-to-LPD must use some other means to supply the 'H'(host) parameter. 4. job-k-octets was clarified to count octets in one copy, not all copies; file size in lpq response does contain copies 5. Notification was removed from the IPP model; therefore support for LPD email notification is not possible 6. For document format, SNMP Printer MIB enums were replace by (MIME) media types 7. Authentication job-originating-user replaced by job-originating-user-name value is (explicitly) a human readable name value comes from underlying authentication mechanism and the attribute: requesting-user-name No other issues were raised Since all issues presented had a proposed solution that was acceptable to the meeting; final copies of the documents, containing the proposed resolutions, will be prepared and circulated to the mailing list by the end of the week. Assuming there are no significant comments received by Dec 18, the revised documents will be transmitted to the IESG for processing before the end of the year. IPP Summary Paragraph The standards track documents on the IPP Model and Semantics and the IPP Protocol Specification and the informational documents on IPP Requirements, IPP Rationale and Mapping between IPP and LPD were discussed. WG final calls for these had either expired or were about to expire. Proposed solutions to all known problems were reviewed (and, where necessary, corrected) during the WG meeting. Unless some new issue arises, it is the intent that final documents that include the proposed solutions will be given to the IESG for final processing before the end of the year. With this action, we consider the WG's charter to be fulfilled and do not expect to meet at the next IETF meeting.