There is a third alternative to ISSUE 01 - Move the Capability Discovery out
of the UIF document.
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.
This third alternative has the following advantages:
1. It keeps the number of documents that we have to read, understand, and
keep aligned to two: UIF and IFX, not three documents.
2. It keeps the CONNEG in the same document where the UIF Profiles are
defined.
3. It allows the UIF document to be used as a MIME type without CONNEG being
used (because the CONNEG is in an Appendix).
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.
5. It is less of a change to our current documents.
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.
Comments?
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, August 06, 2001 13:34
To: Lloyd McIntyre (E-mail)
Cc: IPP FAX DL (E-mail)
Subject: FW: IFX> IPPFax Minutes -- August 2001 [questions for Lloyd McInt
yre]
Importance: High
Lloyd,
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.
Here are the 4 issues, agreements, and questions to you, extracted from the
IPPFAX minutes:
ISSUE 01: 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).
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.
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).
ISSUE 02: 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).
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.
Lloyd: Can you answer?
ISSUE 04: (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 'profile' parameter which is multi-valued to indicate the
profiles that are in the document? For example:
Content type: image/tiff; application=uif; profile=uif-s,uif-c,uif-mcs
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.
Lloyd: Do you see any problem if the MIME Content Type includes some
profiles that the document doesn't actually use?
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?
Additional UIF-related issues raised at meeting:
ISSUE 06: (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 new TIFF tag to
represent the UIF profiles present in a given IFD? Ask Lloyd about this...
Lloyd: Your comments on the above questions.
Thanks,
Tom
-----Original Message-----
From: John Pulera [mailto:jpulera@minolta-mil.com]
Sent: Friday, August 03, 2001 19:23
To: IPP-Fax Group
Subject: IFX> IPPFax Minutes -- August 2001
Meeting minutes are now available from the August 1 IPPFAX meeting in
Toronto. Thanks Marty for taking notes during review of IFX issues:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc>
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf>
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf
John Pulera
-----------------------------------------
John Pulera
Minolta Systems Laboratory
jpulera@minolta-mil.com <mailto:jpulera@minolta-mil.com>
(949)737-4520 x348
This archive was generated by hypermail 2b29 : Mon Aug 06 2001 - 22:06:28 EDT