IP Network Skill

• 最新号：2008-10-10
• 発行周期：週刊
• 読んでる人：1745人
• 創刊日：2001-04-30
• Score!：90点
• コメント数 ： 4
• メルマガID：36790
• バックナンバー：全て公開
• 発行者サイト：あり
• >> 月間ランキング

[ IP Network Skill - No. 0131 - ]

‥‥……━━━━━━ IP Network Skill No. 00000131 ━━━━━━……‥‥

　　┏━┓　
　　┃目┣━┓　　　　　　　　　《IP Network Skill No.131 -CONTENTS-》
╋━┗━┫次┣━━━━━━━━━━━━━━━━━━━━━━━━……‥‥
┃　　　┗━┛　　　　　　　　　 
┃【１】【学習のてびき】：SIPのコネクション確立法
┃【２】【オススメの本】：英語の教科書、好評だったので
┃【３】【コラム】：RFC review RFC3501からRFC3509
┃【４】【本日の試験対策問題】：IMAPとSIP
┃【５】【問題の解答】
╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━……‥‥

　【まえがき】
　19日に2003年の情報処理技術者試験が行われました。
　Webを見ていたら、当日の午前中に、午前試験の解答速報が
　出てました。。。さすがにまだ問題そのものはWeb上に掲載
　されていませんでしたが、発見された方や問題を提供して
　くださる方がいらっしゃれば教えていただけると幸いです。

　[解答速報]午前のみ。
　資格の学校TAC
　http://www.tac-school.co.jp/koza1/sokuhou/joho/joho0310.html
　電算労
　http://www.union-net.or.jp/siken/0310/net.html
　
◎￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣◎
｜　新規購読・購読解除・バックナンバー ⇒ http://www.xai.nu/ipnet　 
｜　　IP Network Skill 掲示板
｜　　⇒　http://www.xai.nu/cgibin/ipnet/bbs.cgi　 
｜　　バックナンバー一覧　　　　　　　　　　　　　　
｜　　⇒　http://xai.nu/ipnet/stack/index.html　
｜　　間違いご指摘
｜　　⇒　ipnet3@xai.nu 
◎＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿◎

┳┯┯┯┯┯━━━━━━━━━━━━━━━━━━━━━━━━━━┯┯┳
┠┼┼┼┴　学習のてびき： SIPのコネクション確立法 　　　　 ┬┼┼┼┨
┻┷┷━━━━━━━━━━━━━━━━━━━━━━━━━━┷┷┷┷┷┻

　SIPでは通信を行う端末をUA（User Agent）と呼び、発信元をUAC（User 
　Agent Client）、着信側をUAS（User Agent Server）と表現します。
　UAは具体的にはSIPプロトコルを話せるIP電話やPCとなります。

　送受信にはHTTPのようなリクエスト、レスポンスが用いられます。主なリク
　エストとしては、通信相手の存在を確認するREGISTER、発呼を行うINVITE、
　確立した呼を終了するBYE、確立前の呼を終了するCANCELなどがあります。

　INVITEはQ.931のSetupメッセージのようなものですね。

　SIPを用いたセッションの確立には、SIP Proxyサーバを用いる場合と、
　Redirectサーバを用いる場合があります。

　SIP Proxyサーバは呼制御情報を中継します。

　[UAC]------------------[SIP Proxy Server]----------------[UAS]

  (1) UAがINVITE要求を送信------->
                              (2)着信先決定------------------->
  <--- Response (返信) ------- 中継 ----- Response (返信) --(3)
　(4) ACKを返す ---------------------------------------------->

  <================== RTPコネクションが確立 ==================>
                        
　RTP (Real-time Transport Protocol) は音声や映像をストリーミング再生
　するときのデータ送信用プロトコルです。

　次に、Redirectサーバを用いた場合です。この場合、中継ではなくて情報
　提供だけサーバから行われます。

