All,
Below are the minutes from the IPP meeting in Minneapolis, taken by Lee
Farrell
Carl-Uno
============================================================================
====
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.
This archive was generated by hypermail 2b29 : Wed Apr 10 2002 - 22:42:19 EDT