attachment-0001
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>There
is a third alternative to ISSUE 01 - Move the Capability Discovery out of the
UIF document. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001>Alternative 3: Move the Capability Discovery section 4
to an APPENDIX of the UIF spec. Then put a condition conformance statement
in the Appendix, something like: The CONNEG in this Appendix is REQUIRED
wherever CONNEG is being used. If CONNEG is not being used, then this
Appendix does not apply.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>This
third alternative has the following advantages:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>1. It
keeps the number of documents that we have to read, understand, and keep aligned
to two: UIF and IFX, not three documents.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>2. It
keeps the CONNEG in the same document where the UIF Profiles are
defined.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>3. It
allows the UIF document to be used as a MIME type without CONNEG being used
(because the CONNEG is in an Appendix).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>4. If
some other protocol that also uses CONNEG, such as Internet FAX, wants to use
UIF as a document format, then they only have to reference our UIF document,
instead of referencing two documents.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>5. It
is less of a change to our current documents.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=104173300-07082001>6. If
we moved the CONNEG to the IFX document (one of the alternatives suggested for
resolving ISSUE 01), then some other protocol that also uses CONNEG, such as
Internet FAX, wants to use UIF as a document format, then they would have to
reference our UIF document and the IFX document which contains a lot of protocol
they they wouldn't be using.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001>Comments?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=104173300-07082001>Tom</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Hastings, Tom N
[mailto:hastings@cp10.es.xerox.com]<BR><B>Sent:</B> Monday, August 06, 2001
13:34<BR><B>To:</B> Lloyd McIntyre (E-mail)<BR><B>Cc:</B> IPP FAX DL
(E-mail)<BR><B>Subject:</B> FW: IFX> IPPFax Minutes -- August 2001
[questions for Lloyd McInt yre]<BR><B>Importance:</B>
High<BR><BR></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=096151420-06082001>Lloyd,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=096151420-06082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=096151420-06082001>From
the IPPFAX WG meeting last week, there are two issue resolutions that the
group wants your input on for the UIF document. I've also asked for your
advice on Issue 01 and Issue 04. We're having another telecon, this
Thursday, August 9, 8 AM PST. It would help if you could respond by then
to the mailing list. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=096151420-06082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=096151420-06082001>Here
are the 4 issues, agreements, and questions to you, extracted from the
IPPFAX minutes:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=096151420-06082001></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=096151420-06082001><FONT face="Times New Roman" color=#000000
size=3></FONT>
<P class=MsoBodyText2><B><SPAN style="FONT-STYLE: normal">ISSUE
01</SPAN></B><SPAN style="FONT-STYLE: normal">:<SPAN
style="mso-spacerun: yes"> </SPAN>Should the capabilities discovery
portion of this spec be removed and placed into a specification that deals
solely with how IPPFAX uses capabilities discovery? Advantages: other
applications interested in using UIF simply as a data format can do so (no
prohibitive excess baggage).<o:p></o:p></SPAN></P>
<P class=MsoBodyText2>The group thought it was a good idea to either create a
new document or move the sections relating to capabilities discovery (e.g.,
UIF Section 4) to the IFX protocol spec.</P>
<P class=MsoBodyText2><SPAN class=096151420-06082001>Lloyd: The
advantage of a separate document, as opposed to moving it to the IFX protocol
spec (IPP FAX Protocol spec), is that if some other protocol wanted to use UIF
as a document format and use CONNEG, such as Internet FAX, they could do so
without having to reference the IFX protocol).</SPAN></P>
<P class=MsoBodyText2><SPAN class=096151420-06082001></SPAN> </P>
<P class=MsoBodyText2><SPAN class=096151420-06082001><B><SPAN
style="FONT-STYLE: normal">ISSUE 02</SPAN></B><SPAN
style="FONT-STYLE: normal">: Should we break UIF Profile C into two
profiles—one to represent a baseline grayscale configuration and the other to
represent a baseline color configuration? This way, a greater number of device
capabilities configurations would be allowed without requiring an
implementation of CONNEG. (The same could apply to UIF Profile
L).</SPAN></SPAN></P>
<P class=MsoBodyText2><SPAN class=096151420-06082001><SPAN
style="FONT-STYLE: normal"></SPAN> </P>
<P class=MsoBodyText2>The group decided this is a good idea; however we felt
it a good idea to check with Lloyd McIntyre about the direction in which
TIFF-FX is heading and why TIFF-FX hasn’t adopted a similarly tiered scheme
for Profiles C and L. Also, we need to check with Lloyd about what the
consequences should be to the tree diagram shown in section 3.1.</P>
<P class=MsoBodyText2> </P>
<P class=MsoBodyText2><SPAN class=096151420-06082001>Lloyd: Can you
answer?</SPAN></P>
<P class=MsoBodyText2><SPAN class=096151420-06082001></SPAN> </P>
<P class=MsoBodyText2><SPAN class=096151420-06082001> </P>
<P class=MsoNormal><B>ISSUE 04</B>: (not in the document; see section 5.1.1)
Should we change the MIME media registration to be simply a single value for
the application parameter and add a new<SPAN style="mso-spacerun: yes">
</SPAN>'profile' parameter which is multi-valued to indicate the profiles that
are in the document? For example:</P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center>Content type:
image/tiff; application=uif; profile=uif-s,uif-c,uif-mcs</P>
<P class=MsoNormal> <o:p></o:p></P>
<P class=MsoBodyText2>Yes this is a good idea, except the profile portion of
the mime type (i.e., “profile=uif-s,uif-c,uif-mcs” in above example) should be
OPTIONAL, and indicates those profiles that a Receiver can expect to (but not
necessarily) find in the UIF data.</P>
<P class=MsoBodyText2> </P>
<P class=MsoBodyText2><SPAN class=096151420-06082001>Lloyd: Do you see
any problem if the MIME Content Type includes some profiles that the document
doesn't actually use? </SPAN></P>
<P class=MsoBodyText2><SPAN class=096151420-06082001>I'd like to hear the
group's ideas on why they added this caveat. For example, if a client is
capable of scanning color, but the user requests that the document be scanned
in gray scale, the client MUST NOT include the color profile in the Content
Type. On the other hand, if the user didn't request to scan in gray
scale, and the Sender's default is to scan in color, but the document scanned
only had black and white, is that when it is ok for the Sender to include the
color profile in the Content Type, even though the document didn't actually
contain any color?</SPAN></P>
<P class=MsoBodyText2><SPAN class=096151420-06082001></SPAN> </P>
<P class=MsoBodyText2><SPAN class=096151420-06082001> </P>
<P class=MsoNormal>Additional UIF-related issues raised at meeting:</P>
<P class=MsoNormal><B>ISSUE 06</B>: (raised at meeting) In the current spec,
the ‘FaxProfile’ tag introduced in RFC2301 is re-interpreted as the
‘UIFProfile’ tag for UIF Documents. Also, the meaning of each value for this
tag is redefined to refer to inclusion of UIF profiles rather than IFAX ones.
The group thought this is not a legitimate thing to do. Should we register a
<I>new</I> TIFF tag to represent the UIF profiles present in a given IFD? Ask
Lloyd about this…</P>
<P class=MsoNormal> </P>
<P class=MsoNormal><SPAN class=096151420-06082001>Lloyd: Your comments
on the above questions.</SPAN></P>
<P class=MsoNormal><SPAN class=096151420-06082001></SPAN> </P>
<P class=MsoNormal><SPAN class=096151420-06082001></SPAN></SPAN></SPAN><SPAN
style="FONT-STYLE: normal"><SPAN
class=096151420-06082001>Thanks,</SPAN></SPAN></P>
<P class=MsoNormal><SPAN style="FONT-STYLE: normal"><SPAN
class=096151420-06082001></SPAN><SPAN
class=096151420-06082001>Tom</SPAN> <o:p></o:p></SPAN></P></SPAN></SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> John Pulera
[mailto:jpulera@minolta-mil.com]<BR><B>Sent:</B> Friday, August 03, 2001
19:23<BR><B>To:</B> IPP-Fax Group<BR><B>Subject:</B> IFX> IPPFax Minutes
-- August 2001<BR><BR></FONT></DIV>
<DIV><FONT size=2>
<DIV><FONT face=Arial><SPAN class=656251202-04082001>Meeting minutes<SPAN
class=760431802-04082001> </SPAN>are now available from the August 1
IPPFAX meeting in Toronto. Thanks Marty for taking notes during review of
IFX issues:</SPAN></FONT></DIV>
<DIV><SPAN class=656251202-04082001></SPAN><FONT
face=Arial></FONT> </DIV>
<DIV><FONT face=Arial><A
href="ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc">ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc</A></FONT></DIV>
<DIV>
<DIV><A
href="ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf"><FONT
face=Arial>ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.<SPAN
class=656251202-04082001>pdf</SPAN></FONT></A></DIV>
<DIV><SPAN class=656251202-04082001></SPAN><FONT
face=Arial></FONT> </DIV>
<DIV><SPAN class=656251202-04082001></SPAN><FONT
face=Arial></FONT> </DIV>
<DIV><FONT face=Arial><SPAN class=656251202-04082001>John
Pulera</SPAN></FONT></DIV>
<DIV><SPAN class=656251202-04082001></SPAN><FONT
face=Arial></FONT> </DIV>
<DIV><FONT size=2><SPAN class=656251202-04082001>
<DIV><FONT face=Arial
size=1>-----------------------------------------</FONT></DIV>
<DIV><FONT face=Arial size=1>John Pulera</FONT></DIV>
<DIV><FONT face=Arial size=1>Minolta Systems Laboratory</FONT></DIV>
<DIV><FONT face=Arial size=1><A
href="mailto:jpulera@minolta-mil.com">jpulera@minolta-mil.com</A></FONT></DIV>
<DIV><FONT face=Arial size=1>(949)737-4520 x348</FONT></DIV>
<DIV> </DIV></SPAN></FONT></DIV></DIV></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>