IFX Mail Archive: RE: IFX> Brief minutes of UIF review, Wed,

IFX Mail Archive: RE: IFX> Brief minutes of UIF review, Wed,

RE: IFX> Brief minutes of UIF review, Wed, 6/27/01

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Jul 02 2001 - 19:06:06 EDT

  • Next message: l9900TYtv@mail.com: "(no subject)"

    John,

    I missed one further agreement related to the following discussion:

    4) Why do profiles C, F and J (optionally) allow centimeter resolution
    units, but profiles L and M only allow "inch" resolution units? TIFF-FX
    again? Again I ask, how would this specification change if the United
    States FINALLY went metric? Is there a reason to prohibit cross-unit
    compatibility like, for example, the computational cost of a good
    sub-sampling algorithm?

    <ira>
    There are some typos on your list above. The b&w TIFF-FX profiles allowed
    centimeters or inches. The color TIFF-FX profiles used inches because
    that's what the engine builders did at the time the TIFF-FX profiles
    were specified. For interoperability, UIF will NOT relax this
    restriction - gateways to Internet Fax and ITU GSTN fax are high
    priority.

    TH> We probably need to add some kind of a note about this in UIF.
    <--->

    We agreed that color resolution MUST be square, i.e., the resolution in the
    X direction MUST be the same as in the Y direction.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, July 02, 2001 15:15
    To: IPP FAX DL (E-mail)
    Subject: IFX> Brief minutes of UIF review, Wed, 6/27/01

    Attendees:

    Tom Hastings, Xerox Corp.
    Marty Joel, Netreon
    Ira McDonald, High North Inc.
    Lloyd McIntyre, Xerox Corp
    John Pulera, Minolta Labs
    Gail Songer, Netreon
    Bill Wagner, NetSilicon

    Agreements:

    1. Section 3.2, MIME Content Type application parameter, REQUIREMENTS for
    Senders:

    a. We reaffirmed using the existing image/tiff; application= parameter for
    MIME content types, but agreed to change the values to reflect the profile
    that the document is actually using.

    b. Furthermore, we agreed that the M (MRC) profile is really only a
    structure for one or more other profiles, so that for the M profile, the
    other profiles being used MUST be indicated as well. So the Sender MUST
    include the other profiles in alphabetic order that are being used with the
    M profile.

    c. Instead of enumerating all possible or all recommended combinations with
    M, we will just give the ABNF and indicate that any combination of M and
    other profiles are possible. The ABNF for the UIF application= parameter
    value is:

       "uif-" (lowalpha | "m" +lowalpha)
       lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
                  "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
                  "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

    Examples MIME Content Types:
       image/tiff; application=uif-s
       image/tiff; application=uif-ms
       image/tiff; application=uif-mcs
       image/tiff; application=uif-mcls

    d. We would indicate via a Note that a profile T was work in progress and
    could be used with UIF as soon as the RFC for the TIFF/FX T profile is
    published AND the IPPFAX WG publishes what additional requirements are
    needed for UIF Profile T.

    e. We would also indicate that all letters after the "uif-" are reserved for
    use with UIF documents.

    2. Section 3.2, MIME Content Type application parameter, REQUIREMENTS for
    Receivers:

    a. When a Receiver is indicating the document formats that are supported,
    the list must include all the profiles supported and, if M is supported, all
    of the combinations with M that are supported. Thus the job validation
    algorithm that a Receiver uses is still to compare the document format of
    the document being supplied with the list of document formats that the
    Receiver supports. While this may lead to a lot of values for the Receiver's
    "document-format-supported" attribute, we felt it was better to be simple
    minded about it. Some Receivers NEED NOT support all possible combinations,
    but only the ones that make sense. We have a list of recommended in the
    mail message, but I don't think we agreed to indicate that in the document.
    Perhaps in an Implementer's Guide, if we do one? Here are the 19 most
    likely combinations (including t):

      s
      f
      j
      c
      l
      t
      mcs -- combinations with s
      mls
      mcls
      mcf -- combinations with f
      mfl
      mcfl
      mcj -- combinations with j
      mjl
      mcjl
      mt -- combinations with t
      mct
      mlt
      mclt

    b. For the IFX document, we can get rid of the
    "printer-uif-profiles-supported", since the "document-format-supported" will
    contain all of the profiles, including combinations with m. In the UIF
    document, the Sender requirement to query the Receiver for the supported
    profiles still remains (for the IPP FAX protocol, that means the Sender
    queries the "document-format-supported", not the
    "printer-uif-profiles-supported" (which will be deleted).

    3. Section 4 agreements:

    a. Move the description of * and ** to after each table, since they are kind
    of like footnotes.

    b. Clarify that * and ** apply to Receivers.

    c. Add another column between the two which indicates the conformance for
    Senders. Use 1, 2, or 3 to represent MUST, SHOULD or MAY.

    d. Copy TIFF/FX use of **: If ** appears with a value, then that attribute
    MUST be supported, so remove the redundant ** from the field. Explain that
    ** in a value means that value is REQUIRED for a Receiver to support and
    that the entire field is REQUIRED to be supported.

    e. We did not agree to add a note to explain the L* did not mean that L was
    recommended, but that it mean the color space. Implementers will know that
    L* is a color space.

    f. Section 4.6, Profile L, add 200dpi as REQUIRED for the Receiver for
    XResolution and YResolution.

    Lloyd McIntyre said he would try to check the CONNEG examples.

    We also considered the comments from Sharp. Ira's notes indicate the results
    (see below). I've added TH> in two comments for us to add a Note to the UIF
    spec about the Baseline tiff requirements (which are from 1992).

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Thursday, June 28, 2001 08:05
    To: McDonald, Ira; 'ifx@pwg.org'; Thomas, John; Whittle, Craig
    Subject: RE: IFX> FW: [Comments on UIF spec]

    Hi John,

    At yesterday's IPP Fax telecon, we discussed all of your comments.

    Brief replies to the best of my abilities are included in your note
    below, preceded by '<ira>'.

    Cheers,
    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Wednesday, June 27, 2001 11:55 AM
    To: 'ifx@pwg.org'; Thomas, John; Whittle, Craig
    Subject: IFX> FW: [Comments on UIF spec]

    Hi folks,

    Here are comments from my colleague John Thomas at Sharp on UIF spec.

    We should consider them at this afternoon's telecon, if we have time.

    Cheers,
    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: Thomas, John
    Sent: Tuesday, June 26, 2001 5:36 PM
    To: McDonald, Ira
    Cc: Thomas, John; Olbricht, Eric; Whittle, Craig; Koss, Scott; Murdock,
    Joe; Hurtz, Robert
    Subject: RE: IFX> IPP FAX telecon agenda, Wed, June 27, 10-12 PDT (1-3
    EDT)

    Ira -

    Most of my questions and observations are about Universal Image Format (UIF)
    specification.

    1) The text fields for "ImageDescription", "DocumentName", "Software" and
    "DateTime" all use ASCII encodings. As we have discussed in the past, this
    limits these fields effectively to US English. (Is there an encoding for the
    British pound symbol in 7-bit ASCII?). Is this an oversight, or is this
    because of UIF's TIFF-FX/ITU legacy?
    NOTE: IPP-Fax identifies the "native language", at least for notification.

    <ira>
    Adobe Baseline TIFF specified ASCII only and didn't provide a language
    tag or alternate charset facility. Too bad, but UIF docs MUST be strictly
    compliant Adobe Baseline TIFF.
    A note will be added to the UIF spec about this limitation.
    The companion IPP Fax spec will explicitly say that the (localized)
    IPP job attribute 'document-name' SHOULD be used in preference to
    the TIFF 'DocumentName' field.
    'DateTime' doesn't need to be localized (it's a document create timestamp),
    because it can be localized by a client without problem.
    <--->

    2) What is the intended use for the "DateTime" field? Creation date? If
    so, it would be nice if the specification stated this. If an image has a
    creation date, shouldn't it also have an author/copyright holder field?
    Yes, I know this would be easy to edit out, but that would be a felony.
    Right? :-)

    <ira>
    Yes - it's a document creation date/time.
    No - we cannot change the semantics of 'DateTime' to add author.
    <--->

    3) The UIF spec expects the name and revision of the authoring software in
    the "Software" text field. I assume this text is format-free? Human
    readable (that is, if you are an English speaking human). And while we are
    on the subject of "Revision", shouldn't the specification identify its own
    revision? This is a common technique to provide "future backward
    compatibility".

    <ira>
    This is Baseline TIFF legacy. Human-readable in some language that
    can be written in ASCII without any accented Latin characters.

    TH> We probaby need to add some kind of a note about this in UIF.
    <--->

    4) Why do profiles C, F and J (optionally) allow centimeter resolution
    units, but profiles L and M only allow "inch" resolution units? TIFF-FX
    again? Again I ask, how would this specification change if the United
    States FINALLY went metric? Is there a reason to prohibit cross-unit
    compatibility like, for example, the computational cost of a good
    sub-sampling algorithm?

    <ira>
    There are some typos on your list above. The b&w TIFF-FX profiles allowed
    centimers or inches. The color TIFF-FX profiles used inches because
    that's what the engine builders did at the time the TIFF-FX profiles
    were specified. For interoperability, UIF will NOT relax this
    restriction - gateways to Internet Fax and ITU GSTN fax are high
    priority.

    TH> We probaby need to add some kind of a note about this in UIF.
    <--->

    5) Do all (international) bitmap format standards order scan lines
    left-to-right and top-to-bottom? If not, is there a need for UIF to specify
    this order? This scan-line order inherited from the base formats (e.g.
    TIFF-FX)?

    <ira>
    Adobe Baseline TIFF specifies the scan lines order.
    <--->

    6) I prefer the presentation of compliance requirements in the IPP-Fax
    specification to that in the UIF specification. IPP-Fax makes it clear what
    is "receiver" responsibilities and what is "sender" responsibilities. UIF
    doe not.

    <ira>
    Improvements in specification of compliance requirements will be done
    in the UIF spec.

    TH> We agreed (for both UIF and IFX specs to make it clear in the
    Conformance Requirements section what are the Sender requirements and what
    are the Receiver requirements (either in separate sections or a separate
    columns in the same table, whichever makes it clearer).
    <--->

    7) Line 152 of the IPP-Fax specification says: "Universal Interchange Format
    (UIF)". I think it should say "Universal Image Format (UIF)".

    <ira>
    Done - Tom Hastings has it in his edits list.
    <--->

    Please pass on to the appropriate authorities any of these thoughts which
    have any merit.

    Thanks.

    John
    jct@sharplabs.com



    This archive was generated by hypermail 2b29 : Mon Jul 02 2001 - 19:06:16 EDT