2002/12/02 ENUM研究グループ第4回研究会
資料1
○ENUM 研究グループ 第3回研究会 議事録(案）
■ 日 時： 2002年 11月 5日 (火) 10:00 - 11:40
■ 場 所： 東京都千代田区内神田2-3-4 国際興業神田ビル6階
(社)日本ネットワークインフォメーションセンター (JPNIC) 会議室
■ 議 題： 1) 第2回研究会議事録確認
2) 分科会報告 (事務局)
3) ベースラインドキュメント
4) 今後のスケジュール
5) その他
■ 配布資料：
資料1 第2回研究会議事録
資料2 ENUM研究会分科会報告
資料3 ENUM研究グループ第1次報告書(第0版)
資料4 用語の定義
資料5 エンティティの定義
■参加者：
(敬称略) 伊勢 禎和 社団法人日本ネットワークインフォメーションセンター
大内 勉 日本電気株式会社
大谷 哲也 日本サイバースペース株式会社
大宮 知己 日本電信電話株式会社
加藤 義文 社団法人テレコムサービス協会
北島 敏 日商エレクトロニクス株式会社
木原 誠司 日本電信電話株式会社
後藤 滋樹 早稲田大学
後藤 雅徳 沖電気工業株式会社
澤田 拓也 KDDI株式会社
佐野 晋 社団法人日本ネットワークインフォメーションセンター
澤木 錠詞郎 NTTコミュニケーションズ株式会社
塩田 要平 東京通信ネットワーク株式会社
白澤 進 日本電気株式会社
神野 公秀 日本電信電話株式会社
関 一朗 日本電信電話株式会社
田中 武四郎 三菱商事株式会社
堂坂 智明 株式会社日本レジストリサービス
根津 智子 社団法人日本ネットワークインフォメーションセンター
延坂 成人 ネットワンシステムズ株式会社
橋本 薫輝 日本サイバースペース株式会社
細見 昭英 三菱商事株式会社
堀崎 修宏 社団法人情報通信技術委員会
藤原 和典 株式会社日本レジストリサービス
堀田 博文 株式会社日本レジストリサービス
真鍋 尚 インターネットフォーラム
森 利行 JENS株式会社
吉井 裕重 日本テレコム株式会社
■オブザーバ: (敬称略) 総務省データ通信課 加藤 博司
■議事：
1) 第2回研究会議事録確認
事務局の伊勢氏が、資料1の通り第2回研究会の議事録をレビューした。
KDDI株式会社の澤田氏の名前が抜けていたためそれを追加した上で承認と
なった。
2) 分科会報告 (事務局)
資料2に基づき、事務局の伊勢氏が2002年10月15日、10月21日にと開催した
研究会グループの分科会の報告を行った。
3) ベースラインドキュメント
資料3、4、5に基づき、事務局の佐野氏が今月の第1次報告に向けた、第0版の
第1次報告書をレビューした。案なので、足りないところを補足して近々に
再提出したいとの補足説明があった。その後、下記の質疑応答が行なわれた。
Q: Tel: とゲートウェイとは直接に関係ないのか
A: ローカルエンティティに直接に接続しているのがゲートウェイであるため、
関係はない。
Q: Tel: は直接つながることを前提としているのか
A: もちろんそういう使い方もあるがSIPで使うことも想定されているときに、
そこにTEL: を直接かくことが出来る。
アウトバンドプロキシで設定して転送することも出来る
Q: それは実装レベルの話か?
A: 何故か知っているSIPのサーバ。実際の外にでるオフィスにtel:で帰って
くると、sip:で出すようなメディアゲートウェイ機能をもっている
Q: fax: modem: について RFC2806bisではこれらはなくなっているようだが
A: fax: はなくなっている。RFC2406ができたころは fax, modem は意識されて
いたがbis になってからはずされたということは tel として使われることに
比重があるのかと考える。(draft-anpti-rfc2806bis)
O: これについて今度のIETFのアジェンダどうなるかわからないが、それが終っ
たあとで本報告書を出したいと考えている
O：TEL：のところも仮想的な電話をかけるイメージで、書き方が微妙である。
O: これまでIP電話応用向の議論だったのだが、それから見ればDDDSをもっと
説明する必要があるのではないか。それがUSER ENUMのバックグラウンドに
なるのではないか
Q: DDDDSとENUMの関係は具体的にどういう事なのか
A: 電話番号もDDDSで表現されるものにすぎないのでは、という解釈
A: DDDSはパート5まであるが、そのものは抽象的なアルゴリズム。
一般的に書き換え規則をもったものに対してキーをいれるとアウトプットが
でる。キーについては文字列AUS(application unit stream)でDBはSQLでも良い
RFC3403 part3 NAPTRを 使う。part2 が書き換え規則の一般的な定義。
3403はNAPTRが定義される。 ここで2つをBindされたのが 2916BIS
一般の人がDDDSがオーバースペックだが、ENUMのところではNAPTRレコードの
ところが記載されればいいのではないか
A：何回も書き換えを避けるという意味で、URL が定義される。一度の書き
換えでよくなっているのでは。
A：他のキーで聞いたときに電話番号を返すということでは出来ないのか
A：E2U がENUMサービスのパラメータ 2616bis (資料の5ページ)
O：報告書にはなにか記載したほうがいいだろうか
Q: 13ページに「共通線を解釈する」という表現があるが、それは関係ないのでは
ないか。自分なら省く
A： 考える。
Q： 報告書のスケジュールは
A： 本日コメントをもらって、4章を含めてもう少し膨らませたい
Tier 構造に関しては、4.1 4.2 を膨らませる
その上でIETFの結果を反映して出したい
2つのやり方(ユーザENUM/オペレータENUM)とリクアイアメントをピック
アップして報告したい
O：11ページ「アプリケーションの識別手段は音声以外のものにもなる」とあるが
それなら総務省に「広げるべきだ」という提言をするべきだ
どちらのスタンスで報告書をまとめるのか
O：音声役務に限定してENUMをやった場合は問題はないが、提言するべきだろうか?
海外はどうなっているのか、本当のところは良くわからない
O：「役務」という概念は日本独特のもの
Q： E.164は何を規定しているのか
A: 電気通信番号に関わるものは何でも構わない。ネットワークレイヤーの識別子。
E164 が国内で使われる電気通信番号。それを public network と
として扱うのが総務省令。
Q：17ページでユーザ、オペレータENUMのもう少しわかりやすい定義が欲しい。
第1種2種も撤廃される中、例えばIP電話事業者の定義は??
またユーザENUMが「普通のENUM」と記載されているが「普通」とは何か
A：もう少し書き下す
■今後の進め方
+ このドラフト案に対してコメントをもらい何点か内容を膨らます（4章含む）
→来週中ぐらいまでにコメント
原則、MLを利用（問題の共有、ディスカッション）
それ以外については事務局相談（Web等に乗せる等柔軟に対応していく）
+ 第1次報告書
→IETFの結果を反映したい（IETF ENUM：11/18）
+ 今後の作業はオンラインで行う
→11月は第1次報告書の見直し
→12月より第2フェーズに入る