Well I suspect the machines will look like MFP's actually. I do agree that
mandatory functions have to be kept to a minimum but this class of device
will be connected to networks in many cases so you dont want to restrict
functionality either.
>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.
Well we have to deal with cover pages since this is a legal issue in the
US, Germany etc. There is a presumption that we should look at satisifying
current legal concerns about fax that end users have. Preserve the curent
"look and feel" as much as possible.
You are correct that machine vendors are not particulary conceerned with
cover pages, but gateways and software clients are and it seems prudent to
make recommendations in that area.
>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.
I'd certainly like to know an estimate of TLS transaction processing for 8
or 16 bit but the security issue is very very real and a mandatory
consideration for any IETF protocol. IMHO its the security of TLS that's
going to help sell this to end users. And identification of sender and
recipient is a real issue because of legal considerations.
>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.
Would'nt you want the option of signed or certificate based doucment
transactions for some classes of machines? I can certainly see vendors
wanting this as a value added option!
>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.
But there does need to be some form of least common demoniator and Profile
S TIFF seems appropriate to insure compatiability with T.37 and potential
gateway applications.
>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)?
IPP terminology can be confusing, at first, to folks with a fax background
but what you need to know is that the sender is a IPP client and the IPP
server is the recipient and the transaction object is defined as a Job..now
what that IPP server really is abstracted..its may be a device or server
software that delivers the document to a print queue or something else.
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.
Well there is a problem here in that IPP really does not mandate a response
to time/date information requests since it was assumed that printers don't
have clocks. In fax both sender and recipient maintain transaction logs so
we need a similar requirement here ..the issue is how extensive can the
client query the server.
>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.
You dont need to eliminate these functions ...its just that the IPP server
will not support them and can be queried to that effect. A
"Get_Printer_Atributes" request by the client will return the supported
values. The issue of the work is what is the superset of current IPP
functions that must be returned to clients upon query, or some profile that
can be queried with..such as "Support_Document_Service_Mode" Y/N etc..
>In general I would recommend we keep in mind:
>
> 1. Cannot require storage of a whole message (multiple pages) in the
>sender or receiver
I'm pretty sure this is not a problem.
> 2. Cannot require a total byte count of the whole message (all the
>pages) since we can't store...see #1
I think you have to do this for chunking ?? Right?
> 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?).
I'm curious what the IPP stacks have required myself.
> 4. Cannot cause user perceivable delays at any point in the fax
>transmittal process.
If you want security ... this will happen. If you want really high quality
600x600 with 256 layers of grey scale or color. Then it will be slower by
definition
> 5. Cannot require upgrade of processor in order to meet any of the
>requirements and maintain today's user
> perception of performance.
Are you looking at new machines or "black box" add on's?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<