IFX Mail Archive: RE: IFX> some UIF issues...thoughts anyone

IFX Mail Archive: RE: IFX> some UIF issues...thoughts anyone

RE: IFX> some UIF issues...thoughts anyone? [terminology: Client vs. Sender and Host vs. Receiver]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jun 20 2001 - 13:58:11 EDT

  • Next message: John Pulera: "IFX> UIF spec has been updated: 'uif-spec-05'"

    I like Bill's definitions for both UIF and IFX specs and the fact that it is
    used in the FAX specs will help understandability by that audience as well.
    I think the definitions also cover Ira's concerns that the Sender might not
    send a job, after querying the Receiver because the definitions say "capable
    of".
     
    Minor tweaks
     
    Capitalize the terms in both specs.
    For the UIF spec, we should refer only to UIF, not IPP FAX, as so have :
     
    Receiver: User agent capable of receiving a UIF document transmission.

    BM__msocom_3Sender: User agent capable of sending a UIF document
    transmission.

    BM__msocom_5Device: Terminal containing a Receiver and/or a Sender.

     

    OK?

    Tom

    -----Original Message-----
    From: Wagner,William [mailto:wwagner@netsilicon.com]
    Sent: Tuesday, June 19, 2001 07:47
    To: 'IPP-Fax Group'
    Subject: RE: IFX> some UIF issues...thoughts anyone? [terminology: Client
    vs. Sender and Host vs. Receiver]

    Relative to names...
     
    These names are not for end user consumption so the main requirement is that
    name components be clearly defined and consistently used. Selecting
    intuitively meaningful names is nice, but not always possible. In IPP, for
    example, "printer" is used for attributes of a "logical" printer, which may
    be a device that never receives a piece of paper. Indeed, anticipating the
    use of the IPP protocol for functions other than printing, it may have been
    nicer to use more general terms.
     
    There appears to be an intent to give IPP-FAX some compatibility with I-FAX,
    presumably meaning T.37 and its variations. The following definition is
    from that document.

    T: 4.1.1 receiver: User agent capable of receiving or retrieving
    Email.

    BM__msocom_3T: 4.1.2 sender: User agent capable of sending Email.

    BM__msocom_5T: 4.1.3 device: Terminal containing a receiver and/or a
    sender.

    One may argue the adequacy and applicability of these definitions to
    IPP-FAX, but I suggest that "receiver" and "sender" are more consistent
    with existing usage by "FAX people". Acknowledging Ira's observation, the
    definitions may be"

    receiver: User agent capable of receiving an IPP-FAX document transmission.

    BM__msocom_3sender: User agent capable of sending an IPP-FAX document
    transmission.

    BM__msocom_5device: Terminal containing a receiver and/or a sender.

    William A. Wagner (Bill Wagner)

    Director of Technology
    Imaging Division
    NETsilicon, Inc.
    781-398-4588

    -----Original Message-----
    From: McDonald, Ira [mailto:IMcDonald@crt.xerox.com]
    Sent: Monday, June 18, 2001 7:27 PM
    To: Hastings, Tom N; 'jpulera@minolta-mil.com'
    Cc: 'IPP-Fax Group'
    Subject: RE: IFX> some UIF issues...thoughts anyone? [terminology: Client
    vs. Sender and Host vs. Receiver]

    Hi Tom,
     
    I vastly prefer 'printer-uif-capabilities'. I don't like unscoped Printer
    object attributes
    like 'uif-capabilities'.
     
    Cheers,
    - Ira
     
    PS - What I don't like about Sender and Receiver (I finally realized) is
    that in protocol specs
    they refer to messages - but here in IPP Fax you mean JOB Sender and JOB
    Receiver.

    -----Original Message-----
    From: Hastings, Tom N
    Sent: Monday, June 18, 2001 6:02 PM
    To: Hastings, Tom N; jpulera@minolta-mil.com; McDonald, Ira
    Cc: IPP-Fax Group
    Subject: RE: IFX> some UIF issues...thoughts anyone? [terminology: Client
    vs. Sender and Host vs. Receiver]

    An additional attribute name affected by whether we continue to use the term
    IPPFAX Receiver or change it to IPPFAX Printer, is the "uif-conneg"
    (octetString32k) Printer Description attribute that we agreed on the May 30
    telecon to rename to: "uif-receiver-capabilities" (octetString32k).
     
    If we decide to change the terminology from IPPFAX Receiver to IPPFAX
    Printer, we should change this Printer Description attribute name (again) to
    one of:
     
    "uif-printer-capabilities", or "printer-uif-capabilities", or just
    "uif-capabilities".
     
    Comments?
     
    Tom
     

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, June 18, 2001 14:27
    To: jpulera@minolta-mil.com; Ira at Xerox XR&T McDonald (E-mail)
    Cc: IPP-Fax Group
    Subject: RE: IFX> some UIF issues...thoughts anyone? [terminology: Client
    vs. Sender and Host vs. Receiver]

    Ira is suggesting IPPFAX Server, instead of IPPFAX Receiver or IPPFAX
    Printer. (We're all in agreement *not* to use "host").
     
    However, to me a Server can act as a Sender or a Receiver, so I like the
    terms Sender and Receiver, because they are more clearly *roles* that hosts
    and servers can play. The conformance requirements of Sender vs. Receiver
    apply to the role.
     
    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, June 18, 2001 13:56
    To: jpulera@minolta-mil.com
    Cc: IPP-Fax Group
    Subject: RE: IFX> some UIF issues...thoughts anyone? [terminology: Client
    vs. Sender and Host vs. Receiver]

    On the second issue, I believe the original issue from the minutes was
    whether to use the IPP/1.1 terminology for IPPFAX Sender and IPPFAX
    Receiver, which would be IPPFAX Client and IPPFAX Printer, not IPPFAX Host.
    To me the term Host is much too vague. To me a Host could be a sender or a
    receiver.
     
    So I'm quite opposed to using the term "Host". Whether to continue using
    the IPPFAX terms Sender and Receiver or go back to the IPP/1.1 terms of
    Client and Printer is harder to decide. If we go back to the IPP Client and
    Printer terms we would make it clear that the term Printer means the
    software entity that accepts requests and returns responses, as in IPP, and
    need not actually have any hardware associated at all. The advantage of the
    term Receiver, is that no hardware is suggested by the name.
     
    However, the problem with using the term "receiver" is that it affects the
    names of some of the attributes ("receiver" vs. "printer"). Also we are
    stuck with the IPP/1.1 terminology of Printer Description attributes and the
    'printer-description' attribute group name used as a keyword in the
    Get-Printer-Attributes request.
     
    The attribute names affected are:
     
    5.1 <outbind://6/#_Toc515389244> ippfax-sending-user-identity
    (text(MAX)) operation/Job Description attribute 9

    5.2 <outbind://6/#_Toc515389245> ippfax-receiving-user-identity
    (text(MAX)) operation/Job Description attribute 9

    5.3 <outbind://6/#_Toc515389246> ippfax-sender-identity
    (name(255)) operation/Job Description attribute 10

    5.4 <outbind://6/#_Toc515389247> ippfax-receiver-identity
    (name(255)) Printer Description attribute 10

     

    We should still keep the terms Sending User and Receiving User, but we could
    change the terms Sender to Client and Receiver to Printer.

    Then the attributes would be named:

     

    5.1 <outbind://6/#_Toc515389244> ippfax-sending-user-identity
    (text(MAX)) operation/Job Description attribute 9

    5.2 <outbind://6/#_Toc515389245> ippfax-receiving-user-identity
    (text(MAX)) operation/Job Description attribute 9

    5.3 <outbind://6/#_Toc515389246> ippfax-client-identity
    (name(255)) operation/Job Description attribute 10

    5.4 <outbind://6/#_Toc515389247> ippfax-printer-identity
    (name(255)) Printer Description attribute 10

     

    Comments?

    Tom

    -----Original Message-----
    From: John Pulera [mailto:jpulera@minolta-mil.com]
    Sent: Thursday, June 07, 2001 09:45
    To: IPP-Fax Group
    Subject: IFX> some UIF issues...thoughts anyone?

    While revising the UIF spec, some issues have surfaced and it would be great
    if we can generate some discussion on them:
     
    1) The MIME type for UIF data.
            From the IPPFAX teleconferences held on May 30 & June 6, there was
    consensus to use "image/tiff; application=faxbw" and "image/tiff;
    application=faxcolor". The primary argument for using these was that it is
    the same MIME type used for Internet Fax, and so there would be less of a
    conformance issue with an IPPFAX device serving as a gateway for Internet
    Fax documents.
            However...If we are going to make UIF a protocol-independent data
    format (which was also agreed at the May 30 telecon), I do not think think
    we should directly associate it with Internet Fax. Perhaps "image/tiff;
    application=uif" would be a better compromise in that UIF would be made
    independent of Internet Fax while existing TIFF readers can still do
    something with the UIF data.
            In addition, is it valid to use the same MIME type as Internet Fax
    if the data requirements for UIF and TIFF-FX are not identical? (TIFF-FX is
    more strict with resolutions and allowed image widths)
     
    2) The use of the terms "Client" to mean the "Sender" and "Host" to mean the
    "Receiver".
        Is "Client" interchangeable with "Sender" and "Host" with "Receiver"?
    Should we be using the more generic terms "Client" and "Host" instead of
    "Sender" and "Receiver" in the UIF spec since the UIF spec is NOT
    protocol-specific?
     
    Does anyone have any thoughts on these issues?
     
    Thanks,
     
    John



    This archive was generated by hypermail 2b29 : Wed Jun 20 2001 - 13:58:27 EDT