　[UAC]------------------[Redirect Server]-----------------[UAS]
                         
  (1) UAがINVITE要求を送信------->
  <----------- 着信先情報を渡す (2)
  (3) もらった情報を元に着信先へINVITE ----------------------->
  <--------------------------------------- 着信先はOKを返す (4)
  (5) ACKを返す ---------------------------------------------->

  <================== RTPコネクションが確立 ==================>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　コ┃ラ┃ム┃【RFC review RFC3501からRFC3509】
　━┛━┛━┛

　RFC350xは今年2003年の3月から4月にかけて発行されたRFCです。
　4月というとジョークRFC？という定例がありますが、これは350x番台にはなく
　てRFC3514になります。

　StatusにPROPOSED STANDARDが多いのが気付きます。
　RFCのステータスにはいろいろあることはすでに紹介済みですが、「標準」と
　呼ばれるインターネットの規格であり世界仕様であるSTANDARD trackには成熟度
　に応じて3種類あります。成熟度の低いものからproposed standard, 
　draft standard, standardの順です。（大文字、小文字は気にしないでください。）

　350x番台はまだできて日が浅いため、現時点ではstandard trackの中でも初期
　段階のproposed standardとなっているのです。

--------------------------------------------------------------------------
3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. M. Crispin.
     March 2003. (Format: TXT=227640 bytes) (Obsoletes RFC2060) (Status:
     PROPOSED STANDARD)
--------------------------------------------------------------------------
　　
　　IMAPのアップデート版です。IMAPはPOPのように、メールサーバからメールを
　　受信するためのプロトコルです。POPの場合、サーバでの保存は一時的で、PC
　　などのクライアントに無条件にダウンロードし、その後サーバ内の情報を削除
　　します。IMAPの場合、メールはサーバ上で管理され、送信者やタイトルなどの
　　ヘッダ情報を見て受信したいメールだけ受信することが出来ます。
　　100ページ以上ある大作です。ExampleのC:はクライアント、S:はサーバを示し
　　ます(RFC3501, 3502, 3503とも)。

--------------------------------------------------------------------------
3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension.
     M. Crispin. March 2003. (Format: TXT=13379 bytes) (Status: PROPOSED
     STANDARD)
--------------------------------------------------------------------------

　　IMAPの拡張コマンドを定義しています。もともとAPPENDというクライアント
　　からサーバへメールデータをアップロードする（送る）コマンドがありまし
　　た。このコマンドでは１つのメールしか送れませんでしたが、これを１つの
　　コマンドで複数アップロードできるようにしたものです。

--------------------------------------------------------------------------
3503 Message Disposition Notification (MDN) profile for Internet
     Message Access Protocol (IMAP). A. Melnikov. March 2003. (Format:
     TXT=16937 bytes) (Status: PROPOSED STANDARD)
--------------------------------------------------------------------------

　　上記２つと同じくIMAP関連のRFCです。メーラー（MUA: Mail User Agent、
　　メールソフト）がメールを受信したことを送信者に伝える開封通知機能（MDN:
　　Message Disposition Notification）に関して、ユーザが別のクライアントや
　　別のメーラーで受信した場合にも正しく制御できるように機能追加したもの。

--------------------------------------------------------------------------
3504 Internet Open Trading Protocol (IOTP) Version 1, Errata. D.
     Eastlake. March 2003. (Format: TXT=8655 bytes) (Status:
     INFORMATIONAL)
--------------------------------------------------------------------------

　　IOTP (Internet Open Trading Protocol) という電子商取引プロトコルが
　　RFC 2801, 2802, 2803にありますが、これの訂正情報です。タイトルにもある
　　ErrataというのはErrorに似てますが、訂正を要する誤りという意味です。

--------------------------------------------------------------------------
3505 Electronic Commerce Modeling Language (ECML): Version 2
     Requirements. D. Eastlake. March 2003. (Format: TXT=13915 bytes)
     (Status: INFORMATIONAL)
--------------------------------------------------------------------------

