What I really meant with my comment, is that the IETF is not very
consistent and clear in what a tranport layers vs. an application layer is,
and keeps on mixing the two in a pragmatic, but architectually unsound and
ad hoc way.
Is the Internet Architecture Board ever paying any attention to these kind
At 03:07 PM 6/4/98 PDT, Ned Freed wrote:
>> > > Once upon a time, a lot of people had email only access to the
>> > > 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
>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
>And IFAX can be done over SMTP. Or HTTP. Or FTP. Or even TELNET. So I
>would not argue that any of these are impossible, since that simply is not
>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
>must not have been listening. I have pointed out, not once but many times,
>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
>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
>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
>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
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514