IFX Mail Archive: IFX> Version 0.11 of IPPFAX protocol avail

IFX Mail Archive: IFX> Version 0.11 of IPPFAX protocol avail

IFX> Version 0.11 of IPPFAX protocol available

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Oct 11 2002 - 19:16:22 EDT

  • Next message: Rick Seeler: "IFX> The first version of the 'PDFax' Standard is now available for review."

    The next draft of the IPPFAX protocol is available at:

    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-11.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-11.doc
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-11-rev.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-11-rev.doc

    The -rev versions show the changes from the .10 version (which was with
    tiff).

    This version is a start on changing from using UIF (tiff and tiff-fx) to
    PDFax. I've used the new PDFax Profile letters and MIME type. However, I
    haven't changed or deleted any of the CONNEG stuff. There are four issues
    listed in the front and copied here which Rick Seeler, John Pulera, Gail
    Songer, Lloyd McIntyre, Rob Buckley and I agree should be in the IPPFAX
    protocol specification, not the PDFax specification. The PDFax
    specification is a subset of PDF suitable for streaming.

    Rick Seeler will post the first version of the PDFax specification shortly.
    Both specifications will be on the agenda at the PWG New Orleans IPP FAX WG
    meeting, November 8.

    I will not be able to attend the IPP FAX WG meeting. Also I've run out of
    time to complete the changes to the spec. I'm still very supportive of
    getting IPPFAX finished. Gail said she might have some time to do some more
    work on it. I hope so, because IPPFAX seems to be a very good application
    of IPP.

    Here are the 4 issues:

    ISSUE 01: Need to add IPPFAX Printer Description attributes for Amount of
    Receiver memory for JBIG2; REQUIRE Sender to query Receiver if going to
    exceed the maximum specified in [pdfax], say around 2M.

    ISSUE 02: Add: Senders MUST NOT use OPTIONAL features, unless they have
    queried the Receiver using Get-Printer-Attributes and verified that the
    Receiver supports the OPTIONAL feature. Need to add Printer Description
    attributes to describe these OPTIONAL features.

    ISSUE 03: Add: Receivers MUST NOT support any OPTIONAL features, unless the
    protocol has a way to indicate that support to the Sender.

    ISSUE 04: Clarify that support of the 'pdfax-c' requires color, while the
    'pdfax-cg' is just gray scale. Same for 'pdfax-d'. What about 'pdfax-m? A
    Sender MUST NOT send a color document to a 'pdfax-cg' Receiver, unless the
    Sending User has been explicitly notified.

    Please send comments to the mailing list.

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Fri Oct 11 2002 - 19:16:37 EDT