I dont think anyone wants to ignore volume products.. but the work is
centered on Quality Document Distribution above and beyond what is
currently available. I have not included a requirement for low cost
implementation..is this what you are suggesting? You should note that any
IPP implementation on a device will entail a significant cost well above
the $200 price point due to the necessity for keyboard, network connections
etc.
>> 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.
You missed my point.. if the IPP client is a "network scanning terminal"
(DUH .fax like device) .. we can safely assume that people will fill in the
little cover sheets.. however if the IPP client is software ..yes then we
can make recommendations on how that client should behave.
>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.
The the discussion in the FAX WG centered on the issue of cover pages
through gateways to the PSTN. Not a end point to end point SMTP transaction.
My point
>is that even in Germany, the electronic cover sheet is destined for the
>round file.
They usually are, but they are necessary and currently have a legal basis
on the GSTN. You get your lawyers and I'll get mine ....:-) but we can
offer some limited umbrella to the protocol if we attempt to conform to
current legal requirements. There is come case law on this as well that the
transaction is protected, irrespective of the underlying transport, if it
has shown to attempt conformity with existing law. In other words... I
would have a great case to sue a IPP spammer under the "junk fax" law if we
state our goals well. We can extend the protection of 47 USC 227 to IPP
transactions. That I submit is a useful goal.
The United States Federal Communication Commission
regulations and US Federal Law (47 USC 227) state:
{quote}
"Identification Required on Fax Messages
The FCC's rules require that any message sent to a fax
machine must clearly mark on the first page or on each page
of the message:
* the date and time the transmission is sent;
* the identity of the sender; and
* the telephone number of the sender or of the sending fax
machine.
> A point-to-point fax call does not have any more validity than an
>email between two parties.
In the general case maybe but ...
Not true in many Judicial Districts (California, Wyoming etc) where there
are specific rules on fax that do not apply to e mail transactions etc.
also GSA rules on bid submissions etc.
>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
>impacton the majority of fax machines, NOT to the feature itself.
Please state your position clearly ... we are not talking about existing
GSTN fax machines here. You seem to imply that this work only has value if
the device implementing our new work has a low Bill of Materials cost?
>> >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.
Its really not helpful to continue to insist on goals based on the need to
support 8 bit controllers. Some vendors are interested in adding value
(read margins) to their products and if the ultimately agreed to mandated
features require more sophisticated hardware components .. so be it.
>> 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
So you are saying that the goals must reflect some LCD hardware platform?
See above!
>> 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 minimumso I misunderstood or didn't read the question correctly. I
agree a
>bare minimum of Profile TIFF S seems okay.
Great .. but you realize that other file format support may require much
more sophisticated hardware. Color?
>> 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.
The whole notion of receipt is that both recipient and sender can log
transactions and/or output some transaction response. Like the little slip
of paper thermal fax machines spit out now or the weekly transaction
reports that higher end departmental devices can produce.
>> 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
This is what we are talking about. We OK here ?? Rough Consensus? :-)
>
>> >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.
But remember those high end IPP machines are not required to do some of the
things that we propose like maintain transaction logs with time/date
stamps. The functionality we propose offers the options to them as well.
IPP was designed as a distributed printing protocol not really as a
document transmission service. I know that seems like a Politically Correct
distinction but it means a great deal in the context of what we propose.
>> 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.
Yea I know .. SRP looks like $149.00 with superstore distribution. I've run
these numbers myself. Been there done that.
>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% to20% and makes it impossible
to build a product.
At the price points YOU want!!
But I submit that the introduction of any new technology like this
traditionally begins with higher end devices and works its way down the
price point scale as components become less expensive and more integrated.
This has been the pattern for the whole PC industry .. not to mention the
fax machine industry.
> 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.
Oh I think when we dive into this you'll see that we're not too far off.
High end machine vendors will support color TIFF, PDF ..maybe
certificates. And I suspect they will support RFC 2305 (t.37) as well. The
notion IMHO is that we have needed a Store and Forward as well as a point
to point oriented protocol.
> 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 contraryInternet faxing will be shipping in machines for
$200 or less.
I hope you are right .. but don't forget there are some really serious
issues that are totally outside the scope of this work ...like will network
administrators punch holes in their fire walls for the IPP traffic and how
simply will it be to set up your little $200 boxes as IPP servers on the
network.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<