RE: [service-orientated-architecture] Re: transfer vs. transportprotocols

[Gervas Douglas]

I am going to intervene here with an edited dialogue which has just taken place between two colleagues and friends of many years ago in response to my request for enlightenment on the matter:   Actually, SMTP is carried over TCP port 25 (as Guy correctly points out) and that makes it a client (ie consumer) of Transport layer services.  Each protocol layer has SAP (Service Access Point) IDs which it uses to address its clients, thereby allowing multiple different users.  So, strictly speaking, SMTP is a TCP client.  However, as Guy points out, everyone (including the switch UIs) refers to them as transport layer protocols, which is not strictly correct.  But everyone does it, and everyone will understand it if you say it that way. Lynton Guy wrote: This whole thing starts getting very hazy in the IP world. TCP, strictly speaking, is the connection-oriented Transport protocol and UDP the connectionless Transport protocol; i.e. Layer 4. Logically, SMTP and the like sit above this layer, but if one were to look at Layer 4 switches, they regard SMTP, etc as layer 4 protocols and switch it accordingly. So where to from here? SMTP is Port 25 of TCP, therefore it does appear to be a transport layer protocol, but is it? As Lynton states, IP effectively blurs the upper layers, but I would agree that, strictly speaking OSI terminology, SMTP is a Session-layer protocol because it is used between MTA's to send email. POP is at the application level because the application uses it to retrieve mail from the MTA. Regards Guy Subject: Re: Protocol Stacks Actually, if we're talking about the OSI model, they mostly live at the session layer of the OSI model.  But in truth, no-one pays much attention to the upper layers these days, so everything in layers 5-7 are typically grouped into "Application".  That's closer to the TCP/IP model, which talks about layers up to (and including) transfer and everything above that is "application"  However, also in TCP/IP convention, these Transfer Services have combined parts of layers 5-7 into the "Application layer", I would reasonably say that they can be considered as Application, even if there are other parts of "Application" needed for full interpretation of the content (eg you need a presentation layer to display the contents of an email message which is being transferred by SMTP) So to answer the question, in the TCP/IP model, all of these transfer items are part of the "application layer" and yes, I also agree that they all use a transport layer service (there's no option here, by the way, all these kind of apps need some kind of transport service, the only difference is how complex (and therefore expensive) a transport service they need) Just as a historical comment: I'm still of the opinion that OSI did a better job than TCP/IP on defining the lower layers (ie layers 1-4) but they got a bit too carried away with the upper layers.  The net result was that the weight of the upper layers; definition made everyone "knows" that the OSI model was too heavy and not practical.  Yes, I know this battle is all over and done with, but its an interesting lesson in "too much, too complicated and too soon" Ultimately, this looks as though it’s a debate about specific terminology, and since many of the terms are in frequent colloquial use, (and therefore less precise than they should be) as long as the terms are well defined, everyone should be able to agree.  {What a hopeless optimist I am} Lynton   Gervas -----Original Message----- From: service-orientated-architecture@yahoogroups.com [mailto:service-orientated-architecture@yahoogroups.com] On Behalf Of Sanjiva Weerawarana Sent: 15 May 2006 05:12 To: service-orientated-architecture@yahoogroups.com Subject: Re: [service-orientated-architecture] Re: transfer vs. transportprotocols   On Sun, 2006-05-14 at 19:30 +0200, Stefan Tilkov wrote: > I found this piece of text in RFC 821 (SMTP), edited by Jon Postel: > >    The objective of Simple Mail Transfer Protocol (SMTP) is to transfer >     mail reliably and efficiently.   The (second) use of the word "transfer" above is just proper English!   >     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    So transport here is just a transport as we refer to it now: a way to move bytes.   I'm sorry but I see no mention or definition here of a difference between a transfer protocol and a transport protocol.   > 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.   I'm not arguing about how long it has been in use at all; maybe it has indeed been a concept that's been clear to many for a long time. In that case it should be easy to craft a definition!   Sanjiva.             ------------------------ Yahoo! Groups Sponsor --------------------~--> You can search right from your browser? It's easy and it's free.  See how. http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~->     Yahoo! Groups Links   <*> To visit your group on the web, go to:     http://groups.yahoo.com/group/service-orientated-architecture/   <*> To unsubscribe from this group, send an email to:     [EMAIL PROTECTED]   <*> Your use of Yahoo! Groups is subject to:     http://docs.yahoo.com/info/terms/     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.