IFX Mail Archive: IFX> IFX spec down-loaded for IPP FAX tele

IFX Mail Archive: IFX> IFX spec down-loaded for IPP FAX tele

IFX> IFX spec down-loaded for IPP FAX telecon agenda, Wed, June 27, 10 -12 PDT (1-3 EDT)

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jun 22 2001 - 22:53:08 EDT

  • Next message: Hastings, Tom N: "IFX> More IFX ISSUES around image/tiff application parameter value"

    I've finally down-loaded the IFX spec to the URLs advertised in the agenda
    for next Wednesday's telecon. Ira, John, Gail, and I have discussed/raised
    some issues. It has 20 issues embedded in it which I have also extracted
    into this mail message. Most of these issues are new. So the IFX document
    isn't quite ready for PWG Last Call.

    Please send any comments on these issues or other issues to the DL before
    the telecon.

    John down-loaded the UIF spec last Wednesday. It is nearly ready for PWG
    Last Call.

    Tom

    The 20 ISSUES in the IFX Protocol document:

    ISSUE 01: Are all the attribute names ok? Check the TOC to see all the
    names together.

    ISSUE 02: Should we add all of the Job Template attributes which MUST be
    subsetted for IPP FAX?

    ISSUE 03: OK that the Sender needs to make two Get-Printer-Attributes
    requests in order to determine both the IPP and IPPFAX document formats
    supported?

    ISSUE 04: OK to add UIF Profile T (JBIG2) which is only an I-D?

    ISSUE 05: Should we change the attribute syntax of the
    "printer-uif-profile-capabilities" (octetString32k) Printer Description
    attribute to be multi-valued text, i.e., 1setOf text(MAX)? At the last IPP
    FAX telecon on May 30, this issue was re-raised. From reading the CONNEG
    RFCs, the same *white space* rules are used between tokens as for email.
    Thus, we could represent CONNEG strings as 1setOf text, where each text
    value contains one or more CONNEG tokens. When combining a 1setOf text into
    a CONNEG string, the parser would insert some *white space" between each
    value.

    Note: each token doesn't have to be a separate text value (though it can
    be).
    Alternatively, we could just simply chunk the CONNEG value at arbitrary
    places between each text value.

    The advantage of using existing IPP data types, instead of inventing a new
    data type, is that existing gateways can be used. Remember that a number of
    initial IPP implementations were just gateways to existing printing systems.

    ISSUE 06: The use of "identity" meaning vCard in the
    "ippfax-sending-user-identity" attribute name is quite different from its
    use in Kerberos and other network single login technologies. Should we
    change the name to something like "ippfax-sending-user-vcard"?

    ISSUE 07: 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? Then this attribute would get through IPP/1.1 Gateways.

    ISSUE 08: Or should we make the attribute syntax of the
    "ippfax-sending-user-identity" operation attribute be multi-valued, i.e.,
    1setOf text(MAX)? Then this attribute would get through IPP/1.1 Gateways
    and not be limited to length.

    ISSUE 09: The use of "identity" meaning vCard in the
    "ippfax-receiving-user-identity" attribute name is quite different from its
    use in Kerberos and other network single login technologies. Should we
    change the name to something like "ippfax-receiving-user-vcard"?

    ISSUE 10: 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? Then this attribute would get through IPP/1.1
    Gateways.

    ISSUE 11: Or should we make the attribute syntax of the
    "ippfax-receiving-user-identity" operation attribute be multi-valued, i.e.,
    1setOf text(MAX)? Then this attribute would get through IPP/1.1 Gateways
    and not be limited to length.

    ISSUE 12: Is 'client-error-forbidden' status code the proper status code to
    return for an IPP Job submitted to a Receiver that is configured only to
    accept IPPFAX Jobs, i.e., the value of the Receiver's
    "ippfax-jobs-supported" contains only the 'ippfax-authenticated' value?

    ISSUE 13: SHOULD be using a client URL by preference and NOT a MAC address
    (generally totally unknown to an IPP client application). In any case the
    IEEE and IETF don't approve the use of MAC address for identifiers anymore
    except in EUI-64 format (an IEEE standard), which is the basis for canonical
    IPv6 self-configured global addresses. Ira will look up the RFC references
    later, if you want EUI-64

    ISSUE 14: The ippfax-receiver-identity (name(MAX)) Printer Description
    attribute is bad design. The "printer-uri-supported" is EXACTLY what
    "ippfax-receiver-identity" is supposed to be without all this unsuitable
    discussion about MAC addresses. So can we get rid of the
    ippfax-receiver-identity (name(MAX)) Printer Description attribute and
    REQUIRE the Sender to query the "printer-uri-supported" Printer Description
    attribute instead?

    ISSUE 15: OK that we are using the 'ipp:' scheme for both IPP and IPPFAX
    protocols?

    ISSUE 16: OK that we are forced to use the same default port for IPPFAX as
    for IPP? So if a Receiver is configured to only receive IPPFAX Jobs from
    outside its firewall, but receive IPP Jobs from inside its firewall, one or
    the other will be forced to supply an explicit (different) port?

    ISSUE 17: Is this the last use of the new octetString32k attribute syntax?
    Can we change it to an existing data type or 1setOf octetString(MAX), i.e.,
    chunk the data, so that it can be passed through existing IPP Gateways?

    ISSUE 18: Can we get rid of the new 'octetString32k' attribute syntax and
    use existing IPP/1.1 attribute syntaxes, so that existing IPP systems can be
    used as gateways?

    ISSUE 19: Do the conformance tables look ok?

    ISSUE 20: Is this vCard example accurate? The phone number format seem
    wrong.

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, June 21, 2001 11:19
    To: IPP FAX DL (E-mail)
    Cc: McIntyre, Lloyd; Buckley, Robert R
    Subject: IFX> IPP FAX telecon agenda, Wed, June 27, 10-12 PDT (1-3 EDT)

    The IPP FAX telecon that we scheduled at the May 30 telecon is coming up in
    a week. We think that the two IPP FAX document are pretty close to being
    finished. If you haven't read them recently, this would be a good time. We
    are ready for PWG Last Call on them. We will decide at next week's telecon,
    whether to start PWG Last Call (ending after the August 1 Toronto meeting)
    or wait for the Toronto meeting to decide to start the PWG Last Call.

    John has posted and announced the UIF spec yesterday and I'll post and
    announce the IFX spec later today or tomorrow at the URLs indicated below.

    Here is the dial-in information:

    Time: Wednesday, June 27, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST)
    Phone: 1-712-271-0568 (8*534-6413 for Xerox folks)
    Passcode: 52863#

    The agenda is:

    1. Review John Pulera's updated UIF spec with changes highlighted:
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05-edit.doc>
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05-edit.pdf>
    clean:
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05.doc>
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05.pdf>

    2. Review the updated IFX spec (its, not there yet, so I'll post in a day or
    so and announce).

    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05-rev.doc>
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05-rev.pdf>
    clean:
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05.doc>
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05.pdf>

    3. Are the documents ready to start PWG Last Call?

    Should we start PWG Last Call on the documents (ending at the end of the
    Toronto August 1 meeting) or wait for the Toronto meeting to decide to start
    the PWG Last Call?

    4. Next meeting and/or telecon

    Unless we can't finish reviewing the two documents in the two hours, no
    further telecons before the PWG meeting are planned. The next face-to-face
    IPP FAX WG meeting will be in Toronto, Wednesday, August 1, after the PWG
    plenary.

    Thanks,
    Tom

    P.S. If you want to refresh your memory on what we agreed to at the two
    previous telecons (May 30 and June 6) see the mail messages on 6/1/01 and
    6/6/01, respectively.

    If you want to refresh your memory on what we agreed on in Portland,
    April 25, the IPP FAX minutes are available at:

    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0104-minutes.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0104-minutes.doc



    This archive was generated by hypermail 2b29 : Fri Jun 22 2001 - 22:53:33 EDT