IFX Mail Archive: IFX> Minutes of the 6/6/01 telecon on IPP

IFX> Minutes of the 6/6/01 telecon on IPP FAX IFX document

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jun 06 2001 - 22:11:01 EDT

  • Next message: John Pulera: "IFX> some UIF issues...thoughts anyone?"

    Attendees: Gail Songer, Peter Zehler, Ira McDonald, John Pulera, Tom
    Hastings
    Regrets: Bill Wagner, Harry Lewis

    On the telecon today we reviewed the Draft D0.4, May 24, 2001 "IPP FAX
    Protocol" document:

    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

    Tom Hastings will update the IFX document with these agreements and the ones
    from last weeks telecon. John Pulera will update the UIF document with the
    agreements from last week. John and Tom will proof read each others work
    with Ira's help. Then publish the updated documents for a telecon the end
    of June.

    The agreements are preceded by TH>:

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

    TH> Yes

    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?

    TH> Rename to "ippfax-versions-supported" (1setOf type2 keyword). Structure
    the keyword as with IPP version, namely major.minor, and append either
    'unauthorized' or 'authorized'. The former corresponds to what we agreed to
    as 'uif-only' last week. Also have a 'none' value which means that the
    Printer behaves as a normal IPP Printer. So the standard keyword values
    are:

       '1.0.unauthorized' - UIF only
       '1.0.authorized' - includes authorization
       'none' - normal IPP behavior

    Also define a "ippfax-version" operation attribute to Get-Printer-Attributes
    with the same values which "colors" the responses to such attributes as
    "copies-supported", "document-formats-supported", etc.

    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.

    TH> Agreed.

    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.

    TH> Agreed (for the renamed "ippfax-versions-supported")

    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?

    TH> Yes, a Receiver MAY support a remote administrator using
    Set-Printer-Attributes to change the (current) versions supported to get
    different behavior, such as making the Receiver be an IPPFAX only printer
    and not a regular IPP Printer. Don't define new operations. Enable-Printer
    and Disable-Printer affect IPPFAX jobs as well.

    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?

    TH> Moot.

    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?).

    TH> We agreed same as last week to use the 'image/tiff; application=faxbw or
    'image/tiff; application=faxcolor' MIME media types.

    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?

    TH> Raise on the mailing list to use '1setOf text(MAX)'. Each value
    represents a text token with white space between values. Need to read VCARD
    spec to see what separates "lines".

    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?

    TH> Raise on the mailing list to use '1setOf text(MAX)'. Each CONNEG value
    represents a text token with white space between values. This aligns with
    CONNEG semantics.

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

    TH> All the operation attributes that IPP/1.1 requires are required for IPP
    FAX.

    The "media" and "resolution" Job Template attributes are required for IPP
    FAX. If the "resolution" differs from that in the TIFF/FX data, then the
    TIFF/FX data wins. The "resolution-supported" Printer attribute MUST
    indicate the resolutions supported in any profile AND profile S MUST support
    all of them (other profiles NEED NOT).

    The "copies-supported" attribute, if supported, MUST only support the value
    1 for:
       '1.0.unauthorized' - UIF only
       '1.0.authorized' - includes authorization

    Any other Job Template attribute MAY be supported by an IPPFAX Receiver.

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

    TH> yes.

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

    TH> Agreed, but MUST support all of the IPP Notification REQUIRED events,
    which are:
    'none', 'printer-state-change', 'printer-stopped', 'job-state-change',
    'job-created', and 'job-completed'.

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

    TH> Disagreed; MUST support all of the IPP Notification REQUIRED events,
    which are:
    'none', 'printer-state-change', 'printer-stopped', 'job-state-change',
    'job-created', and 'job-completed'.

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

    TH> Agreed.

    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?

    TH> No.

    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?

    TH> Because its required for PSTN FAX. So delete this issue.

    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.

    TH> Agreed. Delete "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?

    TH> It MUST either support the restricted form (administrators only) or NOT
    support Cancel-Job on IPPFAX jobs at all.

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

    TH> The attributes that Get-Job-Attributes returns should be policy, not
    part of the protocol spec, so delete and mention that which attributes are
    returned depends on policy and implementation.

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

    TH> Same.

    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".

    TH> Use client-error-not-authorized (0x0403) instead.

    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".

    TH> Agreed to use client-error-not-authorized (0x0403) instead of adding a
    new status code which divides the cases.

    ISSUE 23: Do the conformance tables look ok?

    TH> Leave as an issue for broader review.

    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 : Wed Jun 06 2001 - 22:11:21 EDT