ski2@milton.u.washington.edu (Chris Kacoroski) (10/25/90)
Hi,
I have two references on the OSI 7 layer model that disagree on what
the model does in the applications layer. The analogy is that of
sending a letter from the US to Germany. Reference 1 from 1987 states
that the OSI model will not only send the letter but will also
translate its contents from English to German. Reference 2 from 1989
states that the OSI model will only send the letter and not affect the
contents at all. The method in reference 2 is akin to the current
postal system. My question is: Which reference is correct?
Also, how does the MAP/TOP effort deal with the above problem. Does
MMS actually modify the contents of the letter or only guarantee the
arrival of the letter at a destination?
Thank you for you help
--
Chris "When we try to pick out anything by itself
'ski-' we find it connected to the entire universe"
Kacoroski John Muir
ski2@u.washington.edubobk@boulder.Colorado.EDU (Robert Kinne) (10/29/90)
In article <9905@milton.u.washington.edu> ski2@milton.u.washington.edu (Chris Kacoroski) writes: >Hi, > >I have two references on the OSI 7 layer model that disagree on what >the model does in the applications layer. The analogy is that of >sending a letter from the US to Germany. Reference 1 from 1987 states >that the OSI model will not only send the letter but will also >translate its contents from English to German. Reference 2 from 1989 >states that the OSI model will only send the letter and not affect the >contents at all. The method in reference 2 is akin to the current >postal system. My question is: Which reference is correct? First, understand that the OSI model is exactly that; a model that breaks the communication process into seven defined layers, with layer interfaces and some concept of peer-to-peer level exchange. So the OSI model doesn't deal with the kind of issue you raise, but specifications of the layers and interfaces do. Second, the analogy of a 7-layer communication to a letter in the post is a loose one, and shouldn't be taken too literally. Third, the issue you raise is not an application layer question, but properly a presentation (layer 6) question. The purpose of the presentation layer (simplified, of course) is to place the communication into a form (code, language, syntax, whatever) that will be understood by the application layer. In the analogy of a letter (keeping the second point in mind), if you speak only German, the letter would be presented to you in German translation, since your presentation layer would 'know' that you don't understand English. > >Also, how does the MAP/TOP effort deal with the above problem. Does MAP/TOP hasn't evoloved to deal in any detail with presentation layer as yet.
solomon@CS.WISC.EDU (Marvin Solomon) (10/29/90)
> Third, the issue you raise is not an application layer question, > but properly a presentation (layer 6) question. The purpose of > the presentation layer (simplified, of course) is to place the > communication into a form (code, language, syntax, whatever) that > will be understood by the application layer. In the analogy of a > letter (keeping the second point in mind), if you speak only German, > the letter would be presented to you in German translation, since > your presentation layer would 'know' that you don't understand > English. I have to take mild exception with this point. This explanation is consistent general descriptions of the 7-layer model, but not with the ISO/CCITT presentation service/protocol as actually defined ("Presentation", for short). All Presentation actually provides is facilities to negotiate a set of "presentation contexts", which are simply OBJECT IDENTIFIERS. To continue the analogy, you have a standard way of writing "Language: German" on the envelope, together with the agreement that you will write "German", not "Deutsch", "Allemand", or whatever. When you receive such a letter, you have the option of reading it, handing to your German/English interpreter, or telling the postman, "Sorry, no one speaks German here". (Caveat: This is a loose analogy: In actuality, X.400 is an application (layer 7) protocol. What I'm calling the "envelope" here is not the P1 envelope of MHS. Also note that X.400 (at least the 1984 version) doesn't use ISO Presentation!). Since the ISO stack is [currently, mostly] connection-oriented, perhaps a better analogy is the phone system. The operator, while placing the call, says "Est-ce que quelque on qui parle Allemand?" Everybody is required to understand at least this much French. When you receive such a call, you have the option of refusing it or accepting it, perhaps handing the phone to an interpreter. The operator might say that the call will contain German, English, French, and Swahili (this feature is called "multiple contexts".) You can say that you understand French and English but not German or Swahili. The caller gets your response and has the option of cancelling the call or restricting the converstation to languages you understand. The Presentation spec is silent on how you're supposed to tell which parts of the conversation are in French and which are in German. However, as a part of the initial negotiation, the languages are assigned integer id's (say French=1, English=17), and if you like, you can start each sentence with an indication of language: 1: La plume de ma tante est sur la table. 17: I say old chap, typically nasty weather. ASN.1 provides the EXTERNAL data type for such purposes. It's up to each application protocol to use it. Now let me ask a question: The same sort of thing goes on "inside" the application layer with ACSE. Can anybody explain to me why we need both Presentation and ACSE? I've always assumed that when the 7-layer model was being defined, the upper layers were only poorly understood. When people got around to acually defining them, they discovered that they needed an eighth layer, but since the number 7 has such mystical significance, they refused to call it a layer. Or perhaps, they discovered that the lower layers were lacking functionality, so they stuck things like association control (a transport issue?), transactions (a session issue!), and application contexts (a presentation issue??) in ACSE as a sort of "patch". Am I being unfair? Would anyone from the standards community care to comment?
mckenzie@bbn.com (Alex McKenzie) (10/30/90)
Marvin, You ask why the Presentation Layer functionality is also included in ACSE. I admit that I haven't read the ACSE documentation recently, but my guess is that the functionality isn't also included in ACSE, just the access to that funcionality. The reference model says that all communication functionality is made visible to a user application program through the "top" of the 7-layer stack. This is supposed to make it easier to redesign the way communication functions are actually provided (freedom to ISO to redesign the layers) and make user application programs slightly more portable (a single interface point). But that means that if a function is provided in the Session Layer (e.g. checkpoints) that the user application program needs access to, then the Presentation Service has to offer an identical* function to the Presentation User, and then the ACSE has to offer an identical function to its user. These services are known in the ISO committees as "pass through" services, because the user's service request is "passed through" without change as a service request to the next lower layer. Regards, Alex McKenzie * Of course the service provided by an upper layer need not be identical to the service provided by a lower layer, and not all services are. But in some cases the upper layers have nothing to add - the service offering might as well be identical.