> > > Once upon a time, a lot of people had email only access to the Internet.
> > > That wasn't an good reason for forcing every service to run over email.
> > My favorite example is email over FTP. We'd still be doing email that way
> > if we hadn't deployed a new email service on a separate port.
> If this is your favorite example, why have I not heard you arguing that
> IFAX cannot be done over SMTP?
Well, first of all, because one doesn't follow from the other. I never said it
is impossible to do email over FTP -- the fact of the matter is that it was
possible to do it, and had we continued in that vein I see no overwhelming
obstacle to doing it this way today.
Similarly, it is possible to do IPP over HTTP. Or SMTP. Or FTP. Or even TELNET.
And IFAX can be done over SMTP. Or HTTP. Or FTP. Or even TELNET. So I certainly
would not argue that any of these are impossible, since that simply is not the
case.
Now, I suspect you intended to say was:
If this is your favorite example, why have I not heard you arguing that
IFAX should not be done over SMTP?
And the answer to this is simply that if you have not heard me arguing this you
must not have been listening. I have pointed out, not once but many times, that
if the service characteristics needed by a new IFAX service are intrinsicly
different from those of an email service then the only available option is to
build IFAX as a separate and cleanly dilineated service. There is no way to
achieve interoperability otherwise, and interoperability is something the IETF
requires.
However, I have also pointed out that the cost of building a new store and
forward service is high, far higher than the cost of simpler point-to-point
services, and that this cost has to be weighed against benefits of that new
service.
I am largely neutral on which way the IFAX work goes on this point. My major
concern has been that if IFAX is to be defined as a profile of email and not as
a new service, that it approach this layering realistically and carefully, so
as not to break existing services or damage the service models already in
place.
Ned