It might be worthwhile setting the stage so to speak.
Okay, this is a fax centric view. First a fax machine operation.
1. User takes out of box, plugs in power and hooks up phone cable to phone
plug.
2. User configures name to appear on faxes it sends
3. User configures phone number to appear on faxes it sends
4. Users configures fax to auto answer when someone calls (probably a
default condition)
Ready to Go!
5. Someone elsewhere decides to send to fax to our friend above, so drops
in paper and
6. dials the number and presses start
So far this is why fax is so popular...look how simple! Why change this.
7. Fax machine at our friends house rings, answers and the two machines
negotiate capabilities
8. Cuz fax standards are simple (speed is 9600 or 14400, image type is G3
or G4, resolution is fine
or super fine) the machines agree on a format.
9. The 'elsewhere' person's fax sends the image line by line, page by page,
and
10. Our friend's machine receives and prints accordingly. When done we
disconnect from the phone line at both ends.
Now an Internet fax should act as much as similar as possible...except that
instead of phone numbers we
either use an IP address, or better yet a standard hostname (that DNS can
resolve). The connection
between two machines could ideally work the same...i.e.
1. Internet fax at person A dials into ISP. Gets hooked up and "online".
2. Internet fax A sends request for capabilities to internet fax B
3. Internet fax B is NOT online. Ooops. Now what
4. Or Internet B is online (we happen to catch it while it is dialed up),
so Internet fax B responds with
G3 or G4 then waits
5. Internet fax A now sends first page in TIFF wrapped G3 and waits for
response
or continues to send until the job is complete (I am not sure yet how this
part works under IPP)
6. Internet Fax B receives and sends "Okay got it" as the response.
7. Machines "disconnect" from each other, but may or may not hang up the
phone line.
You should see the key issue is the receiving fax machine (or any other
Internet device ) that is not
full time on the network.
a. What do we do if Internet device B is not online at the time Internet
device A "calls".
b. Can a proxy of some sort (i.e. an IPP intermediate server computer (I
didn't want to write a server server))
help resolve this issue?
c. Do we want to instead require an IPP enabled Internet fax be online
at all times (thereby being called a
fulltime fax) or are there other solutions
Where is Larry when you need him?
Mike
> -----Original Message-----
> From: harryl@us.ibm.com [SMTP:harryl@us.ibm.com]
> Sent: Thursday, March 25, 1999 1:29 PM
> To: Michael Crawford
> Cc: 'Richard Shockey'; ifx@pwg.org
> Subject: RE: Word docs
>
>
>
> I probably need to learn more respect for the problem but, right now, it
> sounds like far too many words than necessary.
>
> To send (legacy) FAX, I "dial in" and the fax machine has to "answer".
> This
> is anologues to "logging on" (perhaps via dial to my ISP) and printing to
> a
> URL. The printer has to "be there"... of course.
>
> In either case, if there's a wire laying of the floor at the receiver
> end... no go.
>
> When I re-read your reply, I get the impression you are describing a IPP
> SERVER (printer) that is ISP dial connected. This would be different
> (still... not unlike some of these folks who use the same phone number for
> voice and fax. Sometime I call their "office" and get "carrier blast",
> other times I get their voice mail... hard to know which it will be).
>
> Guess I thought it was the following
>
> >IPP yes, QUALDOCs maybe not. I think you are right...IPP should be >like
> using a printer on a very long LAN (this doesn't suppose >10baseT by the
> way PPP dialup should qualify!).
>
>
> >Of course it is assumed that any IPP 1.0/1.1 client could use a >dial up
> connection.
>
>
> that got us on this thread and this is obviously referring to a dial in
> client.
>
> Harry Lewis
> IBM Printing Systems
> harryl@us.ibm.com
>
>
>
> Michael Crawford <mcrawford@iready.com> on 03/25/99 02:10:59 PM
>
> To: Harry Lewis/Boulder/IBM, Michael Crawford <mcrawford@iready.com>
> cc: "'Richard Shockey'" <rshockey@ix.netcom.com>, Michael Crawford
> <mcrawford@iready.com>, ifx@pwg.org
> Subject: RE: Word docs
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: harryl@us.ibm.com [SMTP:harryl@us.ibm.com]
> > Sent: Thursday, March 25, 1999 12:35 PM
> > To: Michael Crawford
> > Cc: 'Richard Shockey'; Michael Crawford; ifx@pwg.org
> > Subject: RE: Word docs
> >
> >
> >
> > REgarding...
> >
> > >*** Hmm. Isn't it difficult to have a "server" application that isn'
> > >there to serve (i.e. not dialed up when you request service)?
> >
> > We were talking about the CLIENT dialing in (I thought). Not the IPP
> > server.
> >
> Yes, but in IPP it takes two to tango...the client must find the
> destination
> up in order to exchange capabilitiees and to send data...there is no
> notion
> of store and forward, at least not in the present form of the spec.
>
> > It would be equally
> > difficult to send FAX to a machine that was unplugged to from the phone
> > line... no?
> >
> Yes, but a legacy fax is usually plugged in BUT NOT ONLINE...i.e. it
> answers.
> We need to figure out how we answer a request for service by the
> target fax machine
> or specifically say in the specification how a fax machine MUST be
> online in order to
> provide services. The implication is that:
>
> 1. An ISP must dial out (Don't hold your breath)
> 2. A IPP enabled fax periodically comes online (dials up) to
> receive messages creating
> short window for IPP connection to occur
> 3. An IPP enabled fax MUST be on the LAN (oops, this means
> 10BaseT connectivity not dialup) which
> is in turn reachable by the source machine (WAN or Internet
> gateway with hole in firewall).
> 4. A fax service will act as the destination and then forward to
> the true destination when it periodically
> comes online by dialing up.
>
> I like LAN connected faxes, but there is that cost issue once again.
> Higher end Internet fax solutions
> will undoubtedly be on the LAN (look at the first internet fax
> offerings today...LAN connected, expensive
> and volume which hasn't yet paid for the datasheets let alone the
> development of the machine).
>
> Mike
> > Harry Lewis
> > IBM Printing Systems
> > harryl@us.ibm.com
> >
>
>