IFX Mail Archive: IFX> Updated IPPFAX Protocol spec

IFX Mail Archive: IFX> Updated IPPFAX Protocol spec

IFX> Updated IPPFAX Protocol spec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri May 25 2001 - 04:59:40 EDT

  • Next message: Hastings, Tom N: "RE: IFX> IPP FAX telecon agenda, Wed, May 30, 10-12 PDT (1-3 EDT) [REMINDER for tommorrow]"

    I've edited the IPPFAX Protocol spec D0.3 version with editorial changes to
    make it more like our other IPP documents and PWG standards. The -rev
    versions have the revisions. In fixing the case and use of apostrophes, I
    didn't keep revision marks on, so that the document with revision marks is
    more readable than it would otherwise be. I've down loaded it at:

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

    There are 23 issues that I found, which I'd like to go over at the IPP FAX
    telecon, Wednesday, May 30, 10-12 noon PDT (see previous mail). The issues
    are embedded in the document and I've extracted them here, in hopes that
    some folks would like to discuss any and all of them on the mailing list
    before the telecon:

    ISSUE 01: Ok that I added the Validate-Job step, since Validate-Job is
    REQUIRED for an IPPFAX Receiver to support?

    ISSUE 02: Wouldn't "ippfax-version" (integer(0:MAX)) make a better Printer
    Description attribute name for the "ippfax-receiver (integer(0:MAX)),
    especially since we already have an "ippfax-receiver-identify (name(MAX))
    Printer Description attribute?

    ISSUE 03: Why not REQUIRE an IPPFAX Sender to validate that the Receiver is
    an IPPFAX Receiver? Otherwise, the Sending User isn't guaranteed reliable
    exchange.

    ISSUE 04: When the IPP Printer isn't an IPPFAX Printer (either doesn't
    support the "ippfax-receiver" attribute or returns a 0 value, why not
    REQUIRE the Sender to query the Sending User as to whether to abandon the
    exchange or do it in Degraded Mode? Currently, the Sender can do whatever
    it wants without the Sending User being involved.

    ISSUE 05: Can a Receiver support a remote administrator changing the value
    of the ippfax-receiver (integer(0:MAX)) Printer Description attribute using
    the Set-Printer-Attributes operation or should we define two OPTIONAL
    operations to set the level to 0 or back to its supported level?

    ISSUE 06: If we want two operations, should they be new operations or a new
    operation attribute for the existing OPTIONAL Disable-Printer and
    Enable-Printer operations?

    ISSUE 07: The UIF format is identified using the MIME type:
    'application/vnd.pwg-UIF' ( Or should we use 'image/tiff; application=uif'
    or 'image/tiff; application=faxbw or 'image/tiff; application=faxcolor'
    instead?).

    ISSUE 08: Ok to change the attribute syntax of the
    "ippfax-sending-user-identity" operation attribute from octetString32k(MAX)
    to text(MAX), since the value is a vCard string and 1023 characters seem
    plenty?

    ISSUE 09: Ok to change the attribute syntax of the
    "ippfax-receiving-user-identity" operation attribute from
    octetString32k(MAX) to text(MAX), since the value is a vCard string and 1023
    characters seem plenty?

    ISSUE 10: We need to define which Print-Job operation attributes and Job
    Template attributes are required for the Receiver to support.

    ISSUE 11: MUST the Sender inform the Sending User that the Document as been
    received successfully?

    ISSUE 12: Why not REQUIRE the Sender to support Get-Notifications and
    subscribing to at least the 'job-complete' event?

    ISSUE 13: Ok to allow a Receiver to support a subset ('job-progress' and
    'job-complete') of the REQUIRED events that IPP Notification requires?

    ISSUE 14: Ok to allow a Receiver to subset the REQUIRED operations of the
    IPP Notification specification and not support: Create-Job-Subscriptions,
    Create-Printer-Subscriptions, Get-Subscription-Attributes,
    Get-Subscription-Attributes, Renew-Subscription, or Cancel-Subscription,
    even though the IPP Notification spec requires them?

    ISSUE 15: Should we forbid a Receiver to support the additional IPP
    Notification operations: Create-Job-Subscriptions,
    Create-Printer-Subscriptions, Get-Subscription-Attributes,
    Get-Subscription-Attributes, Renew-Subscription, or Cancel-Subscription?

    ISSUE 16: Why are we requiring that the Sender put the identity at top of
    every page? Isn't that more stringent than PSTN FAX and Internet FAX? I
    thought that a Sender could do that, but that putting it on the first page
    was sufficient?

    ISSUE 17: Why do we have this ippfax-return-uri which is the URI of the
    Receiver? Any IPP client MUST always put this same URI into the
    "printer-uri" (uri) operation attribute of the Print-Job operation which the
    IPP/1.1 Printer MUST copy to the "job-printer-uri" Job Description
    attribute. So I suggest we delete the "ippfax-return-uri" (uri) operation
    and Job Description attribute.

    ISSUE 18: MUST a Receiver support this restricted form of the Cancel-Job
    operation or MAY it omit support all together?

    ISSUE 19: MUST a Receiver support this restricted form of the
    Get-Job-Attributes operation or MAY it omit support all together?

    ISSUE 20: MUST a Receiver support this restricted form of the Get-Jobs
    operation or MAY it omit support all together?

    ISSUE 21: Which IPP/1.1 status code to use when the IPP Printer is
    configured to only accept IPPFAX operations and reject other IPP operations:
    client-error-forbidden (0x0401) or client-error-not-authorized (0x0403)?
    Here are their IPP/1.1 descriptions;
    13.1.4.2 client-error-forbidden (0x0401)
    The IPP object understood the request, but is refusing to fulfill it.
    Additional authentication information or authorization credentials will not
    help and the request SHOULD NOT be repeated. This status code is commonly
    used when the IPP object does not wish to reveal exactly why the request has
    been refused or when no other response is applicable.
    13.1.4.4 client-error-not-authorized (0x0403)
    The requester is not authorized to perform the request. Additional
    authentication information or authorization credentials will not help and
    the request SHOULD NOT be repeated. This status code is used when the IPP
    object wishes to reveal that the authentication information is
    understandable, however, the requester is explicitly not authorized to
    perform the request. This status codes reveals more information than
    "client-error-forbidden" and "client-error-not-authenticated".

    ISSUE 22: Why not use the existing IPP/1.1 status code:
    client-error-not-authenticated (0x0402) for when the client doesn't include
    a certificate? Here is the complete IPP/1.1 description:
    13.1.4.3 client-error-not-authenticated (0x0402)
    The request requires user authentication. The IPP client may repeat the
    request with suitable authentication information. If the request already
    included authentication information, then this status code indicates that
    authorization has been refused for those credentials. If this response
    contains the same challenge as the prior response, and the user agent has
    already attempted authentication at least once, then the response message
    may contain relevant diagnostic information. This status codes reveals more
    information than "client-error-forbidden".

    ISSUE 23: Do the conformance tables look ok?

    Thanks,
    Tom

    -----Original Message-----
    From: gsonger@netreon.com [mailto:gsonger@netreon.com]
    Sent: Tuesday, May 01, 2001 14:08
    To: ifx@pwg.org
    Subject: IFX> ifx spec

    Hi!

    At the last meeting we had so much fun with the UIF spec that we didn't get
    to
    the IFX spec.

    In an effort to stay on schedule, I would like to solicit comments on the
    DL,
    rather than wait till Toronto.

    Comments on the IFX spec? (Tom, I know you have at least one :)

    Gail



    This archive was generated by hypermail 2b29 : Fri May 25 2001 - 05:00:23 EDT