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 - 18:15:33 EDT