No. 54 - 情報規格調査会

No. 54
2002 年 6 月
目
次
標準活動トピックス：
Java の標準化について ............................................................. 2
黒川利明（(株)CSK）
最近の国際会議から：
SC 6（Telecommunications and Information Exchange Between Systems）総会報告 ........ 5
田中一寿（(株)日立製作所）
SC 29（Coding of Audio, Picture, Multimedia and Hypermedia Information）総会報告 ... 6
金子格（早稲田大学）
SC 36 （Information Technology for Learning, Education, and Training）総会報告 ..... 7
仲林清（(株)エヌ・ティ・ティエックス）
解説：ディレクトリの概要と標準化の動向 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9
山口純一（日本アイ・ビー・エム(株)）
平成 13 年度情報処理学会「業績賞」表彰の紹介...................................16
2002 年 6 月以降国際会議開催スケジュール .......................................16
声のページ：
Lisp から始めた標準化活動 ......................................................... 17
黒川利明（(株)CSK）
符号化文字基本集合（BUCS）について ............................................... 17
松岡榮志（東京学芸大学）
ITSCJ の広場 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙18
編集後記 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙18
＜標準活動トピックス＞
Java の標準化について
SC 22 専門委員会
委員黒川利明（(株)CSK）
事務局からやぶから棒に依頼されて，気軽に引き受
けたのだが，どうせのことなら，多少とも刺激的な内
容にしたいと思うので，次のような問いを拙文で発す
ることにしたい．
ンで開かれた総会で，Java 及びそれに関連した国際
標準を検討する Study Group が置かれることが決まっ
た．その時の，Resolution の文章は，下のようなも
のだった．
・国家が関与する標準は，必要だろうか？私企業な
り，私団体が好きなように規格を発行したのでは
まずいのだろうか？
・翻訳 JIS は，必要だろうか？英語の IS をそのまま
JIS のテキストにしてはまずいのだろうか？
・ SC 22 initiates a study period on Java-related
standardization (according to JTC 1 Directives
6.2.3) to investigate potential approaches for
Java-related standards and establishes a Java
Study Group (JSG) to coordinate this study and
report to the next SC 22 Plenary (if not sooner).
In particular, this Java Study Group is to
consider appropriate new work item proposals
(NPs).
・ SC 22 appoints Bob Mathis (US) as Convener of
this Java Study Group. All participants in the
London Plenary are invited and encouraged to
participate and National Bodies are encouraged
to nominate other participants. The Convener is
empowered to involve other organizations and
individuals
that
might
contribute
to
understanding and resolving issues. The work of
this Java Study Group will be conducted via
e-mail and other Internet mechanisms, in as much
as possible.
なお，以下の文章では，個人的な判断・意見を述べ
させていただく．筆者の雇用者である企業ないしは筆
者がたまたま所属している情報規格調査会の専門委
員会や WG の意見ではないことを了承願いたい．
さて，ともかく Java の話に入る．プログラミング
言語としての Java については，すでに多くの文献が
あるはずなので省略する．なお，青山学院大学の井田
昌之先生が標準化の絡みを，「IT 領域における国際
標準策定プロセスに関する一考察」，井田昌之，青山
国際政経論集 51 号，pp357-378（2000-09）に書かれ
ている．拙文とあわせて読まれると良いのではなかろ
うか．
Java が広まってきたと認識されたかなり早い時期
に標準化の議論も始まっている．1996 年 5 月にサンフ
ランシスコで開かれた JavaOne が確か最初の JavaOne
だと思うが，これに参加したときにもフロアや会場の
コーナで，「この 2，3 年で Java が国際規格にならな
きゃ」という声が聞かれたことを覚えている．
この JavaOne の多言語処理の会議で，SMI（Sun
Microsystems Inc.）の人間を捕まえて，「Java の国
際化には専門家の協力が必要だけれど，どうする
の？」と聞いたら，返ってきた答えが，
1) Unicode を使っているから国際化の問題はない，
2) 日本のパートナー企業が国際化をやってくれる
から大丈夫，
ということで，これでは，「問題がぜんぜんわかって
ないのじゃないか」と感じたのも昨日のことのようだ．
一方，プログラミング言語（及びその環境）の標準
化を進めている SC 22 では，1996 年の 9 月にロンド
Mathis さんとは Lisp の WG を立ち上げるときに，
ご一緒したのだが，この総会では，Ada のコンビーナ
をやめられたところで，次から次へとテーマをよく見
つけてくる人だと感心した．
Mathis さん本人に確かめたかどうかは忘れたが，
SMI 側からそれなりの働きかけがあったのだと聞い
たように思う．ただ，それ以上に，インターネットが
これだけ急速に広まっており，JTC 1 がそれに対して
一歩遅れているのではないかという危機感が出席者
の間に流れていたのが印象的だった．
さて，Java Study Group（JSG）は，1997 年 1 月 7
日にカリフォルニア州 Cupertino の JavaSoft の会議室
で最初の会合を開いている．この場で，SMI の Jim
Mitchell が，国際標準化を前向きに考えているが，C++
2
のように長い年月を費やされては困る，と発言した．
今から思えば，これが，Java 標準化ドタバタ劇の幕
開きだった．
SMI は，この春に JTC 1 に対して，PAS Submitter
の資格を申請した．これは，物議をかもした．これま
では，P メンバと A リエゾンだけが Fast-track を提
案できた．SMI は，自分の財産である Java を国際標
準にするのに一番近くて確実な道筋として， PAS
Submitter となることを選んだ．
同じ年の 6 月 30 日には，ロンドンの BSI で 2 回目
の JSG が開かれ，話題は，SMI の PAS Submitter 申請
が通るかどうか，通ったとして，JSG がどういう役割
を果たすのかということに終始した．
1998 年の年明けには，投票では反対の方が多かっ
た SMI の PAS Submitter 申請が JTC 1 とのネゴで承認
され，国内でも対応する Java Study Group を SC 22
専門委員会の下に設けることが承認された．主査を黒
川が引き受けることになった．
しかし，6 月までにはと期待されていた SMI からの
Java 提案がなかなか出てこない．Mathis さんとも相
談し，8 月に Denmark で開かれた SC 22 総会では，次
回の JSG の会議を日本がホストしたいと提案し，歓迎
された．
10 月に機械振興会館で JSG の 3 回目を開いたのだ
が，結果的にはこれが最後の会議になってしまった．
この会議では，日本の JSG のメンバに頑張ってもらっ
て，特に，日本語の処理に関して，従来の Java の規
定ではどんなに問題があるかを掘り下げて発表して
もらった．
しかしながら，1998 年の年末には，SMI が PAS 提出
をやめるらしいとの噂が広まっていた．1999 年には，
ECMA への提出に変更するらしいという情報が流れて
きた．SMI の PAS 資格申請の際には，標準にかかわる
複数の人から，「私企業が国際規格を提案するのは，
おかしいのではないか」という意見が私的な場でも出
され，そのたびに，世の中も変わっているのだし，Java
のもつ重要性を考えれば，いいではないですか，と主
張してきたので，正直言って，この SMI の態度変更は
不愉快だった．
その後の，公式発表は，JTC 1 が PAS に関するコピー
ライトや知的所有権に関する規定を変更したため，SMI
は，方針を変更したことになっていたが，もっと他の理
由があったのではないかと個人的には思っている．
さらに面倒なことには，SMI が，正式には，「PAS
提案を行わないから，PAS 提案資格は要らない」と JTC
1 に申し入れなかったらしいのだ．したがって，後々
まで，JTC 1 の関係者は，SMI は Java を提案しないと
は正式には言っていない．提出が遅れているだけでは
ないか，という立場をとっていた．
1999 年 5 月 6 日には，SMI が，Java の標準化を JTC
1 ではなく ECMA で行なうと正式に発表した．
そこで，国内の Java Study Group としては，この
ECMA への提出と，JTC 1 への PAS として Java の標準
案が出てきそうにないという状況に対してどう応じ
るかが問題となった．
Java Study Group の設立の 1998 年 2 月に出した申
請書には，「Sun Microsystems Inc.が PAS サブミッ
タとして承認され， Java Virtual Machine ， Java
Language，Java platform APIs などの Java 技術の IS
規格化作業が開始されます．これらの技術は国際的に
も SC 22 の担当と考えられ，SC 22 Java Study Group
が対応しており，SC 22 内に Java 対応の WG が設立さ
れる見込みです．」という理由が掲げてあった．厳密
に言えば，WG が設立される見込みがなくなったのだ
から，Java Study Group は解散すべきだということ
になる．
しかし，Java Study Group 内での議論では，ECMA
経由で曲がりなりにも Java が標準化されるのなら，
その標準案作成作業に積極的に関わる方がよいとの
結論に達した．これは，10 月の JSG 会議で日本から
指摘したような，現在の Java が抱えるさまざまの問
題を解決するには，正式に日本からの指摘ならびに修
正提案が取り込まれるべきだという，名を捨てて実を
取るという考えによるものだった．
6 月 24 日の京都で開かれた ECMA の General
Assembly Meeting で，SMI は正式に ECMA に Java の標
準化を提案し，当然ながら，承認され，TC 41 という
部会が作られることになった．善後策を練るために，
6 月 29 日には，情報規格調査会の ECMA のメンバ（日
本の大手メーカのほとんどが実は ECMA のメンバであ
ることをこの時教わった）と Java Study Group のメン
バ，さらに，国内の SC 22 の有志とで会合を開き，日
本としてどうするのが賢明かという話し合いを持った．
結局，ECMA のメンバである日本の会社は，独自に
この TC 41 に参加するが，それとは別に，日本の Java
Study Group も ECMA の Java 標準策定作業に参加する
のがよかろうということになった．
JTC 1 傘下のグループが，PAS としての標準案が提
出される前に，ECMA 内の活動に参加するのは，かな
り異例のことだが，Java の国際化に関して，われわ
れのグループ以上に知識があり，きちんとした提言の
できるところがあるはずがないとの自信もあったの
で，直接，ECMA に対して，参加したいという電子メ
ールを送ることになった．
同時に，ECMA の TC 41 に対して，日本からの提言
をまとめ，最悪の場合，参加が認められなくても，日
本からの提言が日本の ECMA メンバによって取り上げ
られ，会議で議論される手はずを整えた．
3
9 月には，TC 41 の最初の会議が，カリフォルニア
Menlo Park の SMI で，10 月 25，26 日に開かれるとい
う情報が入り，相前後して，ECMA の Jan W. van den
Beld から，日本の Java Study Group からのメンバを
受け入れるとの回答が来た．我々の立場は，リエゾン
ということで，大きな意味では，SC 22 の Java Study
Group の委員長である Bob Mathis と同様に JTC 1 と
しての参加だが，実質的には，日本の専門家という立
場での参加であった．
日本からは，Java Study Group から，風間，黒川，
日立から山東，富士通から西村がこの会議に参加した．
日本のサン・マイクロシステムズ(株)からは，西田憲
正さんが参加していた．
1 日目は，自由討論に近い感じで，風間と黒川がそ
れぞれ日本からの問題提起と提言をした．2 日目は，
実際どう進めていくかの議論で，かなり，SMI の意向
を汲んだ形で，ともかく Java の標準化を進めようと
いうことになった．
最後に，SMI からたたき台としての Java の標準案
の CD-ROM が配られることになっていたのだったが，
ここで，とんでもない番狂わせが生じた．「本社の法
務からストップがかかったので，今日は配布できな
い」という報告である．後で，郵送されるのかという
質問に対しても，「どうなるかは法務の指示によるの
で，今は分からない」という回答しかない．SMI から
の SC 22 委員である Roger Martin がうなだれて頭を
抱えていたのを思いだす．
外資系に勤務していた経験から，米国企業において
法務部がどれほど重要な位置を占めているかは良く
分かっていたから，「法務のストップ」が事実上の中
止命令であることは了解できたのだが，分からないの
は，「なぜ，今頃」だった．本来，このような外部と
関わる事柄は，事前に法務部と打ち合わせするはずで，
ECMA の会議が始まる前に，あらゆる検討が済まされ
ているはずだった．
結果的に，SMI は，ECMA に対しても，Java の標準
案を提出しなかった．TC 41 としての善後策は，2000
年 1 月 25 日∼28 日に，IBM 社の Raleigh での会議で
議論されることになった．このときは， North
Carolina 地方に 40 年ぶりとか言う大雪が降り，
Raleigh の飛行場も周辺の高速道路も閉鎖され，参加
予定者が参加できないという大変な事態になった．
会議そのものは，IBM の Raleigh の施設も閉鎖のた
め，27 日にマリオットホテルで一日だけ開催して終
わった．SMI からは標準案が出せないので，他の形で
Java の言語仕様だけでも提出し，SMI もその会議に加
わる形で，Java の実質的な標準を作れないかという
のが，一つの可能性だったが，「Java」という名前の
問題と，実際に，SMI が Java の改訂作業などを進め
るのとどう同期をとるのかなどの問題が解決できず，
ECMA も結局は Java の作業をあきらめてしまった．
SMI は，Java 技術は SMI 主導で決めるとして，Java
Community Process を定義し，この枠の中で Java を
「標準的」なものとすることに決めた．
以上が，私が個人的に関わった，Java の標準化の
概要である．そこで，最初の問題に戻ろう．
・国家が関与する標準は，必要だろうか？私企業な
り，私団体が好きなように規格を発行したのでは
まずいのだろうか？
「私企業なり，私団体が好きなように規格を発行す
る」問題点は，規格のユーザが納得しないうちに，規
格を変更される危険があることに尽きる．国家にして
も，国民の納得を得ないで，好き勝手なことをする危
険性がないわけではないことを，少なくとも，日本国
民は歴史的に学んできたのだが，現時点では，私企業
よりは，信頼できるということになろう．
ただし，私個人は，無条件に国家なり，あるいは，
国際的な組織なりを信頼するのは，おかしいと思って
いる．競争原理をどう導入するかを考えなければなら
ない．
・翻訳 JIS は，必要だろうか？英語の IS をそのまま
JIS のテキストにしてはまずいのだろうか？
これは，ここまでに述べた Java の標準化の話では
表に出ていない，日本規格協会での Java 言語仕様の
翻訳作業（JIS TR X 0005）に関わる話である．もち
ろん，翻訳 JIS に携わるすべての人が，一度は，胸に
抱いた疑問であろう．
国家とか，国民としての面子や誇りを別にすれば，
JIS の内容が英語であっても構わないのではないか，
翻訳のための膨大な労力をもっと他の作業に割いた
ほうが，日本国家国民にとっても良いのではないかと
いう問いかけである．
翻訳作業の多くで，原文の粗悪な英語に悩まされた
体験から言えば，翻訳作業を原文の英語の洗練作業に
割くことができたら，その方が，世界中の人にとって
有意義な作業になると個人的には考えている．
Java の標準化について，個人的な思い出を書き連
ね，余計な問いかけまで発してしまった．すでに，締
め切りの期日も過ぎており，ここで拙文を終えること
にしたい．しかし，今でもまだ，Java のきちんとし
た国際標準がまともな団体の手で行われることを願
わずにはいられない.
4
＜最近の国際会議から＞
■ SC 6 （ Telecommunications and Information
Exchange Between Systems／通信とシステムの間の情
報交換）総会報告
SC 6/WG 6 小委員会
幹事田中一寿（(株)日立製作所）
1. 開催場所：モントルー（スイス）
2. 開催期間： 2002-03-15
3. 参加国数／出席者数： 5 ヵ国 4 団体／21 名（各
WGs 会議を含む）
議長（Joon-Nyun Kim，韓）
セクレタリ（Jooran Lee，韓）
チェコ(1)，韓(3)，スイス(1)，英(7)，日(1:田中一
寿)，ITU-T(1)，ECMA(3)，ETSI(1)，ISO/ITTF(1)
4. 議事内容
4.1 SC 6 Business Plan の見直しについて
各 NB に対し 6 月 30 日迄のコメント要請を行うこと
を決議．結果は JTC 1 へ検討案件として送付される（決
議 6.4，SC 6 N 12182）．
4.2 SC 6 Programme of Work の見直しについて
各 NB に対し 3 ヵ月のコメント要請を行うことを決
議．また本会議以降，新しい Project 番号を使用する
ことを決議（決議 6.5，SC 6 N 12180）．
4.3 WG 6（私設サービス統合網）の廃止について
各 NB に対し WG 6 廃止の決議について SC 6 レベル
でのコメント要請とすることを決議（決議 6.7，SC 6
N 12122）．また SC 6 議長より各 NB に対し Future Work
Items について SC 6 へ提案するよう recommendation
があった．
4.4 その他
(1) WG 1（物理層およびデータリンク層）関連
SC 25/WG 1（Home Networking）との Joint Work
について，HoD/C 会議にて SC 25/WG 1 Boston 会議の
報告があった．
(2) WG 6（私設サービス統合網）関連
プラハ会議にて提起された
「WG 6 のあり方（Source:
ECMA）」「Future Work Item for WG 6（Source:日本）」
について議論．WG 6 コンビーナの明確な意思（WGs
の継続）が無いこと，且つ実際に on-going な Project
が無く，近年の WG 6 への Input は主に ECMA から行わ
れている，という事実を踏まえ，WG 6 の事実上の解
散を決議し，全ての WG 6 関連 Project を SC 6 へ移管
することとなった．
本決議を踏まえ，SC 6 議長から各 NB に対し，上記
（5.4 項）コメント要請時に SC 6 に対し Future Work
Item 等あれば SC 6 へ提案するように要請があった．
また ECMA より同様に New Work Item Proposal につい
ては ECMA も NB 合意の場を提供するとの発言があった．
(3) WG 7（ネットワーク層およびトランスポート層，
ASN.1，ディレクトリ並びに MHS）関連
韓国提案の 2 案件（RTM: Relayed Transport for
Multicast（SC 6 N 12170），GMP: Group Management
Protocol（SC 6 N 12171））について NP 投票にかけ
ることを決議（決議 6.7.4）．
SC 6/WG 7 内の MHS グループを廃止することを決議
した（決議 6.7.28）．
5. 今後の開催予定
2003-02
ロンドン（英）
2003-11
済州島（韓）
6. 今後の日本の対応
新規案件がほとんどなくなってきている現状と本
会議での審議状況とを踏まえ，SC 6 Business Plan
及び Programme of Work に対するコメント，WG 6 解
散に対する対処について，早急に議論し国内の意見を
とりまとめる予定である．
5
■ SC 29（Coding of Audio, Picture, Multimedia and
Hypermedia Information／音声，画像，マルチメディ
ア，ハイパーメディア情報符号化）総会報告
SC 29 専門委員会
委員金子格（早稲田大学）
1. 開催場所：ジェノヴァ（伊）
2. 開催期間： 2002-03-25/27
3. 参加国/参加者数： 11 ヵ国 1 団体／18 名
議長（渡辺裕，日）
セクレタリ（小倉由紀子，日）
ベルギー(1)，加(1)，フィンランド(1)，仏(2)，独
(1)，伊(2)，日(2: 金子格，石井克己(キヤノン))，
スウェーデン(1)，スイス(1)，英(2)，米(2)
ITU-T(1)
4. 議事内容
4.1 進捗状況
SC 29 の作業項目に関し，IS/AMD/COR 出版段階 9
件，FDIS/FDAM 段階 14 件，FCD/FPDAM 段階 9 件，
CD/PDAM/PDTR 段階 13 件を次段階に進めることを承認
した．
4.2 Program of Work の変更
SC 29 の作業項目の修正に関し，改版 2 件，分割 2
件，微修正 5 件，タイトル変更 1 件を承認した．
4.3 プロジェクトエディタ
今回承認された日本 NB 在籍エディタは以下の通り
である．
・ 15444-3/AMD 3 福原隆浩（ソニー）
・ 14496-1/AMD 3 クレイグ・A・シュルツ（アクセ
スチケットシステムズ）
・ 15938-5/AMD 1 橋田浩一（産総研）
・ 15938-8
柴田賀昭（ソニー）
・ 21000-3
阪本秀樹（NTT）
4.4 ITU-T との協調（WG 1）
ITU-T SG 16 より，共通テキストとして開発された
JPEG 2000（ISO/IEC 15444）パート 1-5 のうち，パート
3 をキャンセルする提案があった．しかし，パート 3 は
すでに出版段階にあり，テレコミュニケ−ション技術上
も重要パートであるため，共通テキストとすることにつ
いて ITU-T SG 16 に再考を求めることになった．
4.5 ITU-T との協調（WG 11）
次世代ビデオ符号化技術の標準化のため，ITU-T SG
16 VCEG（Video Coding Experts Group）と Joint Video
Team を設立し，H.26L をベースに共同開発を行うこ
ととなった．
4.6 ISO/IEC 14496-10 の投票期間の短縮
Joint Video Team で協調開発するプロジェクトは
AVC （ Advanced Video Coding ）として， ISO/IEC
14496-10（MPEG-4 パート 10）にする予定である．ITU-T
との承認手続きの違いによる出版の遅れを防ぐため，
CD 投票期間を第 61 回 WG 11 会合（2002-07-22/26）
前までに短縮することを承認した．
4.7 Publicly Available Standard
SC 29 内で開発した IS の普及のため，JPEG 2000，
MPEG-1，MPEG-2，MPEG-4，MPEG-7 の適合性試験と参
照ソフトとウェアを Web 公開することを勧告した．
[備考] MPEG-1，MPEG-2 などインターネット普及以前
の標準についてはインターネット上での配布体制が
十分整っていなかった．これを整備することがこの勧
告の主目的である．各 WG ではすでに準備を進めてお
り，Web 公開の準備はほぼ整っていた．
4.8 Registration Authority for ISO/IEC 15938-5
and 21000-3
これらの RA の候補に，RA として果たせるサービス
の提示を求める．
4.9 著作権表示
Joint Video Team のプロジェクトにも対応できる
よう，SC 29 Software Copyright Licensing Disclaimer
を改定した．
[背景]
現状の著作権表示では，標準用に開発した参照用
公開ソースコードを非標準用途に利用することを
防ぐために，「当該標準に準拠した製品に限り」
自由に利用できる，と記載されておりこのままで
は ISO/IEC の参照用公開ソースコードを ITU 等の
標準化に利用できないという不都合が生じていた．
旧著作権表示は ITU との共同作業を想定していな
かっただけであり，すでに新しい著作権表示を作
成した旨が WG 11 コンビーナより説明された．な
お標準以外の利用を禁止したのはおそらく，標準
以外の利用を無制限に認めてしまうと
proprietary な部分改良版を作ることが非常に容
易であり，参照用公開ソースコードの本来の目的
（標準の普及）に逆効果となる可能性があるため
と思われる．
(12) IPR と特許
ITTF に標準化作業において増加している IPR と特
許に関して注意を払うよう求める．また，各国 NB か
らの IPR policy の改善提案を歓迎する．
[背景]
ここで IPR と特許の増加とは，IPR や特許の扱い
が標準化プロセスに大きな影響を与える事例の増
6
加のことである．具体的には，現在 WG 11 で進め
ている Joint Video Team では標準に採用する提案
の選別に“patent free”に相当する条件を課して
おり，このような選別条件の是非やその手続きが
WG 11 でも大きな議論となっている．これは一例
にすぎず，一般にそれぞれ事情は異なるが，特許，
著作権の扱いに関し議論となる事例が多く，
Directives による明確な運営指針がないことによ
り，技術以外の議論に多くの時間を割かれる要因
となっている．特許に関する処理が簡単ではなく，
単純に Directives の改定を求めるだけでは対応
が難しいだろうという理解をしており，この件に
ついては標準の利用者である各国標準化機関の意
見を求めることとなった．
(13) Advisory Group on Management
a) 前回の SC 29 総会において，Motion JPEG 2000
と MP4 ファイルフォーマットの共通テキストを
作成するため，WG 1 と WG 11 の調整を主目的と
して,AGM を継続することにした.本会合では正
式に AGM コンビーナが任命され,共通テキストだ
けでなく，SC 29 間の問題に対応できるように各
国 NB に AGM メンバを募り,また AGM に対し AGM
の Terms and References の改定案の作成を依頼
することになった．
b) 各国 NB に対し，標準化に IPR が関係する事例を
提供するよう求め，AGM はそれらをまとめて IPR
関係の Directives 改定案を含むレポートを SC
29 に提出する．
c) Motion JPEG 2000 と MP4 ファイルフォーマット
の共通テキストについて，WG 間の調整を継続す
ること，また，このような案件があがった際の
調整・管理について，他にとりうる方法を検討
することを AGM に求めた．
(14) SC 29 Document Handling
UK NB より，非公開文書が WG 11 Ad hoc グループ
のリフレクタに流れている状況への懸念が示された
が，WG 11 済州島会合の案により，UK NB の求めてい
た事項が満たされていることを確認した．
[背景]
現在多くの WG 11 文書や SC 29 文書が Directives
の規定，または委員会の承認により Web 上で公開
されているが，これら多くの文書が公開されてい
ることにより，ISO/IEC 外部の人々が ISO/IEC の
委員会文書が「一般的に」公開であると誤解して
いる例が増えている．この点を UK NB は懸念して
いる．ISO/IEC の委員会内配布文書は「必ずしも
公開ではないが，その文書に限り一定条件で公開
している」ことが明確にわかるような著作権表示
について検討した．
5. 今後の開催予定
2003-07-28/30 トロンハイム（ノルウェー）
■ SC 36 （Information Technology for Learning,
Education, and Training／学習，教育，研修のため
の情報技術）総会報告
SC 36 専門委員会
委員長仲林清（(株)エヌ・ティ・ティエックス）
1. 開催場所：アデレード（豪）
2. 開催期間： 2002-03-06/09
3. 参加国数／出席者数： 12 ヵ国／37 名
議長（Frank Farance，米）
セクレタリ（Tony Monaco，Carolyn Merrick，米）
豪(2)，中国(3)，デンマーク(2)，フィンランド(1)，
仏(3)，独(1)，アイルランド(1)，ノルウェー(2)，英
(3)，米(5)，日(9:仲林清，池田満(阪大)，岡本敏
雄(電通大，WG 2 コンビーナ)，奥井康弘(日本ユニ
テック，WG 2 セクレタリ)，加藤重信(凸版印刷，SC
2 リエゾン)，黒木将人(日本ユニテック，WG 2 セク
レタリ)，古賀明彦(日立)，原潔(ユニシス)，平田謙
次(産能大)）
4. 議事内容（敬称略）
SC 36 は前回 2001 年 9 月のコペンハーゲン会議が
米国同時多発テロの影響で中止となり，1 年ぶりの総
会であった．日本から提案した協調学習は作業体制が
確立されつつあるが，他にも新しい規格検討の提案が
あった．主要な決議を以下に示す．
4.1 WG 2（協調学習）
プロジェクトエディタとして Collaborative
Workplace は原（ユニシス），Learner to Learner は
Frank Pretty（英）と古賀（日立）を任命した．各プロ
ジェクトに関してプレゼンを行い，CW については，プ
ロジェクトエディタが次回までに WD を用意することで
合意した．
4.2 WG 3（学習者情報）
Mike Collett（英）をコンビーナに任命した．IEEE
LTSC（Learning Technology Standards Committee）
PAPI（Public and Private Information）Learner，
IMS LIP（Learner Information Package）などをベー
スドキュメントとして検討することで合意した．
7
4.3 MDLET（学習管理システム）アドホック
Carlos Amaro（米）をコンビーナに任命した．IEEE
LTSC CMI（Computer Managed Instruction）規格をベ
ースに検討を進め，NP 投票を進めることで合意した．
4.4 LOM（学習オブジェクトメタデータ）
IEEE LTSC 規格を SC 36 でも規格化して行く方向で
合意した．
4.5 品質標準アドホック
学習教材，教育サービスにおける品質標準規格の概
念，手順を検討するアドホックを設ける．ISO 9000
などを念頭に置く．
5. 今後の開催予定
2002-09-19/21 カンサス（米）
2003-03-16/22 パリ（仏）
2003-09-21/27 未定（中国）
Technology Standards Committee）とのコロケーシ
ョンで会議が実施された．学習者情報，LOM，学習管
理システムなど，これまで LTSC で議論されてきた内
容に対応する WG が SC 36 でも活動を開始するととも
に，品質標準という，これまで e ラーニング業界全
体では大きなテーマであったが，技術標準としては
手付かずであったテーマが提案された．IEEE LTSC
でも今回，権利管理（Rights Management）Study Group
の設置が提案されており，e-ラーニング分野の標準
化に関する活動対象が広まりつつあることが実感さ
れた．
今回，中国は初参加でありながら，2003 年 9 月の
アジア開催のホスト国を引き受け，積極的に貢献す
る姿勢を表明した．わが国も会議開催をはじめ SC 36
の活動における貢献姿勢を積極的に示していく必要
がある．
6. その他
今回も過去の例に倣って，IEEE LTSC（Learning
8
＜解説：ディレクトリの概要と標準化の動向＞
SC 6/ディレクトリ SG
主査山口純一（日本アイ・ビー・エム(株)）
1. はじめに
ディレクトリは，実世界のオブジェクトに関する情
報の論理的データベースを保持する開放型システム
の集合体である．ディレクトリの利用者は，アクセス
権限の制約を受けながらディレクトリが保持する情
報の読み出しや更新をすることができる．このような
ディレクトリサービスを提供するため，開放型システ
ムの相互接続を容易にすることを目的として，ディレ
クトリに関する国際規格（ISO/IEC 9594）及び国際勧
告（ITU-T X.500 シリーズ）が技術的に同一の内容で
規定及び勧告されている．表 1 にディレクトリの国際
規格及び国際勧告の一覧を示す．
本稿では，ディレクトリの概要，及び標準化の経緯
と今後の動向を解説する．
2. ディレクトリの概要
ディレクトリの全体像を概観するため，ディレクト
リの機能モデル，情報モデル，サービスとプロトコル，
国際規格番号
ISO/IEC 9594-1
ISO/IEC 9594-2
ISO/IEC 9594-3
ISO/IEC 9594-4
ISO/IEC 9594-5
ISO/IEC 9594-6
ISO/IEC 9594-7
ISO/IEC 9594-8
ISO/IEC 9594-9
ISO/IEC 9594-10
国際勧告
ITU-T X.500
ITU-T X.501
ITU-T X.511
ITU-T X.518
ITU-T X.519
ITU-T X.520
ITU-T X.521
ITU-T X.509
ITU-T X.525
ITU-T X.530
セキュリティ，分散ディレクトリ，複製，ディレクト
リの管理と運用，TCP/IP 直接写像プロトコル，公開
かぎ証明書及び属性証明書の枠組みの各側面に焦点
を絞り，各々概要を説明する．最後に，IETF（Internet
Engineering Task Force）で開発された簡易なプロト
コル（LDAP）との比較を示す．
2.1 ディレクトリへのアクセスと機能モデル
ディレクトリは，オブジェクトの情報を保持し，そ
の情報にアクセスするサービスを利用者に提供する
分散処理システムである．ディレクトリ利用者は，ア
クセス権限があれば，ディレクトリ利用者エージェン
ト（DUA）を介して，ディレクトリにアクセスし，デ
ィレクトリ情報を読み出したり，変更することができ
る．このアクセスの入り口をアクセス点と呼ぶ（図 1）．
ディレクトリは，互いに協調動作する 1 つ以上のディ
レクトリシステムエージェント（DSA）の集合体であ
る（図 1）.
タイトル
ディレクトリ−第 1 部：概念，モデル及びサービスの概要
ディレクトリ−第 2 部：モデル
ディレクトリ−第 3 部：抽象サービス定義
ディレクトリ−第 4 部：分散操作の手順
ディレクトリ−第 5 部：プロトコル仕様
ディレクトリ−第 6 部：代表的な属性型
ディレクトリ−第 7 部：代表的なオブジェクトクラス
ディレクトリ−第 8 部：公開かぎ証明書及び属性証明書の枠組み
ディレクトリ−第 9 部：複製
ディレクトリ−第 10 部：ディレクトリ管理のためのシステム管理の利用
表1
ディレクトリ国際規格,国際勧告一覧
アクセス点
ディレクトリ
ディレクトリ
利用者
DSA
DAP
DUA
DSP
DSA
DSP
DSA
DSP
DUA：ディレクトリ利用者エージェント
DSA：ディレクトリシステムエージェント
DAP：ディレクトリアクセスプロトコル
DSA
DSP：ディレクトリシステムプロトコル
図 1 ディレクトリへのアクセスとディレクトリの機能モデル
9
2.2 情報モデル
ディレクトリに保持される情報をディレクトリ情
報ベース（DIB）と呼ぶ．DIB では，各オブジェクト
に関する情報は，エントリとして格納される．DIB
の各エントリは，階層構造を持った木構造に配列さ
れる．これをディレクトリ情報木（DIT）と呼ぶ（図
2）．エントリは，属性の集合として構成され，各属
性は，属性型と 1 つ以上の属性値からなる．属性値
は，名前を表すために使われる識別属性値とそうで
ない属性値がある．各属性値には，オプションでコ
ンテキストを付けることにより，属性値の言語的，
地理的，時間的等の利用条件特性を付与することが
できる．
コンテキストは，図 2 に示すように，コンテキス
ト型と 1 つ以上のコンテキスト値及びフォールバッ
クからなる．
2.3 サービスとプロトコル
ディレクトリがディレクトリ利用者に提供するサ
ービスは，アクセス点を介して，DUA により提供さ
れる．DUA からサービス要求を受けると，ディレク
トリは，正常に処理ができた場合は結果を，そうで
ない場合は，エラーを返却する．ディレクトリが提
供するサービスは，ディレクトリアクセスプロトコ
ル（DAP）を使って提供される．表 2 にこれらのサー
ビスを示す．ディレクトリがサービスを提供する際
に，1 つの DSA のみで操作要求を完了できない場合，
関連する DSA と協調動作を行う．この協調動作は，
DSA 間でディレクトリシステムプロトコル（DSP）を
使って行われる（表 2）．この他，シャドウ消費側
とシャドウ提供側の間で複製サービスを提供するシ
ャドウ化プロトコル，2 つの DSA 間で情報交換する
ための共通枠組みを適用するディレクトリ運用結合
管理プロトコル（DOP）が規定されている（表 2）．
根（root）
Ｄ
Ｉ
T
構
造
エントリ
別名エントリ
属性
属性
属性型
エ
属性
属性値(群)
ン
ト
リ
識別属性値
属性値
属性値
コンテキスト(群)
コンテキスト(群)
コンテキスト(群)
構
造
コンテキスト
コンテキスト
コンテキスト型
図2
コンテキスト値(群)
コンテキスト
フォールバック
ディレクトリ情報木（DIT）とエントリの構造
10
プロトコル
サービス
ディレクトリ結合
プロトコルの位置付け
DUAとDSA間のコネクションの確立を要求する
ディレクトリ結合解放 DUAとDSA間のコネクションの切断を要求する
ディレクトリ
アクセスプロトコル
（DAP）
Directory Access Protocol
読出
エントリの情報の読み出しを要求する
比較
エントリの情報と指定値の比較を要求する
放棄
既要求のサービス操作の放棄を要求する
一覧
あるエントリの配下のエントリの一覧を要求する
検索
ある条件に合致するエントリの情報を検索する
エントリ追加
エントリの新たな追加を要求する
エントリ削除
既存のエントリの削除を要求する
エントリ更新
既存のエントリの情報の更新を要求する
識別名更新
ディレクトリ
システムプロトコル
（DSP）
Directory System Protocol
DSA間のコネクションの確立を要求する
DSA結合解放
DSA間のコネクションの切断を要求する
ディレクトリ
運用結合プロトコル
（DOP）
Directory Operational
Binding Management
Protocol
DUA
DSA
DSA
ディレクトリ
利用者
DUA
DSA
DSA
DUA
DSA
DSA
DUA
DSA
DSA
DAPの読出∼識別名更新に対応する各サービスを要求する
DSAシャドウ結合
ディレクトリ
情報シャドウ化
プロトコル
（DISP）
Directory Information
Shadowing Protocol
利用者
既存のエントリの名前（識別名）の更新を要求する
DSA結合
連鎖…
ディレクトリ
DSA間のシャドウサービスのコネクションの確立を要求する
DSAシャドウ結合解放 DSA間のシャドウサービスのコネクションの切断を要求する
シャドウ更新要求
シャドウ更新
シャドウ消費側からシャドウ更新を要求する
ディレクトリ
利用者
シャドウ情報の更新の実行を要求する
シャドウ更新調整
シャドウ提供側からシャドウ更新の要望を伝える
ディレクトリ結合
DSA間のコネクションの確立を要求する
ディレクトリ結合解放 DSA間のコネクションの切断を要求する
運用結合確立
運用結合の確立を要求する
運用結合更新
運用結合の内容の更新を要求する
運用結合終結
運用結合の終結を要求する
表2
ディレクトリ
利用者
ディレクトリのプロトコルとサービス
2.4 セキュリティ
セキュリティ機能は，①ユーザ認証機能，②アクセ
ス制御機能，③暗号化機能，④情報発信元認証機能が
考えられる．ディレクトリでは，これら全てを規定し
ている（①1988，②1993，③1997，④1988）．ユーザ
認証機能では，認証なし，簡易認証（パスワード利用），
厳密認証（デジタル署名利用）の 3 つを規定している．
デジタル署名は，公開かぎ証明書を使って行う．情報
発信元認証機能では，認証なし，厳密認証の 2 つを規
定している．アクセス制御機能では，アクセス制御管
理モデルにより，アクセス制御管理権限の委譲のメカ
ニズムと具体的なアクセス制御メカニズムが規定さ
れている．アクセス制御モデルとしては，基本アクセ
ス制御，簡易アクセス制御，及び規則ベースアクセス
制御の 3 つのオプションが規定されている．
2.5 分散ディレクトリ
DIB が複数の DSA に分散された環境では，DUA からの
サービス操作要求が１つの DSA で完了しない場合，DSA
は他の DSA と協調動作を行う．協調動作には，3 つの動
作があり，①単一連鎖，②多重連鎖，③紹介がある．
ディレクトリを構成する各 DSA は，DIB の一部を保持
する．DSA が保持する DIB の一部は，１つ以上の名前コ
ンテキストにより表現される．名前コンテキストは，
DIT の部分木であり，コンテキスト接頭部（部分木の
根ノードの名前）で参照される．ディレクトリが複数
の DSA に分散される場合，協調動作を行うためには，
各 DSA が DIT のどの部分を保持するかといった知識を
持つ必要がある．DSA はこれを知識参照として保持す
る．知識参照には，①上位参照，②直接上位参照，③
下位参照，④不特定下位参照，⑤相互参照の 5 種類が
ある．また，複製サービスのサポートにおいて，さら
に，⑥提供側知識，⑦消費側知識が規定されている．
分散ディレクトリでは，各 DSA は，適切な手順にした
がって協調動作を実施する．この手順は，①名前解析フ
ェーズ，②評価フェーズ，③結果合併フェーズよりなる．
2.6 複製
ディレクトリでは，情報の複製により，性能，可用
性，信頼性，回復性の向上を図ることができる．情報
の複製の方法には，キャッシュ化とシャドウ化の 2
通りがある．前者は，ローカル方針で管理され，ディ
レクトリでは規定されない．一方後者に対しては，シ
ャドウ化プロトコルにより提供される．シャドウ化の
機能モデルは，2 つのポリシー，一次シャドウ化と二
次シャドウ化を規定している（図 3）．一次シャドウ
11
化は，マスタ DSA の情報をディレクトリ情報シャドウ
化プロトコル（DISP）を使って，シャドウ消費側 DSA
に複製する．これにより，ディレクトリサービスの性
能，可用性，信頼性，回復性の向上を図ることができ
る．二次シャドウ化は，マスタ DSA の負荷軽減が必要
となる際に，シャドウ消費側兼提供側 DSA を介して，
シャドウ消費側 DSA に複製するもので，
DISP を使う．
2.7 ディレクトリの管理と運用
ディレクトリは，地球規模のグローバルな運用を目
指した分散システムであるため，多くの DUA 及び DSA
により構成され，その結果多くの組織により運用され
る．ディレクトリを運用・管理する側面から，ディレ
クトリ管理モデルが規定されている．１つの組織が管
理する範囲は，機能モデルと情報モデルの側面で捉え
ることができる．機能モデルで捉えた場合の範囲をデ
ィレクトリ管理領域（DMD），情報モデルで捕らえた
場合の範囲を DIT 領域と呼び，管理組織をディレクト
用管理方針を定め，それに従ってディレクトリを運用
する．運用管理方針は，機能モデル側面のものを DMD
方針と呼び，情報モデル則面のものを DIT 方針と呼ぶ．
DMD 方針は，例えば，ディレクトリ利用者に参照系サ
ービスのみ提供するといった運用条件を規定するも
ので，DMO が管理する DSA に一様に適用することも，
特定の DSA のみに適用することもできる．DIT 領域方
針は，①エントリの命名方針に関する命名管理，②サ
ブスキーマに関するサブスキーマ管理，③アクセス制
御方法に関するセキュリティ管理，④集合属性の設定
方法に関する集合属性管理が規定されている．このよ
うな DIT 領域方針は，運用属性とサブエントリの概念
を導入することにより実現される．運用属性は，ディ
レクトリの運用管理のための属性であり，この中に上
記 DIT 領域を示すサブツリー仕様と DIT 方針を示す情
報を格納する．図 5 にディレクトリの管理・運用情報
モデルを示す．
リ管理組織（DMO）と呼ぶ（図 4）．
DMO は，ディレクトリの運用にあたり，それぞれ運
一
次
シ
ャ
ド
ウ
化
シャドウ
消費側
DSA
マスタ
DSA
：シャドウ更新
シャドウ
消費側&
提供側
DSA
シャドウ
消費側
DSA
ディレクトリ管理組織（DMO）
DIT領域
DMD
DUA
DSA
二
次
シ
ャ
ド
ウ
化
DSA
DSA
DUA
図4
図 3 シャドウ化の 2 つのポリシー（一次シャドウ
ディレクトリの管理
化と二次シャドウ化）
管理エントリ
AP
利用者属性
運用属性
サブエントリ
利用者属性
運用属性
管理領域（AA）
エントリ
利用者属性
運用属性
：管理ポイント
（AP）
図5
ディレクトリの管理・運用情報モデル
12
ACSE，プレゼンテーション，セション，トランスポ
ートの各層をバイパスし，直接 TCP/IP に写像される
（図 6）．
2.9 公開かぎ証明書及び属性証明書の枠組み
公開かぎ基盤（PKI）で利用できる公開かぎ証明書，
権限管理基盤（PMI）で利用できる属性証明書が定義
されている（図 7）．
2.8 TCP/IP 直接写像プロトコル
簡易な実装を目的に，ディレクトリサービスの
TCP/IP への直接写像が規定されている．これをイン
ターネット直接写像プロトコル（IDM）と呼ぶ．IDM
プロトコルでは，ディレクトリサービスを運ぶ要求
と結果，エラーは，IDM メッセージ（IDM-PDU）の形
で表現される．IDM-PDU は，OSI 参照モデルの ROSE，
OSI 基本参照モデル
IDM over TCP/IP
応用層
IDM-PDU
ディレクトリ over OSIサービス over TCP/IP
DS-PDU
ROSEヘッダ
ACSEヘッダ
DS-PDU
プレゼンテーション層
アプリケーションPDU
Pヘッダ
セション層
プレゼンテーションPDU
Sヘッダ
トランスポート層
IDM-PDU
TCPヘッダ
セションPDU
TCPヘッダ
IDM-PDU
TCPヘッダ IPヘッダ
セションPDU
TCPヘッダ IPヘッダ
ネットワーク層
データリンク層
【凡例】 IDM-PDU：インターネット直接写像・プロトコルデータユニット
DS-PDU：ディレクトリサービス・プロトコルデータユニット
物理層
Pヘッダ：プレゼンテーションヘッダ
図6
Sヘッダ：セションヘッダ
IDM over TCP/IP とディレクトリ over OSI over TCP/IP のプロトコルスタック
公開かぎ証明書
ハッシュ
属性証明書
バージョン
バージョン
シリアル番号
所有者
署名アルゴリズム
発行者
証明対象発行者
証明書有効期限
ダイジェスト
シリアル番号
有効期間
証明対象公開鍵情報
属性群
発行者ユニーク識別子
発行者ユニーク識別子
ユーザユニーク識別子
拡張群
拡張識別子
重要性
拡張値
図7
署名
発行者の
秘密鍵による
暗号化
署名
拡張
署名アルゴリズム
証明対象ユーザ
証明書拡張群
発行者の
秘密鍵による
暗号化
ハッシュ
ダイジェスト
拡張
拡張識別子
重要性
拡張値
公開かぎ証明書と属性証明書
13
プロトコルスタック
機能
データ表現形式
符号化方式
X.500 DAP
OSI 基本参照モデル
OSI サービス over TCP/IP
IDM over TCP/IP
全サービス
構造化表現
ISO/IEC 8825 に基づく符号化
表3
拡張項目
フレンド属性
ページ単位返却機能の分散サポート
LDAP との整合
証明書拡張
関連エントリ
LDAP
Over TCP/IP のみ
読み出しサービスと一覧サービスを検索サービスに統合
文字列
ISO/IEC 8825 のサブセット（基本形式のみ）に基づく符号化
X.500 ディレクトリと LDAP の違い
拡張の概要
オープンエンドなサブスキーマ定義を可能とすることを目的に，ホスト属性に対する
フレンド属性を定義し，エントリ情報選択にホスト属性を指定することでフレンド属
性も返却可能とする．また，検索条件の照合対照にフレンド属性を考慮する検索メカ
ニズムを提供する．
伝送速度の高速化及びデータ量の増大化による境界 DSA のページ化処理の負荷軽減を
目的として，DSP 上でのページ単位に結果を返却する機能を実現する．
LDAP と OSI ディレクトリの両者の良い技術要素を結合することによるメリットを見出
すことを目的に，①LDAP の DSP へのカプセル化による分散オペレーション連携，②関
連エントリの処理対象範囲を LDAP まで拡大すること，③名前解析の対象名前空間を
LDAP，DNS まで拡張すること，④XML を使ったプロトコル／プレゼンテーション間連
携等を実現する．
証明書に関して，①未来における証明書失効の事前通知機能，②集団に属する証明書
の失効通知機能，③公開かぎ証明書に対象者のディレクトリ属性の証明書を包含する
機能，④証明書の照合規則の追加，⑤名前制約を含む証明書の検証処理の拡張，⑥XML
を用いた権限情報の符号化，等を実現する．
複数のサービス提供者がそれぞれ個別に運用するディレクトリにサービス加入者の
情報を格納することを想定し，①オブジェクトを複数の関連エントリの中で表現可能
にすること，②複数の離散的な DIT ビューを許容すること，③関連エントリに対する
結合操作を実行可能にすること等を実現する．
表4
検討中の拡張項目一覧
2.10 X.500 ディレクトリと LDAP
LDAP（Lightwight DAP）は，IETF で開発されたデ
ィレクトリアクセスプロトコルである．名前のとおり，
X.500 シリーズで規定された DAP に対して，軽いフロ
ントエンドを提供する．
ディレクトリの国際標準である X.500 ディレクト
リは，豊富な機能と洗練された構造を持ち，ディレク
トリサービスとしては充実した内容のものであった．
しかし，多機能さと構造の複雑さが，インターネット
環境における実装や実際のサービス提供を難しくし，
ディレクトリアプリケーションやディレクトリサー
ビス普及の障害となっていた．
LDAP は，この障害を軽減し，インターネット環境
でディレクトリを簡易に実現することを狙って設計
された．表 3 に X.500 ディレクトリと LDAP の主な違
いを示す．
3. 標準化の経緯と今後の動向
3.1 経緯
ディレクトリの国際標準は，最初の国際規格（第 1
版）が 1988 年に制定されて以来，様々な側面におけ
る拡張要望に応えながら改版が重ねられており，2001
年に規格化された第 4 版が最新版である．図 8 に第 1
版から第 4 版までの標準化経緯概要を示す．
3.2 今後の動向
現在，ISO/IEC JTC 1/SC 6/WG 7 及び ITU-T SG 17/Q9
において，さらに国際規格及び勧告の拡張が検討され
ている．拡張検討項目は，フレンド属性，ページ単位
返却機能の分散サポート，LDAP との整合，証明書拡
張であり，その概要を表 4 に示す．
4. おわりに
以上，本稿では，ディレクトリの概要，標準化の経
緯と今後の動向を概観した．
14
第１版
第２版
第３版
第４版
CCITT：
CCITT：1988
ISO/IEC：
ISO/IEC：1990
ITUITU-T：1993
ISO/IEC：
ISO/IEC：1995
ITUITU-T：1997
ISO/IEC：
ISO/IEC：1998
ITUITU-T：2001
ISO/IEC：
ISO/IEC：2001
タイトル
ITU-T
ISO/IEC
パート１
X.500
95949594-1
概念、モデル、サービスの概要
パート２
X.501
95949594-2
モデル
パート３
X.511
95949594-3
抽象サービス定義
パート４
X.518
95949594-4
分散操作の手順
パート５
X.519
95949594-5
プロトコル仕様
パート６
X.520
95949594-6
代表的な属性型
パート７
X.521
95949594-7
代表的なオブジェクトクラス
パート８
X.509
95949594-8
認証フレームワーク
パート９
X.525
95949594-9
複製
パート10
パート10
X.530
95949594-10
ディレクトリ管理のためのシステム管理の利用
主な規定内容と
拡張項目
①ディレクトリ最初の標準
②基本機能を標準化
①複製
②アクセス制御
③スキーマ管理 ④サービス拡充
図8
①セキュリティ拡充
②コンテキスト概念
③サービス拡充
④システム管理の利用
①証明書拡充
②TCP/IP写像
TCP/IP写像
③サービス拡充
④分散エントリ
標準化の経緯概観
15
＜平成 13 年度
情報処理学会「業績賞」表彰の紹介＞
情報処理学会では，平成 13 年度より「業績賞」を設け情報技術に関する新しい発明，新しい機器や方式の
開発・改良，あるいは事業化プロジェクトの推進において，顕著な業績をあげ，産業分野への貢献が 3 年以
内に明確になった業績を対象に表彰することになりました．
平成 13 年度に選ばれた 3 つの業績のうちの１つは JTC 1 の国際標準に関係する業績で，5 月 20 日に開催さ
れた情報処理学会の総会で表彰されました．
◆
2 次元シンボル「QR コード」を利用した情物一致手段の提供による企業の情報化，効率化
受賞者：
柴田
高井
河岸
木内
辻本
彰氏
弘光氏
智史氏
潤一郎氏
有伺氏
(株)デンソーウェーブ（SC 31 専門委員会委員長）
(株)デンソーウェーブ（SC 31 専門委員会委員, WG 1，WG 3 国内委員会主査）
(株)デンソーウェーブ
(株)デンソーウェーブ
デンソーインターナショナルアメリカ
*QR コードは，日本が JTC 1/SC 31 へ国際提案し，ISO/IEC 18004 として 2000 年 6 月 15 日に発行．
∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪∽♪
＜ 2002 年 6 月以降
国際会議開催スケジュール＞
JTC 1
2002-10-21/25
Sophia Antipolis, France
SC 25
2002-09-27
Washington D.C., USA
SC 2
2002-12-05/06
東京, 日本
SC 27
2002-10-14/15
Warsaw, Poland
SC 6
2003-02 未定
London, UK
SC 28
2003-05/06 未定
未定, 日本
SC 7
2003-05-11/16
Montreal, Canada
SC 29
2003-07-28/30
Trondheim, Norway
SC 11
2004-05-12/14
Lugano, Switzerland
SC 31
2003-05-15/16
未定, France
SC 17
2002-10-09/11
Copenhagen, Denmark
SC 32
2003-01-27/31
Santa Fe, USA
SC 22
2002-08-27/30
Saariselk, Finland
SC 34
2002-12-07/12
Baltimore, USA
SC 23
2003-09-17
未定，Europe
SC 35
2002-06-03/05
Copenhagen, Denmark
SC 24
2002-06-21
London, UK
SC 36
2002-09-19/21
Kansas city, USA
訃
音
氏名：井口厚夫先生
勤務先：獨協大学
主な所属委員会：学会試行標準専門委員会（委員），学会試行標準/WG 3 小委員会（主査）
平成 14 年 6 月 3 日にご逝去されました．生前の活動に感謝し，ご冥福をお祈り致します．
16
＜声のページ＞
Lisp から始めた標準化活動
黒川利明（(株)CSK）
標準化にかかわるようになったきっかけは，日本
IBM のサイエンス･インスティチュートが東京基礎研
究所と看板を変えたばかりの春に，本社の徳永英二
さんが来られて，「今度，Lisp の国際標準化を進め
ることになったので，協力してほしい」とおっしゃっ
た一言にある．おかげさまで，徳永さんとはその後も
（二人とも IBM を定年退職したが）お付き合いさせて
いただいている．
記憶が不確かなのは，電子協（今は，電子情報技術
産業協会）で青山学院大学の井田昌之先生が委員長を
務めておられた Lisp の作業部会にその前から参加し
ていたのか，その後から参加したのかという点である．
ともかく，和田英一先生の「Lisp を標準化するの
は正しいことなのかね？」というコメントを横目で見
ながら，「Lisp が標準化される時代になったのだ」
という感慨を抱いたことを昨日のことのように思い
出す．そういえば，1980 年に Stanford 大学で開かれ
た最初の Lisp Conference で「Common Lisp」が提案
されたときの，戸惑いを含めて「うひゃっ」と思った
こともほんの今しがたのことのようである．
それまでの「研究」という場から，「標準」という
場に来て驚いたことは，研究の場で存じあげていたか
なりの人が標準にも関わっておられるということで
あった．その意味では，居心地がそう悪くなかった．
もうひとつ驚いたのは，「標準」の持つ政治性である．
まだ，商業主義に露骨に漬かっていない時代だったが，
政治臭だけは紛々としていて，研究者としての青臭さ
が抜けていない身にとっては，尻を落ち着けにくい場
でもあった．
もっともその後，企業内での「政治」を見聞きする
につれて，標準の世界もその他大勢の人間の世界とな
んら変わらないと達観するようになったが．
いや，標準の世界の方が個人の能力に依存するとこ
ろが大きいという現実を目の当たりにしてきたとい
う経験から言えば，政治はつき物だという定理を導く
べきかも知れない．その点に関しての日本の（少なく
とも情報標準に関する）弱点は，標準に対する「個人」
の技術的ならびに政治的貢献を正当に評価せず，いま
だに「企業」（の一社員）の貢献としか見ていない点
だろう．
専門委員会などは，その線から言えば，企業の枠にと
らわれず，専門家集団に衣替えすべきなのだが，これ以
上は紙数が尽きたのでまたどこかの機会でにしたい．
符号化文字基本集合（BUCS）について
松岡榮志（東京学芸大学）
本年 3 月，「符号化文字基本集合（BUCS）」が，学
会試行標準 IPSJ-TS 0005:2002 として公布されました．
この「符号化文字基本集合」というのは，ISO/IEC
10646-1 の漢字部分の basic subset です．詳細は，
http://www.itscj.ipsj.or.jp/ipsj-ts/02-05/ を見
ていただくとして，私がなぜそのような事を考え始め
たのかについて，少し書いてみたいと思います．
まず，「漢字をうまく使いこなす」ための漢字コー
ドセットの提案，ということです．それは，機械が手
早く処理できるから何でもよいということではなく，
私たち人間自身が，毎日の生活のためにうまく使いこ
なすにはどうしたらよいか，ということです．そのた
めには，巨大な漢字コード表が一つあれば事足りる，
というわけにはいきません．むしろ，使用場面に応じ
たいくつかのコード表が必要です．
1990 年の年末に，CJK-JRG（日中韓 Joint Research
Group）のエキスパート委員として，私が標準化活動
に参加して以来，すでに 10 年以上の月日が流れまし
た．CJK-JRG は，やがて JTC 1/SC 2/WG 2/IRG として
活動し，国際規格 ISO/IEC 10646-1:1993 （ JIS X
0221:1995）を提案，BMP（基本多言語面）において
20,902 字の漢字のコード化を行いました．さらに，
Extension A （ 6,582 字）を追加して， ISO/IEC
10646-1:2000（JIS X 0221:2001）となり，最近では
Extension B として，約 7 万字にコードが振られ
（ISO/IEC 10646-2:2001），さらに Extension C とし
ての追加が話し合われています．もちろんこれは，研
究にとっては大変すばらしい事です（私も，中国語
学・中国文学が専門なので，その重要性は実によくわ
かります）．ただ，もう一方では，私たちの毎日の暮
らしにとって必要な，基本的な漢字セットのことは，
これまで置き去りにされてきました．
私たちが日常使用している漢字は，せいぜい 2,000
字くらいです．また，漢和辞典の索引などでは，人間が
普通に扱えるのは，せいぜい一万字どまりです．今回，
学会試行標準として公布されたセットには，代表字形
7,946 字，別字形 5,085 字が含まれていますが，日本，
中国，台湾，韓国などの国や地域（すなわちマルチリン
ガル環境）における情報交換に対応しうる，基本的な漢
字コードセットとなっています．これを選定する上で導
入されたのは，「機能度」という新しい考え方ですが，
こうした生活上の観点から，用途に応じたいくつかの漢
字セットを提案していきたいと思っています．
17
＜ ITSCJ の広場＞
投稿フォーマットの規定
情報規格調査会のホームページに，会員の皆様，情
報技術標準化に関心をお持ちの方々に広く参加してい
ただきたく，公開討論や意見交換のコーナとして
『ITSCJ の広場』を 1998 年 8 月より設けております．
掲載記事は，ITSCJ ホームページをご覧下さい．
また，情報技術標準化活動に資する活発な討論や意
見交換を望みます．意見・コメントは電子メールでお
寄せください．なお，投稿に際しては後述の投稿フォ
ーマットの規定を守って下さい．
ITSCJ ホームページ
http://www.itscj.ipsj.or.jp/
寄せられた意見・コメントに対しては，当調査会の
広報委員会が中心となって，この広場で発言していた
だくに相応しいか否かを判断させていただきます．場
合によっては修正させていただくこともあります．
電子メールアドレス
[email protected]
前号以降の新規投稿
(1) タイトル，著者名，所属および投稿日付を必ず
お書き下さい．
(2) 所属は，会社名（または学校名，機関名）の他
に，部署名も簡潔（会社名も含めて全角文字換
算 30 字程度以内）に書いて下さい．
(3) 原稿は，行替えや行の開始位置など希望の最終
仕上げが分かるように編集して投稿して下さい．
MS word や html で編集して添付ファイルにして
いただくのも歓迎です．ただし，掲載されたと
きの編集状態は必ずしもご希望に沿ったものに
なるとは限りません．あらかじめご了承下さい．
なし
お知らせ
JTC 1 関係の国際規格のプロジェクトの進捗状況が Web 上で照会できるシステムが
ほぼ完成し,間もなく ITSCJ のホームページからご利用いただける予定です.
前号まで掲載していました NP，CD，DIS，IS の状況は，この照会システムでご覧い
ただけますので，今号より省略させていただくことになりました．ご了承ください．
＜編集後記＞
2002 FIFA ワールドカップがいよいよ始まりました．
日本は，予選リーグを勝ち残れるでしょうか．世界中の
注目が日本と韓国に集まっています．共通のルールの下，
まさに技と力の対決ですね．初戦で前回優勝のフランス
が初出場のセネガルに敗れるという波乱の幕開けです．
それにしてもカメルーンには，やきもきさせられました．
テレビの解説者が言ってましたが，世界には，そういう
国もあるのです．日本人は几帳面なので，やきもきする
んですよと．中津江村は，ちょっと有名になりました．
今回は，専門委員会の活動報告が別冊であり，なかな
か大変でしたが無事キックオフできました．
このニューズレターが皆様のお手元にとどくころ，日
本が決勝トーナメントに出場していることを確信しつつ
筆を置きます．
[コータロー記]
発
行
人
社団法人情報処理学会
情報規格調査会
広報委員会
〒105-0011 東京都港区芝公園 3-5-8
機械振興会館 308-3
Tel: 03-3431-2808 Fax: 03-3431-6493
[email protected]
http://www.itscj.ipsj.or.jp/
18

Download Report