The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. Appendices A,
B, C, and D describe the use of SMTP with various transport
services.
A Glossary provides the definitions of terms as used in this
document.
An important feature of SMTP is its capability to relay mail across
transport service environments. A transport service provides an
interprocess communication environment (IPCE). An IPCE may cover
one
network, several networks, or a subset of a network. It is
important
to realize that transport systems (or IPCEs) are not one-to-one with
networks. A process can communicate directly with another process
through any mutually known IPCE. Mail is an application or use of
interprocess communication. Mail can be communicated between
processes in different IPCEs by relaying through a process connected
to two (or more) IPCEs. More specifically, mail can be relayed
between hosts on different transport systems by a host on both
transport systems.
This, as well as the fact that NNTP, FTP, and HTTP all use "T" for
transfer, suggests that "transfer" has been used for a long time to
indicate something with application semantics, sitting on top of some
transport (or transmission) protocol.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/
On May 14, 2006, at 9:24 AM, Gervas Douglas wrote:
> Looks like jargon drift to me if the likes of Sanjiva are not clear
> about it. Transfer, transport, queueing, messaging, communication
> process... Are any of you old enough to rememeber that huge extinct
> construct in comms. which was referred to tersely as "OSI"? It died
> out gradually in the early to mid-90s due to a combination of
> American boycott (not a standard controlled there) and apathy and
> inaction on the part of Europe and Japan. However there still
> remains one useful relic: the OSI Reference Model!
>
> This is still useful in terms of layering a protocol stack and
> defining (hopefully) clean boundaries of demarcation of
> functionality, each layer intercommunicating in what is essentially a
> client/server process with the layer immediately above and below it.
> Each layer is oblivious of the internal workings of its contiguously
> neighbouring layers, and only needs to know and conform to their
> functional interface protocols. Actual interaction is via "service
> primitives". Two entities at the same stack level intercommunicate
> by going up and down their respective stacks. Nothing original here
> - TCP/IP works in exactly the same way.
>
> Could this concept be usefully applied to this new thread topic?
>
> Gervas
>
> --- In [email protected], Sanjiva
> Weerawarana <[EMAIL PROTECTED]> wrote:
>>
>> I'll admit, I'm one of those who cannot explain the diff if my 10
> year
>> son were to ask me :).
>>
>> Can one of the more enlightened please give concise definitions and
>> explain the difference please? Please do not point me to the HTTP
> spec;
>> that does not help. Nor to Roy's thesis ;-).
>>
>> Sanjiva.
>>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Get to your groups with one click. Know instantly when new email
> arrives
> http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
