IFX Mail Archive: IFX> More IFX ISSUES around image/tiff app

IFX Mail Archive: IFX> More IFX ISSUES around image/tiff app

IFX> More IFX ISSUES around image/tiff application parameter value

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Jun 26 2001 - 21:16:05 EDT

  • Next message: McDonald, Ira: "IFX> FW: [Comments on UIF spec]"

    I just got off the phone from Lloyd McIntyre. He has been away for a month
    and so did not participate in this discussion (see thread below).

    ISSUE A: MIME type application parameter should be the profile

    He strongly suggested that we represent the profile in the parameter value,
    not just bw vs. color. He had wished that the Internet Fax folks that done
    the same thing.

    Thus he supports IPP FAX using approach a below, i.e.:

    image/tiff; application=uif-s
    image/tiff; application=uif-f
    image/tiff; application=uif-j
    image/tiff; application=uif-c
    image/tiff; application=uif-l
    image/tiff; application=uif-m
    and any additional profiles invented in the future such as t.

    This would mean that the IFX protocol document would have the above values
    for the "document-format" operation attribute and for the
    "document-format-supported" Printer attribute.

    ISSUE B: Profile M is really a meta Profile

    Profile M (MRC) is really a structure for holding the other profiles. So
    when a document is sent using Profile M, there is no indication of what
    other profiles it contains. He suggests that we could come up with some
    syntax for the parameter value that indicates the possible other profiles.
    For example, just append other profiles (in some canonical order):

    image/tiff; application=uif-msc

    for a document that contains Profile S and C under Profile M.

    We can enumerate the RECOMMENDED combinations (other combinations are
    possible but NOT RECOMMENDED). There are 19 RECOMMEND combinations
    (including the new T Profile nearing approval) which are:

      s
      f
      j
      c
      l
      t
      msc
      msl
      mscl
      mfc
      mfl
      mfcl
      mjc
      mjl
      mjcl
      mt
      mtc
      mtl
      mtcl
        

    ISSUE C: Which Profiles under M does the Printer support?

    For the "document-format-supported" the number of values can get large when
    Profile M is supported and the Printer has to indicate all the Profiles that
    it supports under M. We can RECOMMEND that an IPPFAX Printer support under
    M all of the profiles that it supports separately. We could even REQUIRED
    it. Then the combinations of M could be eliminated and we would be back to
    7 possible values, instead of 19. Also the "document-format-supported"
    wouldn't need to enumerate any of the possible profiles under M that the
    Printer supports, since any profile that it support separately it must also
    support under M (if it supports M).

    ISSUE D: Is "printer-uif-profiles-supported" still needed with
    "document-format-supported"?

    Which leaves what to do about the similar "printer-uif-profiles-supported"
    Printer attribute which has the values, 'uif-s', 'uif-f', 'uif-j', 'uif-c',
    'uif-l', and 'uif-m', i.e., the profiles supported, same as
    "document-format-supported" will be.

    Can we get rid of the "printer-uif-profiles-supported" Printer attribute,
    because the "document-formats-supported" has all of the values?

    Or should we keep the "printer-uif-profiles-supported" Printer attribute,
    since its value isn't colored by the value of the "ippfax-semantics"
    Operation attribute passed in the Get-Printer-Attributes request? Then the
    client can get the profiles supported even when just querying the Printer
    using IPP semantics (the "document-format-supported" Printer attribute is
    colored by the value of "ippfax-semantics" operation attribute supplied in
    the Get-Printer-Attributes request).

    Comments?

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Monday, June 18, 2001 14:06
    To: 'Hastings, Tom N'; McDonald, Ira; 'don@lexmark.com';
    jpulera@minolta-mil.com
    Cc: IPP-Fax Group; Lloyd McIntyre (E-mail); Robert Buckley (E-mail)
    Subject: RE: IFX> some UIF issues...thoughts anyone?

    Hi Tom,

    I much prefer your first choice (application=uif-s, etc.).

    It's consistent. The existing 'faxbw' and 'faxcolor' keywords
    imply specific minimum black and white and color TIFF-FX profiles.
    We would merely be making the profile more explicit (and also
    more constrained, per our UIF spec).

    Cheers,
    - Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, June 18, 2001 4:39 PM
    To: McDonald, Ira; 'don@lexmark.com'; jpulera@minolta-mil.com
    Cc: IPP-Fax Group; Lloyd McIntyre (E-mail); Robert Buckley (E-mail)
    Subject: RE: IFX> some UIF issues...thoughts anyone?

    John, Ira, and Don,

    Another possibility is to encode the profile letter (s, f, j, c, l, m, ...)
    either:

    a) in application parameter itself or
    b) with another parameter.

    I'm not familiar enough with the tiff/fx registration procedures to know
    whether introducing new parameters is allowed, or whether we can only add
    values to the 'application' parameter.

    For approach a, we would have:

    image/tiff; application=uif-s
    image/tiff; application=uif-f
    image/tiff; application=uif-j
    image/tiff; application=uif-c
    image/tiff; application=uif-l
    image/tiff; application=uif-m
    and any additional profiles invented in the future.

    For approach b, we would have:

    image/tiff; application=uif; profile=s
    image/tiff; application=uif; profile=f
    image/tiff; application=uif; profile=j
    image/tiff; application=uif; profile=c
    image/tiff; application=uif; profile=l
    image/tiff; application=uif; profile=m
    and any additional profiles invented in the future.

    By indicating the profile in the MIME Media Type, we more fully describe the
    contents of a document.

    Another advantage with either of these approaches is the existing IPP/1.1
    "document-format-supported" Printer attribute would indicate which profiles
    were supported (as well as the MIME Media Type) and we wouldn't need to add
    the "uif-profiles-supported" (1setOf type2 keyword) Printer Description
    attribute.

    Comments?

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Monday, June 11, 2001 12:16
    To: 'don@lexmark.com'; jpulera@minolta-mil.com
    Cc: IPP-Fax Group
    Subject: RE: IFX> some UIF issues...thoughts anyone?

    Hi Don and John,

    I agree with you both that using the exising Internet Fax
    values for 'application' is a bad idea.

    What about equivalent 'uifbw' and 'uifcolor' (rather than
    just 'uif') - the info from the 'faxbw' and 'faxcolor' is
    of great value to renderers as well as intermediate systems.

    Cheers,
    - Ira

    -----Original Message-----
    From: don@lexmark.com [mailto:don@lexmark.com]
    Sent: Friday, June 08, 2001 9:22 AM
    To: jpulera@minolta-mil.com
    Cc: IPP-Fax Group
    Subject: Re: IFX> some UIF issues...thoughts anyone?

    John:

    In regards to #1, I prefer image/tiff; application=uif for the very reasons
    you
    stated.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Alliances and Standards *
    * Lexmark International *
    * 740 New Circle Rd C14/082-3 *
    * Lexington, Ky 40550 *
    * 859-825-4808 (phone) 603-963-8352 (fax) *
    **********************************************

    "John Pulera" <jpulera%minolta-mil.com@interlock.lexmark.com> on 06/07/2001
    12:44:50 PM

    Please respond to jpulera%minolta-mil.com@interlock.lexmark.com

    To: "IPP-Fax Group" <ifx%pwg.org@interlock.lexmark.com>
    cc: (bcc: Don Wright/Lex/Lexmark)
    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 : Tue Jun 26 2001 - 21:16:51 EDT