セッション層 (Session Layer)、プレゼンテーション層 (Presentation
Layer)、アプリケーション層 (Application Layer) について
UNIX 系での TCP/IP 、言い換えるとインターネットの世界では、これら上位
層は明確に分けることなく（一緒くたに？）扱われることが多いです。
そして、 意味内容 (semantics) をあたえてるのはここの階層です。
つまり、この層は人間にとっても理解が容易なプロトコルとなっていること
が多いです。具体例は、以下のようなものです。
-
WWW ( Hyper-Text Transfer Protocol (http) の上での HTML )
-
電子メール ( メールを送る=smtp での envelope/header/body
/ メールを受け取る=pop3/imap4 )
これらについては、別途個別に説明します。
具体的プロトコルの説明前の重要事項
RFC
Internet 上の約束事（規則といってもいいが、強制する組織は無いのは前述
の通り）は、RFC (Request For Comments) という形でまとめられて、
公開されています （原語は英語）
。たとえば、電子メールのプロトコルと型式に関しては、比較的最近（と
いっても2008 年）更新された
RFC5321 と RFC5322
で規定されています。
その前にあったメールに関する RFC としては821/822, 2821/2822 がありまし
たが、これらは5321/5322 に上書きされた形で 無効 (obsolete) と
なっています。このように、RFC は旧来のものを改善したものが出てきたとき
に、バージョン管理ではなく新しい番号をふって古いのを無効にする、という
習慣があります。
ちなみに一部は日本語に翻訳されています。それらについては、例えば
JPNIC の RFC のページ などを参照してください。
単なるユーザならいざしらず、将来的に広い意味で「インターネット」でご飯
を食べたい（職業としたい）人は、RFC をきちんと読めるようになることは必
須です。こういう基本的なことを疎かにしていると、例えば
RFC を
読まなかった携帯キャリアの罪（元リンクが切れてるので archive.org)
のようなおろかなことをしでかしてしまいます。個人的にも実際に不具合があっ
たこともあり、正直、非常に迷惑したことがありました。賢者の皆さんは
- @ の直前に「. (dot)」 がつくとか、
- @ の前の部分のどこかで「.」が２つ以上連続するとか、
(例: a..b.@example.com)
のアドレスは設定しないようにしましょう（！！）。現実に、gmail も当初は
送受信出来ませんでしたし、Windows Server 上の Exchange というソフトウェ
アでメールサービスを提供しているドメインとは、上で指摘したアドレスでは
メールのやりとりは出来ない（Microsoft が RFC に厳格にのっとっている）よ
うです。例えばもし就職活動していて、先方の会社のメールシステムが
Windows Server を使っていたりすると…連絡がつかないわけですから、採用活
動どうこう以前の問題です。
さらに、他国語のコードなど、さらに興味ある人は
http://www.d2.dion.ne.jp/~imady/charset/index.html 等を参照してく
ださい。
講義用スタイル
印刷用スタイル
（開いてから、ページを再度更新してください）