> >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.
>
>>> I see your point, but as was discussed in other WGs (namely
IFAX), the
message you are transporting is a FAX message, which has a cover
page already.
This is the same coverpage that qualifies today on a point to point
fax call, and
our legal eagle here is of the studied opinion that an
electronically produced
additional cover page is actually less legal...the payload of the
electronic system
is in fact the legal document, not the wrapping. This includes date
and time
stamps created electronically as part of the wrapping...look at it
like fed ex. Fed
Ex adds their own tracking info...that's nice. But under U.S. AND
International
law, the content of the Fed Ex package is what matters. Fed Ex
tracking info
which includes time and date is NOT admissable anywhere in the world
as either
part of an evidencery trail or "unalterable in nature". However,
the signed and
witnessed document inside the package is evidencery (sp?). My point
is that
even in Germany, the electronic cover sheet is destined for the
round file.
> >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.
>>>Again, we speak legal requirements...I think we really need to
get an offical
recommendation on any legal issue from a governing body. We aren't
lawyers.
A point-to-point fax call does not have any more validity than an
email
between two parties. VCard adds additional security and yes
everyone woiuld
agree this is a great feature. If we can add Vcard and the impact
is not a
perceivable delay for the end user while this is being processed,
AND
IMHO can be satisfied similarly, then fine. My objection was to the
impact
on the majority of fax machines, NOT to the feature itself.
> >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!
>>> See C. Above
> >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.
>
>>> Okay. My suggestion was to take advantage of the capabilities
negotiation...I see you are saying what HAS to be supported as a
bare minimum
so I misunderstood or didn't read the question correctly. I agree a
bare minimum
of Profile TIFF S seems okay.
> >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.
>
>>> Ah...got it. I agree in the context of Fax machine logs
> >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?
>>> New machines. Sharp, Brother, Matsushita (Panasonic) have spent
years cost
reducing the high volume machinese and typically use a single chip
controller for
scanner, compression, printing, and control which makes use of an 8
bit controller.
Higher end machines have lots of horsepower, but the majority (by
several magnitudes)
of fax machines are 8 bit. Add-ons are interesting and will be
applied bring online
the legacy faxes (100 million or so) out there, so this is not
insignificant. Here the BOM
cost has to far south of $50. The memory to do many of the things
we are talking
about in this soon to be working group will grow the cost by 10% to
20% and makes it
impossible to build a product.
I know I am probably being perceived as being severe, but my goal is
to ensure that
this GREAT idea will not get designed to such a state that only
certain high end fax companies
will be the only ones to benefit. In fact, the high end fax
machine,as I said earlier, has
all the horsepower and margin to support all of IPP so it doesn' t
seem as important
to reduce costs for that use.
Internet faxing, in my not so humble opinion, will be ubiquitous
quite soon, and certainly
within a year will not be shipping only in mulit-thousand dollar fax
machines, on the contrary
Internet faxing will be shipping in machines for $200 or less.
--Mike
(Pontification courtesy of the author and does not express the
pomposity of the company that pays him :)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<