　　RFC2706, 3106でバージョン１が書かれている、ECMLのバージョン２です。
　　Webサイト経由の電子商取引で使うパラメータ（支払方法、顧客情報など）
　　に関するガイドラインや標準文法を定めています。いくつかの企業が採用
　　しているようです。ただし英語なので、日本のEコマースには向いていない
　　かも。バージョン１から見ないと何を言っているのかわかりません。

--------------------------------------------------------------------------
3506 Requirements and Design for Voucher Trading System (VTS). K.
     Fujimura, D. Eastlake. March 2003. (Format: TXT=30945 bytes) (Status:
     INFORMATIONAL)
--------------------------------------------------------------------------

　　NTTの日本人が著者に名を連ねています。割引クーポンやポイント還元を
　　インターネット上で取引するためのシステム要求。IOTPやXMLで使うそう
　　です。

--------------------------------------------------------------------------
3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa.
     April 2003. (Format: TXT=98772 bytes) (Status: INFORMATIONAL)
--------------------------------------------------------------------------

　　コンテンツデリバリー（Web情報をいかに効率よくユーザへ送るか）系のプ
　　ロトコルです。
　　IETFでRFC3238のOPES (Open Pluggable Edge Services) が出る前にICAPが
　　作られ、知れ渡ったそうで、OPESが現在Standard trackに載せようと作業中
　　ではあるがRFC3238の中には実装方法まで書いていなかったので、このRFCで
　　補足しようとしています。

--------------------------------------------------------------------------
3508 H.323 Uniform Resource Locator (URL) Scheme Registration. O.
     Levin. April 2003. (Format: TXT=10983 bytes) (Status: INFORMATIONAL)
--------------------------------------------------------------------------

　　Webで使うURLはhttp:...で始まりますが、H.323というITU-Tのプロトコルに
　　対するURLもh323:...というものがあるそうです。SIPもURLがアドレス代わり
　　になって、"sip:user@sip.xai.nu"のような形になります。
　　h323も"h323:user@h323.xai.nu"のようなURLになりますが、これを提示した
　　RFCです。

--------------------------------------------------------------------------
3509 Alternative Implementations of OSPF Area Border Routers. A.
     Zinin, A. Lindem, D. Yeung. April 2003. (Format: TXT=24326 bytes)
     (Status: INFORMATIONAL)
--------------------------------------------------------------------------

　　ルーティングプロトコルOSPFのArea Border Router (ABR) について、拡張
　　実装を語っています。通常のABRは常にarea 0に接するはずですが、area 0
　　に接しない、例えばarea 1とarea 2だけに接しているようなABRの振る舞い
　　について代替案を提案しています。


　INFORMATIONALは他の規格（OSIやIEEE、ITU-Tなど）の情報やベンダのデファ
　クトスタンダード（標準ではないがすでに広く知れ渡っている規格）、パラ
　メータなど有用な情報が盛り込まれています。
　あまり意味はないのですが3500くらいから新しいRFCを少しずつ紹介していこ
　うと思います。
　　　
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━≪今週のオススメ本≫━━━━━━━━━━━━━━━━━━━━━━━

――――――――――――――――――――――――
　☆★☆　英語の教科書、好評だったので　★☆★
――――――――――――――――――――――――

　No.129でも紹介しましたが、結構評判が良くて、買ってくださった方も
　多くいらっしゃいます。というわけでもう一度紹介します。

[Entry 1]【Basic Grammar in Use 】――――――――――――――――――
｜初心者向け。英検準２級くらいまでか。見開き2ページで１つの
｜単元となっていて、基本的な文法がきれいにまとまってます。
｜カラーで見やすい。さらにCD付き。
｜⇒ http://www.amazon.co.jp/exec/obidos/ASIN/0521626005/ipnetworkskil-22 
└―・――――――――――――――――――――――――――――――――
[Entry 2]【Grammar in Use Intermediate 】――――――――――――――
｜中級者向け。初級と同じくカラーで見やすい。CD付き。
｜⇒ http://www.amazon.co.jp/exec/obidos/ASIN/052162598X/ipnetworkskil-22 
└―・――――――――――――――――――――――――――――――――

