IPP WG - IETF 53 Carl-Uno Manros led the Internet Printing Protocol (IPP) WG session. Only 5 people attended. He gave the agenda items: * Agenda bashing * Go over the status of outstanding drafts that are in queue for RFC publication * Discuss issues on IPP Notifications, raised by the IESG * Report from the Printer Working Group on the status of IPP FAX * Discuss and decide if we can now close the IPP WG 1. Status of IPP Drafts Progress during the last 12 months: * 2 Informational RFCs published * 3 Standards Track Drafts in the RFC Editor's Queue * 3 Standards Track Drafts under IESG discussion * 1 Informational Draft under IESG discussion ==> However: 4 Standards Track Drafts are still under AD Review Carl-Uno presented a chart showing the current state of each of the IPP WG draft documents along the process of becoming an RFC. Ned Freed said that he believes some of the IESG comments on the IPP URL Scheme document have not been completely addressed in the last update. He will forward the latest comments to Carl-Uno. 2. Discuss Issues on IPP Notifications, Raised by the IESG Ned has suggested that the entire set of documents relating to Notifications should be forwarded as a complete unit for combined review by the IESG. According to Ned, the SASL stuff in the "mailto:" document could use some improvements. He believes the modifications are relatively minor. Other than that, he thinks "we're almost done." 3. IPP Fax Carl-Uno then gave some information on the IPP Fax activity that is taking place in the Printer Working Group (PWG.) He explained that the PWG group has been working on two specifications for the past two years, and they are now close to publication: * Universal Image Format (UIF) ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-10.pdf * IPP Fax/1.0 Protocol ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-10.pdf He provided an overview of the UIF specification: UIF is a raster image data format intended for use by, but not limited to, the IPPFAX protocol, which is used to provide a synchronous, reliable exchange of image Documents between Senders and Receivers. UIF makes reference to the TIFF-FX specification [RFC2301], which describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. UIF also requires the use of certain TIFF-FX extensions described in this document. UIF does not specify any new TIFF tags or field values. UIF uses the existing MIME types for image/tiff and image/tiff-fx. And he highlighted the UIF-related Extensions to TIFF-FX: * TIFF-FX Extention 20: Relaxed Image Width and Resolutions: * ImageWidth, XResolution, and YResolution TIFF fields are not constrained to the set of resolutions specified in [RFC2301]; however, the Receiver MUST support the image width & length that are determined by the media size and resolutions supported. * TIFF-FX Extensions 21-24, Required Resolutions * XResolution=YResolution=200 and ResolutionUnit=2 (inches) * XResolution=YResolution=300 and ResolutionUnit=2 (inches) * XResolution=YResolution=400 and ResolutionUnit=2 (inches) * XResolution=YResolution=600 and ResolutionUnit=2 (inches) * TIFF-FX Extension 25, Required Field: If TIFF-FX Extension 25 is supported, then Receivers MUST support the use the JPEGTables Extension Field * TIFF-FX Extension 26, Required Compression: If TIFF-FX Extension 26 is supported, Receivers MUST support Resolution=4 (2-dimensional MMR encoding as defined in [T.6]) and T6Options=0. * UIF suggests how to use CONNEG for negotiation of capabilities. It defines a number of CONNEG auxiliary predicate values for use with UIF (to be registered with IANA): * profile-tiff-fx-s * profile-uif-f * profile-uif-j * profile-uif-cg * profile-uif-c * profile-uif-lg * profile-uif-l * profile-uif-m' He summarized the IPP Fax /1.0 specification: IPPFAX is used to provide a synchronous, reliable exchange of image Documents between clients and servers. The primary use envisaged of this protocol is to provide a synchronous image transmission service for the Internet. The IPPFAX/1.0 protocol is a specialization of the IPP/1.1 protocol supporting a subset of the IPP operations with increased conformance requirements in some cases, some restrictions in other cases, and some additional REQUIRED attributes. The IPPFAX Protocol uses the 'ippfax' URL scheme in all its operations. A separate port number for IPPFAX will be registered with IANA. IPPFAX/1.0 REQUIRES the support of the IPP Event Notification mechanism [ipp-ntfy] using the 'ippget' Pull Delivery Method [ipp-get-method]. An IPPFAX Printer object MUST support at least the UIF S Profile as specified in UIF, which is defined for the 'image/tiff' MIME type, and MAY support additional UIF Profiles for the 'image/tiff' and 'image/tiff-fx' MIME types. Carl-Uno then described the typical sequence of operations involved in the IPP Fax/1.0 protocol: * Get-Printer-Attributes * Validate-Job * Print-Job * Get-Notifications He listed the additional attributes of IPP Fax: * ippfax-version-number * ippfax-versions-supported * uif-profile-requested * uif-profiles-supported * uif-profile-capabilities 4. Other Printing-Related Documents Carl-Uno referenced a few of the other printing-related documents published by the PWG: * 5100-1 IPP - "finishings" attribute values extension ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.1.pdf * 5100-2 IPP - "output-bin" attribute extension ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.2.pdf * 5100-3 IPP - Production Printing Attributes - Set 1 ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf * 5100-4 IPP - Override Attributes for Documents and Pages ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.4.pdf * 5101-1 Standard for Media Standardized Names ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf 5. Market Progress Carl-Uno says he is very unhappy about Microsoft's support of IPP. However, he is pleased to say that there is a CUPS Linux implementation that is very good. It is expected that this will also be included in the next Apple OS. 6. Should We Close the IPP WG? Ned says that all the Internet-Drafts must all be published before a WG can be closed. He noted that there are a lot of documents-and they aren't small. It will still take time to go through the remaining steps prior to becoming RFCs, but he hopes that they will all be in the RFC queue by the next IETF Plenary in July. Ned thinks that another IPP face-to-face meeting will [probably] not be necessary. Meeting adjourned.