IFX Mail Archive: RE: Online and connected?

IFX Mail Archive: RE: Online and connected?

RE: Online and connected?

Michael Crawford (mcrawford@iready.com)
Tue, 30 Mar 1999 17:43:45 -0800

The notion of dialup works with the "always" connected model when the sender
is a dialup
and the receiver is "always available" (i.e. Lan connected to the Internet
via a gateway or via
intranet).

Dialup Fax to Connected Device is a likely type of transaction where a
dialup fax meets this criteria.
Thus a dialup fax (or other device, digital camera, portable scanner, PDA,
etc.) might choose to dialup and
"come online", send a print job to a well known connected device (a printer
back at the main office), and
then wait for the results to be verified.

In this case the dialup device will not have to be a server, since it is
only online for the time it is being
a sender...

My question is how does this fit into the things we have been discussing,
and is this scenario a
viable reason for a low end fax vendor to invest in using IPP for fax.

Mike

> -----Original Message-----
> From: Graham Klyne [SMTP:GK@Dial.pipex.com]
> Sent: Tuesday, March 30, 1999 9:58 AM
> To: Nick Webb
> Cc: ifx@pwg.org
> Subject: Re: Online and connected?
>
> Nick,
>
> What I was trying to do was raise general issues of dealing with
> intermittently connected receivers so that a rational decision could be
> made about whether they should be supported.
>
> You raise more of the same, in the context of using IPP in a s&f context.
> I really don't want to get into protocol detail at this time -- but the
> points you raise certainly may need to be addressed if we were to try and
> support a s&f mode using IPP.
>
> #g
>
>
> At 15:24 29/03/99 -0700, you wrote:
> >
> >>That may be so. But I wasn't thinking of that when I wrote that.
> >>(Actually, I was thinking of possibly using IPP as a transfer mechanism
> >>to/from a message store. But, my purpose here is not to discuss
> >>solutions, but requirements, so that's equally irrelevant.)
> >
> >If we accept that some form of store and forward intermediary is possible
> >(I'm not entirely convinced it's within the scope that we've been
> >considering, but I'll go with the consensus) without necessarily
> discussing
> >how the solution would work, it does bring up the issue of authentication
> >between sender and recipient (the analog of the CSID string, time and
> date)
> >and who gets notifications and when, so it's a good point to bring up.
> >
> >I think IPP could handle being the protocol for this sort of dial-up
> >connection, but it wouldn't be an efficient way to do it. IPP is
> initiated
> >by the client end rather than requested by the server, so any document
> >store would have to act as an IPP client to transfer the stored document
> to
> >its ultimate destination. However, the only mechanism I'm aware of to
> >handle this store-and-forward functionality is repeatedly polling the
> >server to see if it's up (that could be as simple as ICMP echoes, but
> it's
> >still ugly).
> >
> >Then again, an ISP could implement a QualDocs repository which would be
> the
> >document store you describe, with the dial up server using some other
> >protocol (maybe SMTP) to get the job. I guess that's the same as the SMTP
> >gateway I mentioned in an earlier post on the subject.
> >Cheers,
> >Nick Webb
> >
> >
> >
> ------------
> Graham Klyne
> (GK@ACM.ORG)