╋━━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━━━━━━━━━━……‥‥
　　　┃本┃日┃の┃試┃験┃対┃策┃問┃題┃　
╋━━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━━━━━━━━━━……‥‥

　〔問題１〕IMAPの特徴として正しいものはどれか。
　　　１．電子メールの送信および受信をするためのプロトコル。
　　　２．電子メールをクライアントに保存させる。
　　　３．フォルダの作成やフラグ管理などメールを管理する機能を持っている。
　　　４．POPよりはSMTPに似たプロトコル。

　〔問題２〕SIPのコネクション確立に関して、正しいものはどれか。
　　　１．プロキシサーバは送信元からINVITE要求を受けるとあて先の情報を
　　　　送信元に送り返す。
　　　２．UAはまずRTPコネクションを確立し、このコネクション上でINVITE
　　　　要求を送る。
　　　３．リダイレクトサーバは送信元からINVITE要求を受けるとあて先へ
　　　　要求を中継する。
　　　４．UAはINVITE要求を送ったあと、ACKを送信してからRTPコネクション
　　　　を確立する。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　解┃答┃と┃解┃説┃
　━┛━┛━┛━┛━┛

　《本日の試験対策問題》
　　（解答１）３
　　（解説１）IMAPは電子メールを受信するプロトコルです。POPも電子メール
　　　をメールサーバから受信するプロトコルですが、POPがサーバからメールを
　　　ダウンロードしてクライアントでメールを管理するのに対し、IMAPは
　　　メールをダウンロードせず、サーバ上でメールを管理します。送信機能は
　　　ないので、SMTPに任せます。

　　（解答２）４
　　（解説２）１．はプロキシサーバではなくリダイレクトサーバの説明になり
　　　ます。２．ですがRTPコネクションはINVITE要求が通ってから確立されます。
　　　３．はりダイレクトサーバではなくプロキシサーバの説明になります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


◆◆◆◆◆◆　┃ あとがき ┃　◆◆◆◆◆◆

　前回、RIPの問題を出しました。
　解説にRIPはサブネットの概念はない、と書きまして、読者より
　RIPv2にはあるじゃないか？！というご指摘を頂きました。
　たしかにおっしゃるとおりです。
　ですが、通常RIPと書くとRIPv1のことを示す場合が多いです。
　「サポートプロトコル：RIP/RIPv2」のように書かれているのは、
　RIPv1とRIPv2をサポートしているよ、ということでRIP＝RIPv1
　です。
　言い訳がましいですが、実際そのような傾向もあるので気にして
　みてください。

………………………………………………………　　　　　　　　　　 
　IP Network Skill vol.000131 　10/24/03
　発行者：adzuki　http://www.xai.nu/ipnet  
……………………………… ipnet3@xai.nu ……　　　　　　　　　　 

のんびりやろう！情報処理試験！　〜１問１問コツコツと〜

ソフトウェア開発＆基本情報技術者試験対策を中心に初級シスアドや高度区分まで幅広く対応。流行のIT用語の解説も行っているので，パソコンについて勉強した...

Office & VBA パーフェクトマスター

Excel・Access・Word等の今さら聞けない「疑問」、今すぐ知りたい「困った」、たちまち解決！のmoug（モーグ）がお送りする、関数初心者か...

ネットワークのおべんきょしませんか？

TCP/IPってなに？LANって？ルータって何をするの？というネットワークに関することをわかりやすく解説します。情報処理の試験を受ける方にもぴったり...

全部フリーソフト！！

ネット上にはこんなに便利なフリーソフトがいっぱい。お金なんか使わなくても、あると絶対にお得で楽しいソフトを1つずつご紹介します。

ＩＰネットワーク考

インターネットのネットワークＳＥの実務者が、IPネットワークにまつわる話題、問題、技術について実務者ならではの視点から解説します。ネットワーク、TC...

この記事へのコメント

■三菱東京UFJ銀行系 モビット■

【１】ネットで自動審査・来店不要！
【２】限度額300万円
【３】年利9.8％-18.0％（実質年率）

急な出費にモビット！