e elim- inated by incorporating its functions into the layer above or the layer below, thus simplifying the OSI model. Whatever, the bottom line is that it does perform a set of critical functions that cannot be ignored. First of all, the Session Layer ensures that a logical relationship is cre- ated between the transmitting and receiving applications. It guarantees, for example, that our PC user in Madrid receives his or her mail and only his or her mail from the mainframe, which is undoubtedly hosting large numbers of other e-mail users. This requires the creation and assign- ment of a logical session identifier. Many years ago, I recall an instance when I logged into my e-mail account and found, to my horror, that I was actually logged into my vice president's account. Needless to say, I back-pedaled out of there as fast as I could. Today I know that this occurred because of an execution glitch in the Session Layer. Layer five also shares responsibility for security with the Presentation Layer. You may have noticed that when you log in to your e-mail appli- cation, the first thing the system does is ask for a login ID, which you dutifully enter. The ID appears in the appropriate field on the screen. When the system asks for your password, however, the password does not appear on the screen-the field remains blank or is filled with stars, shown graphically in Figure 2-24. This is because the Session Layer knows that the information should not be displayed. When it receives the correct login ID, it sends a command to the terminal (your PC) asking you to enter your password. It then immediately sends a second message to the terminal telling it to turn off "local echo" so that your keystrokes are not echoed back onto the screen. As soon as the password has been transmitted, the Session Layer issues a command to turn local echo back on again, allowing you to once again see what you type. Enter Login Figure 2-24 (Login received) Session Layer Enter Password turns off echo Turn off local echo to protect user. Turn on