Re: Tough Love Reply

[Ken Camarro <kcamarro@xxxxxxxx>]

>Return-Path: raylutz@cognisys.com
>X-Sender: raylutz@crash.cts.com
>Date: Wed, 18 Dec 1996 09:18:39 -0800
>To: Ken Camarro <kcamarro@snet.net>
>From: Raymond Lutz <raylutz@cognisys.com>
>Subject: Re: Tough Love Reply
>
>Ken, it would probably be appropriate for you to post this to
>ietf-fax@imc.org since I responded to you in that forum. Your points are
>important and we should air these issues with everyone "tuned in". After
>receiving it there, I will respond in more detail.
>-Raymond
>
>At 11:11 AM 12/18/96 -0500, you wrote:
>>Thanks for comments and patience.  Since I am not a communications engineer
>>I try to use self-descriptive terms.  It's hard for me to read some of this
>>stuff but after a while you learn from the discourse.  I need to get a few
>>handy articles with some good glossaries in them.
>>
>>Hi Ken...
>>
>>.  Our concentration must be on the file and not
>>>the lines.  
>>
>>Ray:
>>
>>Certainly, we need to support the installed base of about 80 million fax
>>terminals and another 80 million computer-fax boards. Long-term, I think we
>>will be using the 'scan here, print there' paradigm "with constraints". An
>>internet-fax gateway looks like a printer with certain constraints, such as
>>standard rendering capabilities, for example.
>>
>>Ken:
>>Understood.  The legacy population will deal with the internet fax gateway.
>>I see Email and Session fax specifications as defining how a new internet
>>fax device will be able to operate peer to peer and to a legacy device
>>through a gateway.  One the specs are done, the gateway design falls into
>>place.
>>
>>I was trying to find a way to say that T.30 is raster line printing because
>>it had to be and that with internet fax we should have the facilities on
>>any internet fax transceiver to think in terms memory send in contrast to
>>line by line sending.
>>
>>Ray:
>>
>>"Real-Time T.30 Tunnelling" through the internet isn't possible from what I
>>can tell. This would be nice to transparently support the installed base of
>>legacy fax devices, but we still would need to consider the internet/fax
>>gateway, and I doubt that this would be any easier than the situation we
>>are in now.
>>
>>Ken:
>>
>>Understood.
>>
>>I guess I am saying that I want to see some efficiency lingo.
>>
>>I understand the tunneling notion.
>>
>>>I certainly hope that we do not default to line-by-line
>>>transmission in Session fax.  
>>
>>I don't think this was ever (seriously) proposed. However, there is a
>>proposal to support "streaming" mode where the sending device would be able
>>to start transmitting the first page prior to scanning the entire document.
>>This is important for low-memory requirement in the terminals themselves.
>>
>>Understood.
>>
>>>As a matter of fact, I don't see why session
>>>fax has to be T.30 real time.  
>>
>>I will send the terminology mail around. "Session" fax is not "real-time"
>>these have different definitions.
>>
>>Ken:  
>>
>>I only said this because there were remarks about T.30 timeouts etc. and I
>>thought T.30 timeouts were only going to come into play with internal fax
>>gateway and in session fax there would be a new set of control parameters
>>for the compliant device.
>>
>>>If Internet Session Fax cannot quite do T.30
>>>Real Time within the boundaries of the Internet infrastructure, then let
>>>the sender use T.30 when this is necessary.  Our focus must be on the 98%
>>>of fax transmissions which can live with whatever the Internet
>>>infrastructure allows not the other 2 %.
>>
>>No, we're not going to support real-time tunnelling as I mentioned, to my
>>knowledge.
>>
>>Your comments here are littered with misconceptions on terminology. Please
>>review the terms.
>>
>>>2.      Legacy facsimile transmitters and receivers are going to have to go
>>>through a private black box or ISP service to operate over Internet
>>>
>>An internet/fax gateway is the black-box you are speaking of. If you look
>>closely, you will recognize this as my favorite topic, an MFP. The MFP can
>>be accessed using the computer port to the internet and can simultaneously
>>be connected to the PSTN using T.30. So, they act like internet/fax
>>gateways, and will be strongly affected by the "constraints" that I
>mentioned.
>>
>>Ken:
>>I love it!
>>
>>>
>>>3.      Facsimile Internet compliant transmitters and receivers (customer
>>>premise devices) will have an alphanumeric keyboard or facility in order to
>>>present Internet Facsimile addresses.
>>
>>This hasn't been determined yet, but this is a possibility.
>>
>>Ken:
>>This is a certainty and let's start talking like this!  You must assume
>>that the standalone device is not connected to a PC!
>>
>>>4.      Facsimile Internet compliant  transmitters and receivers (not
>>>legacy systems) will send and receive files in _MMR_ or better and in any
>>>resolution selected by the transmitter thus 100X200 or 200X200 or 300X300
>>etc.
>>
>>Probably other encodings will be supported. We don't need to limit the
>>encodings, but it may be a smart idea so that our conversions can be
>>limited to one type. MMR is harder for computer-fax and is certainly in
>>conflict with the "one line at a time" point you were making earlier.
>>
>>Ken:
>>I only said MMR because I am thinking of  the content file that is going to
>>be kicked around.  I don't see a need to lug an MH file between servers
>>once the fax is onto the internet!  It can be some other format that's why
>>I said MMR or better.
>>
>>>5.      Both Email Fax and Session Fax messages or transmissions will occur
>>>in MMR format or better between the origination server and the destination
>>>server which means that the Internet portion will be conducted under MMR or
>>>better.
>>
>>This is not determined yet, and it doesn't matter what it is as long as we
>>agree it is one thing.  
>>
>>Ken:
>>It does matter that it is efficient.  If each entry server receives in MMR
>>or better, or converts to MMR (in gateway situations) then everyone
>>benefits.  The decompression can be done on the receiver or the last
>>server.  Imporatnt to use smallest file while in transit.
>>
>>As above.  I want to hear we selected this because it saves file space
>>etc.! I think this is obvious to most but there are some who still live in
>>the MH world because of some constraint.  I got a note from a portable
>>device guy who indicated the limitations of cellular fax at 4.8 kbs and
>>std. mode because a fine mode file was too large.  He didn't understand
>>that MR and MMR reduces the file size and that the PC fax world is in bad
>>shape because many PC fax chips, the PC bus and architecture are not fax
>>friendly. His device could possibly have the MIPS but his chip is MH.
>>
>>>6.      The objective is to _clip fax file sizes_ over the Internet now to
>>>enable internet intermediaries and the enduser to enjoy smaller fax file
>>>sizes wherever possible.  This is good.
>>
>>The tradeoff is compression/decompression complexity.
>>
>>Ken:
>>As above.  It's our job to architect this correctly. It is a requirement.
>>
>>>7.      The internet network will never see a 100x200, 9.6 kbs MH session. 
>>
>>100x200 is probably a possibility, if that is the resolution of the
>>original scan, probably from a legacy device. I don't see the merit in
>>up-converting this to 200x200 just for uniformity-sake. 9.6kbs doesn't make
>>any sense on the internet. Check your comment again.
>>
>>Ken:
>>I understand 100x200 is virtually default and is o.k.
>>
>>What do you mean by check comment?
>>
>>I was saying that an internet fax gateway might typically see this but it's
>>unlikely that this will occur in session fax because:
>>
>>1.      An internet compliant device will talk to the SMTP server over data
>>modem.
>>
>>2.      I don't think we are going to require the SMTP server to install
>>fax modem 
>>
>>3.      An internet compliant device will be able to operate at V.34 with
>>step down.
>>
>>4.      If we send the raster line data as a file we don't need the error
>>correction and error recovery of MH and MR nor ECM with  MMR so everything
>>can be faster if we have the transmitter prepare the file or page files and
>>then use the internet infrastructure!  That does not mean that it cannot be
>>recreated at the terminus. 
>>
>>>8.      The destination point Internet Server will translate the fax file
>>>into the highest level capable by the receiver through T.30 if this is
>>>necessary.  This would occur when a compliant transmitter sends an Email
>>>Fax transmission to a legacy fax machine which receives its messages from
>>>an ISP service.
>>
>>You are missing some important points:
>>
>>==> Internet fax gateway should be able to convert text/plain;charset=xxx
>>so that email messages, like this one, can be received by legacy fax
>>devices if the receiver so desires.
>>
>>Ken:
>>Agree, is a standard fax gateway facility.
>>
>>==> It is probably also important for the gateway to be able to render
>>encapsulated HTML documents, since this is the "internet" page description
>>language.
>>
>>Ken:
>>And send to the legacy receiver is good.
>>
>>>
>>>Precedent:
>>>
>>>        If you are not aware, Microsoft will only release Windows 97 on a
>>>new PC platform.  
>>
>>I don't believe it. This is pre-release HYPE that MS is certainly famous
>>for. If you think Bill is going to thumb his nose at the installed base of
>>Pentiums, I think you are in for a rude awakening....
>>
>>Plus, I doubt that most large corporate buyers are ready for another
>>massive software upgrade. They will probably thumb their noses back...
>>
>>>Microsoft has steadily been releasing updated versions of
>>>Windows 95 but only to OEM PC vendors who load the OS directly into a new
>>>PC.  If you have the original Windows 95, you can upgrade pieces over the
>>>MS bulletin board only, you cannot buy an upgrade kit.  Devilish isn't it.
>>>This is the mother-of-all -trade-up-incentives.  But there are practical
>>>reasons too.  The older platforms just don't support plug and play and
>>>other new subroutines. And to release Windows 95.5 or 96 would be a support
>>>nightmare.  See PC Computing November 1996, pages 152-      
>>
>>Ken:  Read the article. Will send you a copy.
>>
>>>
>>>Moral:
>>>
>>>If the user wants to make use of Internet Fax, he will have to obtain
>>>Internet Fax equipment.  Otherwise the customer can use T.30 over the PSTN
>>>or an intermediary service or device.  Tough isn't it.  But this is
>>reality.  
>>
>>Sorry, Ken, I disagree with your conclusion. Please wait before you start
>>trying to reach such conclusions until this area has been developed
>>further, and you have had time to fully research the information and at
>>least are familiar with the current terminology.
>>
>>Ken:
>>I stand by my claim.  I will wait.  He will need internet capable equipment
>>or he will need a gateway.
>>
>>I feel strongly about exploiting the internet infrastructure and believe
>>_Internet Fax has to be optimized using the best internet paradigms_ and I
>>believe we should not carry any baggage we do not need to.  Remember our
>>job is not to make it possible to replace T.30 PSTN fax in every case.  We
>>may not be able to do it..  I also feel strongly about not undermining fax
>>in any way. But you can see from the discourse that we are dealing with a
>>lot of orbits here.  The bias should be to commercial users first and
>>consumer users second or in that sequence since business will underwrite a
>>lot of the development costs which later can filter to consumer.  Thus we
>>may not be able to support every  application at first.  But I think
>>support of the business laptop with internet fax is a requirement.  Maybe
>>not every Wizard.
>>
>>Once the Email Fax and Session Fax  specifications are developed that
>>defines the gateway which is Internet Fax and T.30/T.4/T.6.  T.30/T.4/T.6
>>already is and the Internet already is.
>>
>>The internet fax terminal can be a multifunction product and have T.30 PSTN
>>and Internet fax coresident.  It will need a data/fax modem.  It will need
>>a keyboard and display. 
>>>Tip:
>>>
>>>        Worrying about old transceivers which only operate in 100X200 is
>>>madness.
>>
>>Ken:
>>I assume that the gateway would handle this.
>>
>>WRONG. Tip: Please stop giving tips.
>>
>>Ken:
>>O.K.
>>
>>Sorry about long response and thanks.
>>
>>
>>
>>Ken Camarro			
>>Camarro Research
>>Product and Marketing Development
>>580 Commerce DR
>>Fairfield, CT 06432-5513
>>
>>Tel 203-336-4566  Fax 203-331-0470
>>
>>email: kcamarro@snet.net
>>
>>MFP Focus Group Project Info:
>>
>><http://www.mfpa.org/cgi-bin/HyperNews/get.cgi/industry-pr/2.html>
>>
>>
>
>/***********************************************************************
>** Raymond Lutz                             Voice: 619-447-3246
>** Director R & D, Cognisys, Inc.           Fax:   619-447-6872 
>** MFPA EC Chair                            MFPA:  1-800-603-MFPA
>** 1010 Old Chase Ave., Suite B             EMail: raylutz@cognisys.com
>** El Cajon (San Diego Co.), CA 92020 USA   
>** WWW:   http://www.cognisys.com           http://www.mfpa.org
>***********************************************************************/
>
>