IPP Mail Archive: IPP> IPP WG Notes - IETF 53

IPP Mail Archive: IPP> IPP WG Notes - IETF 53

IPP> IPP WG Notes - IETF 53

From: Carl (carl@manros.com)
Date: Wed Apr 10 2002 - 22:41:19 EDT

  • Next message: Michael Sweet: "IPP> Re: Mandatory Delivery Method for Notifications - Comments by Ap ril 15]"


    Below are the minutes from the IPP meeting in Minneapolis, taken by Lee



    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
    * 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)
    * IPP Fax/1.0 Protocol

    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

    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
    * 5100-2 IPP - "output-bin" attribute extension
    * 5100-3 IPP - Production Printing Attributes - Set 1
    * 5100-4 IPP - Override Attributes for Documents and Pages
    * 5101-1 Standard for Media Standardized Names

    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

    Meeting adjourned.

    This archive was generated by hypermail 2b29 : Wed Apr 10 2002 - 22:42:19 EDT