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