B. Cover pages should be the LAST thing we discuss, since this is an add-on
feature that just also happens to be unnecessary for fax operation. Just
because printing uses clever cover pages, does not mean that a fax user or
vendor
cares about cover pages, and not necessarily something we need to support
for high quality docs transmission between fax machines.
C. TLS/VCARD and other security issues will raise problems in selling this
concept to many fax vendors interested in
adding IPP for fax into low end machines with 8 or even 16 bit
microprocessors...we need a believeable estimate as to
how long it takes an 8 bit to process the entire security chain at the
beginning of each session or transaction...delays
perceived by the end user are a major negative impact to the follow-on sales
and success of Internet faxing. See D below.
D. Yes, we need to prevent spoofing. Solutions for doing so need to match
the level of security inherent in the
fax transport. In other words, a 128 bit strong encryption seems a bit too
difficult to lay on an 8 bit controller based low
end fax machine, so let's just make sure our anti-spoofing does not a)
provide for complexities on the simplistic front
panel of an internet fax machine, b) does not appear to inject long
perceived delays in processing at any point in the
fax transmittal process, and c) does not cost the fax vendor an arm and a
leg or huge amounts of negotation time in order
to get a license to use.
E. I believe that since using IPP for fax traffic allows us to negotiate
capabilities, then we support whatever file
formats are possible...i.e. the fax machine will identify whether it can
deal with the source...It seems logical
for the request to be "what capabilities do you have" and the sender than
determine the best quality that can be
sent that the sender can deal with, do any conversions necessary, and then
send that converted message.
F. The concept of IPP Servers are a mystery to me...what are the implied
capabilities of IPP servers (does a receiving fax
machine always act as a server or is there an intervening fax server that
takes IP to a new internet fac machine)? In any
case, server logs would seem to contain info that is NOT part of the
request-response mechanism already built into the
IPP function calls we identified in Minnesota. I believe server logs are
out of scope for our use.
G. For high end fax machines which are MFPs and/or MOPIERS, then IPP is
probably the right set of tools...have those folks implement IPP in its full
richness. For fax, keep it simple...we don't have many $200 or less fax
machines with
staplers, sorting trays, and other finishing options. I counsel eliminating
this feature. Thus I agree with Base Profile.
In general I would recommend we keep in mind:
1. Cannot require storage of a whole message (multiple pages) in the
sender or receiver
2. Cannot require a total byte count of the whole message (all the
pages) since we can't store...see #1
3. Cannot require and additional 1MB of ROM space (what IS the minimal
ROM needed to implement
in an 8 bit situation using the functions defined in Minnesota?).
4. Cannot cause user perceivable delays at any point in the fax
transmittal process.
5. Cannot require upgrade of processor in order to meet any of the
requirements and maintain today's user
perception of performance.
6. Cannot require a huge SW maintenance staff to support the IPP
implementation in the device.
Keep it simple, keep it small, but solve the problems we are trying to
solve. Otherwise just use IPP or T.37.
Mike
> -----Original Message-----
> From: Richard Shockey [SMTP:rshockey@ix.netcom.com]
> Sent: Tuesday, March 23, 1999 12:14 PM
> To:
> Subject: Questions to be addressed...
>
>
> Before Minneapolis started to put together a list of questions that need
> to
> be asked about IPP in relation to the QUALDOCS work.
>
> I'd like to see if anyone would like to start adding to this list ...since
> it might be useful to kick off the Goals work.
>
> Thanks...
>
>
>
> A. What elements of [IPP-MOD] or [IPP-PRO] that are currently optional
> should become mandatory in a IPP/Document Service Mode Base Profile.
>
> B. The need for cover pages. Should the burden of cover page creation be
> solely on the IPP client or should mechanisms be created for IPP clients
> to
> signal IPP servers to create such cover pages?
>
> C. The need for identity exchange between IPP clients and servers. If a
> [VCARD] is adopted as a means of identity exchange, would this require
> support of TLS during Job Submission for all IPP/DSM transactions?
>
> D. Are mechanisms or protocols available to prevent the "spoofing" of the
> identity of a sender?
>
> E. Since support for RFC2301 TIFF file formats will probably be a
> requirement, what level of granularity in attributes needs to be exchanged
> between IPP client and Server? Are TIFF Profiles sufficient or are
> [FAX-SCHEMA] elements required.
>
> F. Facsimile service reports and logs are traditionally kept locally by
> the
> sender and recipient. Should IPP clients be able to query IPP server logs
> and what information should be made available?
>
> G. IPP offers a rich and robust set of job attributes for finishing
> options. Since FAX is traditionally the distribution of 1 copy to a
> recipient, is there a need to restrict the available IPP finishing options
> in an IPP/DSM Base Profile?
>
>
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey
> Shockey Consulting LLC
> 8045 Big Bend Blvd. Suite 110
> St. Louis, MO 63119
> Voice 314.918.9020
> Fax 314.918.9015
> INTERNET Mail & IFAX : rshockey@ix.netcom.com
> eFAX 815.333.1237
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<