SyncML 調査報告書 - MOBILE POCKETs Site

SyncML
（Device Management）
調査報告書
第 1.0 版
2004/07/02
(株)フジシステムズ金子
---------------------------------------------------------------------------------------------------使用上の注意
以下は当文書を利用するにあたっての注意事項です。以下について了承されない方は、速やかに当文書を
破棄して下さい。
! 当文書中のすべての情報について
その正確性・有効性は十分配慮していますが、不正確な内容がある可能性があります。それら情報の使
用の際に生じた損害等については一切の責任は負わないことをご了承下さい。
以上
Copyright © 2003-2004 Fujisystems Inc., All Rights Reserved.
----------------------------------------------------------------------------------------------------
変更履歴
年月日
版数
区分
2004/07/01
0.1
A
新規作成
2004/07/02
1.0
U
版数更新
区分：A＝追加／U＝更新／D＝削除
項番
変
更
内
容
備
考
目次
1.
はじめに ................................................................................................................................................ 1
1.1
参考文献 ................................................................................................................................................ 1
1.2
用語 ....................................................................................................................................................... 1
略語 ....................................................................................................................................................... 3
1.3
2. SYNCML のネットワーク構成 ................................................................................................................ 4
3. DM ツリー ............................................................................................................................................. 5
3.1
概要 ....................................................................................................................................................... 5
3.2
ノードの特性 ......................................................................................................................................... 5
3.2.1
3.3
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
4.
ACL................................................................................................................................................ 7
Format ........................................................................................................................................... 8
Name ............................................................................................................................................. 8
Size ................................................................................................................................................ 8
Title ............................................................................................................................................... 8
TStamp .......................................................................................................................................... 8
Type ............................................................................................................................................... 9
VerNo............................................................................................................................................. 9
3.5
DDF（DEVICE DESCRIPTION FRAMEWORK） ......................................................................................... 9
DM オブジェクト ................................................................................................................................... 9
4.1
DM オブジェクトの種類 ........................................................................................................................ 9
4.1.1
4.1.2
4.1.3
5.
ノードの種類 .................................................................................................................................. 5
ノードを操作するためのコマンド .......................................................................................................... 6
ノードのプロパティ............................................................................................................................... 6
SyncML DM オブジェクト ............................................................................................................. 9
DevInfo DM オブジェクト............................................................................................................ 12
DevDetail DM オブジェクト ........................................................................................................ 13
ブートストラップ（初期プロビジョニング） ..........................................................................................14
5.1
実現方法 .............................................................................................................................................. 14
5.1.1
5.1.2
5.2
カスタマイズブートストラップ .................................................................................................... 14
サーバ起動型ブートストラップ .................................................................................................... 14
ブートストラッププロファイル ........................................................................................................... 15
5.2.1
5.2.2
WAP プロファイル ....................................................................................................................... 15
プレーンプロファイル .................................................................................................................. 15
プロトコル ............................................................................................................................................15
ノードアドレッシング ......................................................................................................................... 15
6.1
6.2
SYNCML DM プロトコルパッケージ ................................................................................................... 16
6.3
認証 ..................................................................................................................................................... 16
6.4
ユーザインタラクションコマンド ........................................................................................................ 16
7. 通知 ......................................................................................................................................................16
7.1
通知起動型セッションアラートの一般的な構造 ................................................................................... 16
7.2
WAP PUSH を使った PACKAGE #0 の配信............................................................................................. 17
8. セキュリティ .........................................................................................................................................17
認証データ........................................................................................................................................... 17
8.1
認証処理 .............................................................................................................................................. 18
8.2
6.
8.2.1
8.3
8.4
パスワードと nonce の使い方 ....................................................................................................... 18
整合性 ................................................................................................................................................. 18
機密性 ................................................................................................................................................. 18
9.
市場動向 ...............................................................................................................................................18
9.1
SYNCML 搭載端末 ............................................................................................................................... 18
9.2
市場動向 .............................................................................................................................................. 19
10.
総括 ...................................................................................................................................................21
APPENDIX A サンプル DTD ファイル .......................................................................................................22
Page 1
1. はじめに
本書の目的は、SyncML DM スペックから読みとれる技術の概要を記述し、現在の市場の動向を探ることである。
SyncML Initiative, Ltd とは、データシンクロ及びデバイス管理に関するオープンスペックを策定するために共同
した企業のグループで構成される非営利団体である。SyncML が発足する前までは、データシンクロ及びデバイ
ス管理は製造者者特有の異なるプロトコルをベースとしていて、各プロトコルは限られたデバイス、システム、
及びデータタイプでのみ動作していた。これらの相互運用不可能な技術によってユーザ、製造者、サービスプロ
バイダー、及び開発者の仕事を難しくしていた。
SyncML DS スペックでは主にデータベースを更新したり、端末の情報（空きメモリ容量、各種アイテムの ID、
ローカル DB の所在、など）を交換したりすることについて規定されている。
SyncML DM スペックでは主に DM サーバが DM クライアントの DM ツリー（3章参照）を追加、変更、削除する
ことについて規定されている。
1.1
参考文献
[DMCONF]
[DMDDFDTD]
[DMPRO]
[DMSEC]
[DMSTDOBJ]
[DMREPU]
[DMTND]
[DMBOOT]
“
Device Management Conformance Requirements, Version 1.1.2”
. Open Mobile AllianceTM.
OMA-SyncML-DMConReqs-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
“
SyncML DM Device Description Framework, Version 1.1.2”
. Open Mobile AllianceTM. OMASyncML-DMDDFDTD-V1_1_2. URL:http:www.openmobilealliance.org/tech/DTD
“
SyncML Device Management Protocol, Version 1.1.2”
. Open Mobile AllianceTM. OMA-SyncMLDMProtocol-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
“
SyncML Device Management Security, Version 1.1.2”
. Open Mobile AllianceTM. OMA-SyncMLDMSecurity-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
“
SyncML Device Management Standardized Objects, Version 1.1.2”
. Open Mobile AllianceTM.
OMA-SyncML-DMStdObj-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
“
SyncML Representation Protocol, Device Management Usage, Version 1.1.2”
. Open Mobile
Alliance TM. OMA-SyncML-DMRepPro-V_1_1_2.
URL:http:www.openmobilealliance.org/tech/docs
“
SyncML Device Management Tree and Description, Version 1.1.2”
. Open Mobile Alliance TM.
OMA-SyncML-DMTND-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
“
SyncML Device Management Bootstrap, Version 1.1.2”
. Open Mobile AllianceTM. OMASyncML-DMBootstrap-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
[DMNOTI]
“
Notification Initiated Session, Version 1.1.2”
. Open Mobile AllianceTM. OMA-SyncMLDMNotification-V1_1_2. URL:http:www.openmobilealliance.org/tech/docs
Synchronica
http://www.synchronica.com/products/syncml/syncml_enabled_phones.html
ケータイ on
Business
http://keitai.nikkeibp.co.jp/kotohajime/groupware0527/index.shtml
1.2
用語
アクセス制御リスト
(Access Control List)
認証 (Authentication)
各 ID に関連付けられる ID とアクセス権のリスト
機密性
(Confidentiality)
メッセージを交換する 2 つのエンティティ以外のエンティティに内容を秘密にす
るための能力。メッセージの可視性（傍受の可能性）をなくすものではないが、
伝送されるデータの解釈は行えないようにする。結果として、機密性によって他
端末又は DM サーバの身元の確認を行うこと
Page 2
のエンティティがメッセージの内容を理解することができなくなる。
認証データ
(Credentials)
認証データは身元を証明するために必要な要素である。典型的にはユーザ名やパ
スワードなどがある。
定義フレームワーク
(Description Framework)
端末
(Device)
特定の端末タイプの DM シンタックスやセマンティックスを定義する仕様書。
端末は 1 つ又は複数のリモートエンティティ（DM サーバ）によって管理され
る。端末は様々な特性を持つことができ、DM サーバはそれらのパラメータを読
み、書き、削除、変更することができる。
DM サーバ
(Device Management Server)
DM サーバは 1 つ又は複数の端末を管理するエンティティである。端末のメンテ
ナンスを容易にすることが目的である。
動的ノード
(Dynamic node)
ノードに対する DDF の Scope プロパティが Dynamic に設定されているか何も設定
されていなければそのノードは動的である。
完全 URI
(Full device URI)
端末のコンテキストで指定される端末リソースへのフルパス。常に端末のルート
ノードからの相対 URI である。
整合性
(Integrity)
メッセージがコンテンツを維持するための能力、又は、最低でもコンテンツへの
変更や破壊を検知する能力。
インテリアノード
(Interior node)
子ノードを持てるが、値を保存できないノード。インテリアノードの Format プロ
パティは node である。
リーフノード
(Leaf node)
値を保存できるが、子ノードを持てないノード。リーフノードの Format プロパテ
ィは node 以外である。
DM クライアント
(Management client)
DM 端末内のソフトウェアコンポーネントで、SyncML DM コマンドを正しく解釈
し、適切な動作を端末内で実行し、発行側 DM サーバに適切な応答を返す。
DM オブジェクト
(Management object)
DM ツリーのサブツリーで、何らかの形で関連しているノードの集合。例え
ば、./DevInfo ノードは DM オブジェクトを構成する。単純な DM オブジェクトに
は 1 つのノードのみが含まれる。
DM サーバ
(Management server)
SyncML DM コマンドを発行するネットワークベースのエンティティで、端末から
送信された応答を正しく解釈する。
DM セッション
(Management Session)
端末と DM サーバ間で 1 つ又は複数の DM 操作を行うためにはられた継続的な接
続。
DM ツリー
(Management tree)
DM クライアントが端末とインタラクトするメカニズム。例えば、DM ツリーから
値を取得したり格納したり、そのプロパティを操作したりする。
メッセージ
(Message)
SyncML DM プロトコルの原子的な単位で、ベアラネットワークが受け付けること
ができる 1 つのパケット。1 つの SyncML DM プロトコルパッケージには複数のメ
ッセージを含むことができる。
メッセージ認証コード
（MAC）
(Message Authentication Code)
ノード
(Node)
メッセージハッシュと何らかの共有鍵をベースに演算された値。MAC はブートス
トラップパッケージとは別に伝送される。
パッケージ
(Package)
静的ノード
DM ツリーの 1 つの要素。DM ツリーではインテリアノードとリーフノードの 2 種
類のノードがある。ノードの Format プロパティによってリーフかインテリアかが
決まる。
複数のメッセージにまたがる論理的なコマンド群。
静的ノードに対する DDF の Scope プロパティが Permanent に設定されている。ノ
Page 3
(Permanent node)
ードが静的でない場合は動的である。静的ノードを削除することはできない。
リソース
(Resource)
HTTP[RFC2616]で定義されるように、URI で識別できるネットワークデータ又は
サービス。リソースは様々な方式であらわされることがある（様々な言語、デー
タ形式、サイズ、解像度、など）。
サーバ ID
(Server identifier)
DM サーバの SyncML DM における内部名称。DM サーバは SyncML DM 認証を通
じて現存するサーバ ID と関連付けられる。
1.3
略語
ACL
DDF
MAC
SyncML DM
URI
WAP
Access Control List
Device Description Framework
Message Authentication Code
SyncML Device Management
Uniform Resource Identifier
Wireless Application Protocol
Page 4
2. SyncML のネットワーク構成
以下の図は、ノキア、オラクル、及びテキサスインスツルメンツが共同して行った SyncML の企業での試験運用
の際の構成図である。SyncML を利用したネットワークの例として示す。
図 2.1：Texas Instruments における SyncML のネットワーク構成図
ノキア 9290 内の SyncML クライアントがウェブサーバを経由してインターネットを介して Sync Server に無線で
アクセスする。シンクロが完了するとモバイルユーザは最新のカレンダー情報を表示することができる。
シンクロは SMS によってクライアント又はサーバのどちらからも起動することができる。社員が自分の情報を
更新した場合はクライアントから SMS をサーバに送信し、サーバの情報を更新する。サーバの情報が更新され
たらサーバから各端末に SMS を送信し、各端末はシンクロを行う。（7章参照）
なお、ノキア 9290 はキーボードが搭載されている携帯電話である。
Page 5
3. DM ツリー
3.1
概要
DM ツリーとは、DM クライアントがデバイスとやり取りを行う（ツリーの値を格納及び取得したりそれらのプ
ロパティを操作したりする）ためのメカニズムである。デバイス内の全ての DM オブジェクトはツリー構造で整
理される。全てのノードは URI によって一意に識別できる。以下の図は DM ツリーの例を示す。
図 3.1：DM ツリーの例
3.2
ノードの特性
ノードとは、SyncML DM プロトコルを使って行われる管理動作で操作できるエンティティのことである。ノー
ドは、１つの整数からスクリーンセーバなどの複雑なものまで様々な形態を持つ。上の図の中では、四角で囲わ
れているものが全てノードである。
ノードの URI は端末のルートから開始し、各ノード名が“
で区切られて付加される。
/€35
例えば、上図の xyzInc ノードをアクセスしたい場合、アドレスは次のようになる：
./SyncML/DMAcc/xyzInc, または SyncML/DMAcc/xyzInc
3.2.1
ノードの種類
ノードには２種類ある。それらの種別はノードの Format プロパティ（3.4参照）に定義される。
インテリアノード：
子ノードを持つことができるが、値を保存することができないノード。インテリアノード
の Format プロパティは node と定義される。
Page 6
リーフノード：値を保存することができるが、子ノードを持てないノード。リーフノードの Format プロパティ
は node 以外に定義される。
また、ノードには 2 種類の属性がある。それらは DDF（3.5参照）の Scope プロパティに定義される。
静的ノード：
DDF の Scope プロパティが Permanent に設定されている場合、ノードは静的となる。静的ノー
ドは通常、製造時に作成され、削除することができない。しかし、例えば新しいハードウェア
アクセサリを端末に接続することで静的ノードを一時的に追加することは可能である。但し、
DM サーバは実行時に静的ノードを作成及び削除することはできない。なお、静的ノードは動
的ノードの子とはなれない。
動的ノード：
DDF の Scope プロパティが Dynamic に設定されているか、指定されていない場合、ノードは動
的となる。DM サーバは実行時に動的ノードを作成及び削除することができる。削除されたノ
ードに子がある場合、つまり、インテリアノードの場合は子も一緒に削除される。
3.3
ノードを操作するためのコマンド
SyncML プロトコルでは様々なコマンドがあるが、ここではノード操作のためのコマンドについてのみ記述する。
Add
新規ノードを作成する。指定した URI と同じ名前のノードが既に存在する、指定された URI でノード
を作成する権限がない、又は指定された URI を解決できない場合はエラーが返される。
Delete
ノードとその配下の子をノードのアクセス権限に応じて全て削除する。ノードの値のみを削除する場合
は Replace コマンドを使う。
Get
DM ツリーの構造を把握するために使う。URI を指定して Get コマンドを発行すると、インテリアノー
ドの場合は子ノード名のリストが、リーフノードの場合は値が返される。
Replace 既存のノードの値を上書きする。指定したノードが存在しない場合、新規に作成してはならない。新し
く指定した名前が既に存在する場合はエラーが返される。
3.4
ノードのプロパティ
ノードのプロパティは当該ノードに関するメタ情報を提供するために使われる。以下に示すプロパティは実行時
プロパティで、関連するノードの寿命の間のみ有効である。新規プロパティを作成することはできない。
以下にプロパティ一覧と適用できるコマンドの表を示す。
プロパティ
ACL
Format
Name
Size
Title
説明
アクセス制御リスト
（Access Control List ）
ノード値を解釈する方法
を定義する
ツリー内のノード名
ノードのサイズ（バイト
単位）
人間が理解できる名前
適用できる
コマンド
Get, Replace
Get
Get, Replace
Get
Get, Replace
コメント
ACL 操作においては Get と Replace のみが有効であ
る。なお、Replace は常に ACL を完全に置換する。
関連ノードに対する Add 及び Replace コマンドによ
って自動的に更新される。
Replace はノードの名前を変更する。静的ノードの場
合は変更不可。
端末によって自動的に更新される。
サーバ動作またはソフトバージョン更新時のみ更新
される。
Page 7
TStamp
Type
VerNo
最後の更新のタイムスタ
ンプ、日付、時刻
ノード値の MIME タイ
プ
バージョン番号、更新毎
に自動的に加算される
Get
端末によって自動的に更新される。
Get
関連リーフノードに対する Add 及び Replace コマン
ドによって自動的に更新される。
端末によって自動的に更新される。
Get
表 3.1：ノードのプロパティ
プロパティはAddコマンドをサポートしない。全ての必須プロパティ及びオプションプロパティは新規ノードが
作成された時に自動的に作成される。新規ノードのプロパティの値は全て空（例：<Data/>）である。但し、デ
フォルト値を持つノードや端末が自動的に更新するノードに関しては端末が適切な値を割り当てる。
3.4.1
ACL
ACL とはアクセス制御リストの略で、SyncML DM サーバを識別するサーバ ID に対して付与したアクセス権を定
義する。
以下の図は各ノードの ACL を記述した例である。
図 3.2：ACL を記述した DM ツリーの例
ACL プロパティは必須だが、全てのノードで ACL に値を割り当てているとは限らない。しかし、ルートノード
は常に ACL 値を持つ。ACL 値が設定されていないノードに対してサーバが操作を行った場合、親ノードの値を
見る。親ノードにも値がなければその親、またその親、と ACL が見つかるまで探す。ルートノードは必ず値を
持つので必ず値にたどり着ける。つまり、ACL 値は継承することができる。
Page 8
継承は、ACL プロパティの値が全くない時のみ適用される。1 つでも値があればそれがそのノードに適用される。
ACL 値はカレントノードとその親との連結には絶対にならない。
上図の DM ツリーに関する以下の記述は全て真である：
・全てのサーバが./NodeA/Node1 の値を取得することができるが、ServerC のみが一度の操作
で./NodeA/Node1?prop=ACL を変更できる。
・どのサーバも./NodeA/Node1 の値を削除又は置換することができない。
・./NodeA/Node1?prop=ACL に対する Get 要求は Get=*を返す。
・./NodeB/Node3/Node4?prop=ACL に対する Get 要求では何も返されない。
・サーバ A からの./NodeB/Node3/Node5 に対する Replace 要求は成功する。
3.4.2
Format
Format プロパティはカレントの node 値のデータフォーマットに関する情報を維持する。可能なフォーマット
は：(b64 | bin | bool | chr | int | node | null | xml) である。インテリアノードの場合の値は必ず「node」となる。なお、
b64 は Meta Format タグでのみ使われる。Meta Type の Mime Type にバイナリ形式のデータであると示されている
ときに XML で送信された場合、Meta Format は b64 でなければならない。このデータを受信した側はデータをデ
コードして Format プロパティを bin にする。そのため、そのノードに Get コマンドを発行すると必ず bin が返っ
てくる。
3.4.3
Name
DM ツリーではこの名前でノードをアドレッシングする。新規ノードを作成した場合、Name プロパティの値には
ターゲット URI の最終セグメントの値を割り当てる。Replace コマンドを受けた場合、端末はその結果としてツ
リー内で名前が重複しないことを確認する必要がある。
3.4.4
Size
Size プロパティはノード値のカレントサイズを格納する。値は 32 ビットの符号なし int 型で、サイズをバイト単
位で示す。リーフノードに Add、Copy、Replace コマンドの権限が付与されている場合、クライアント側がノー
ドの Size プロパティを更新する責任を持つ。
3.4.5
Title
Title プロパティは人間が読める形のノードに関する情報を提供する英数字文字列である。最大長は 255 バイトで
ある。
3.4.6
TStamp
このプロパティを持つノードの値が最後に更新された日付と時刻を記録する。UTC ベースの ISO 8601 基本フォ
ーマット形式で表され、例えば 20010711T163817Z は 2001 年 7 月 11 日 16 時 38 分 17 秒を示す。
Page 9
3.4.7
Type
リーフオブジェクトの場合、Type プロパティはオブジェクトの値としてどの MIME タイプのデータが格納され
ているかを定義する。インテリアオブジェクトの場合、カレントオブジェクトを定義する DDF 文書の名前を表
す。インテリアオブジェクトの場合は空でも良い。
3.4.8
VerNo
VerNoは16ビット符号なしint型で、ノードの値が更新されるたびにインクリメントされる。値がFFFF16になると、
次は000016に戻る。
3.5
DDF（Device Description Framework）
DDF（デバイス定義フレームワーク）とは、端末メーカが自分の作った端末を説明する方法を規定することで
DM システムが端末を管理する方法を理解できるようにするためのものである。また、SyncML DM をベースとし
た総合管理システムが柔軟で拡張しやすくすることを目的としている。DDF は XML DTD で書かれ、DM ツリー
の内容がこの文書で定義される。サンプル DTD は Appendix A 参照。
4. DM オブジェクト
DM オブジェクトとは、SyncML DM プロトコルを通じて操作可能なエンティティのことである。つまり、上述し
たノードのことである。DM オブジェクトは SyncML DM DDF を使って定義される。
4.1
DM オブジェクトの種類
DM オブジェクトの種類を以下の表に示す。
DM オブジェクト
SyncML DM
DevInfo
DevDetail
説明
管理される端末の SyncML DM クライアントの設定
SyncML DM サーバ用の端末情報。クライアントからサーバに送信される。
標準化によって恩恵を受ける一般的な端末情報。
表 4.1：SyncML DM オブジェクト
4.1.1
SyncML DM オブジェクト
この DM オブジェクトは SyncML DM プロトコルの設定を管理するために使われる。このオブジェクトは
SyncML DM 端末をブートストラップするためにも使われる。以下の図は SyncML DM オブジェクトの概要を示す。
Page 10
図 4.1：SyncML DM オブジェクト概略図
Page 11
SyncML DM オブジェクトは 2 つの部分で構成される。1 つ目は SyncML DM 特有の設定が格納される DMAcc ノ
ードである。これらの設定を総称して SyncML DM アカウントと呼ぶ。2 つ目は Con ノードで、SyncML DM サ
ーバと通信する時の接続性設定が格納される。Con ノードのサブツリーは一般的な接続性 DM オブジェクトと似
ていて、WAP プロビジョニングパラメータと特に似ている。従って WAP プロビジョニングを使う場合はこの場
所に接続性設定を置く必要はなく、ConRef が WAP プロビジョニング設定を指すようにすれば良い。
SyncML DM のノードには以下の意味がある：（なお、URI は./SyncML をベース URI とした相対 URI である）
DMAcc：このインテリアノードは SyncML DM アカウントノード全てに共通する親ノードである。
DMAcc/x：このインテリアノードは複数の SyncML DM アカウントがある場合に識別することができる。ノード
名はブートストラップ時にサーバによって命名される。
DMAcc/x/Addr：このノードでは様々なアドレスを格納できる。格納されるアドレスの種別は
DMAcc/x/AddrType ノードの値で特定される。
DMAcc/x/AddrType：このノードでは DMAcc/x/Addr ノード値のフォーマット及び解釈方法を指定する。値は
数値で、以下の表のようにインライン文字列としてエンコードされる。なお、クオートは含まれない。
Address Type
HTTP
WSP
OBEX
Value
'1'
'2'
'3'
Description
A URL, [RFC2396].
A URL, [RFC2396].
DMAcc/x/PortNbr：このノードはカレントのベアラで使用するポート番号を指定する。
DMAcc/x/ConRef：このノードは端末内の他の場所に格納されている接続性情報へのポインタを格納する。
DMAcc/x/ServerId：このノードはカレントの SyncML DM アカウントのサーバ ID を格納する。この値はブート
ストラップ時に設定され、通常の SyncML DM セッションでは変更できない。
DMAcc/x/ServerPW：このノードはサーバがクライアントと認証するときに使うパスワードや秘密鍵を格納する。
DMAcc/x/ServerNonce：このノードはサーバがクライアントと認証するために使う次の nonce（ナンス？ノン
ス？：その時だけ有効な情報）を格納する。
DMAcc/x/UserName：このノードは SyncML DM 認証で使うユーザ名（又は端末名）を格納する。
DMAcc/x/ClientPW：このノードはクライアントがサーバと認証する時に使うパスワードや秘密鍵を格納する。
DMAcc/x/ClientNonce：このノードはクライアントがサーバと認証するために使う次の nonce を格納する。
DMAcc/x/AuthPref：SyncML 認証タイプを保存する文字列パラメータが格納される。例： "syncml:auth-md5"
DMAcc/x/Name：このノードはオプションで、ユーザに表示可能なカレントの SyncML DM アカウントの名前を
格納する。
Con ：このインテリアノードは接続性ノード全てに共通する親ノードである。
Con/w：このインテリアノードは上記 x ノードと同様に複数の接続性ノードを識別する。SyncML DM アカウント
と接続性ノードを論理的にリンク付けるためにはこのノード名を DMAcc/x/ConRef ノードと同じにする、
つまり、(Con/w)の名前 = (DMAcc/x/ConRef)の値とする。
Con/w/NAP/Bearer：このノードは接続情報のベアラタイプを指定する。
Con/w/NAP/AddrType：このノードは接続情報のアドレスタイプ値を指定する。
Page 12
Con/w/NAP/Addr：リモートエンティティと通信するために必要な全てのディジットとポーズが含まれる。ノー
ドのフォーマット及び内容はベアラタイプに依存する。このノードでは例えばアクセスルータの電話番号、
GPRS APN、SMSC のアドレス、などが含まれる。
Con/w/NAP/Auth/y：このインテリアノードは NAP 認証方法を指定する。このノードの名前は“
PAP€35
又は“
CHAP€35
とする。
Con/w/NAP/Auth/y/Id：NAP 認証 ID を指定する。例：ユーザ名。
Con/w/NAP/Auth/y/Secret：NAP 認証鍵を指定する。例：パスワード。
Con/w/PX/PortNbr：このノードは使用するポート番号を指定する。
Con/w/PX/AddrType：このノードは Con/w/PX/Addr ノード値のフォーマットと解釈方法を指定する。
Con/w/PX/Addr：このノードには AddrType に従った種類のアドレスを保存する。
Con/w/PX/Auth/z：このインテリアノードは NAP 認証方法を定義する。“
HTTP_BASIC”
,“
HTTP_DIGEST”又は
“
WTLS_SS€35
という名前にすること。
Con/w/PX/Auth/z/Id：プロキシ認証 ID、例：ユーザ名、を指定する。
Con/w/PX/Auth/z/Secret：プロキシ認証鍵、例：パスワード、を指定する。
Con/w/Ext：オプションのインテリアノードで、SyncML DM オブジェクトのサブツリーとして拡張を静的又は動
的に追加することができる。
4.1.2
DevInfo DM オブジェクト
以下の図は DevInfo DM オブジェクトの概略を示す。
図 4.2：DevInfo DM オブジェクト
Page 13
以下にノードの意味を記述する：
Ext：オプションのインテリアノードで拡張を静的又は動的に追加できる DevInfo サブツリーの唯一のブランチで
ある。
Bearer：オプションのインテリアノードで、ベアラ（CDMA、など）に関する情報が格納される。
DevId：端末の一意の ID
Man：メーカ ID
Mod：モデル ID
DmV：SyncML DM クライアントバージョン ID
Lang：端末のカレントの言語設定
4.1.3
DevDetail DM オブジェクト
以下の図は DevDetail DM オブジェクトの概略を示す。
図 4.3 DevDetail DM オブジェクト
以下にノードの意味を記述する：
Page 14
Ext：オプションのインテリアノードで拡張を静的又は動的に追加できる DevDetail サブツリーの唯一のブランチ
である。
Bearer：オプションのインテリアノードで、ベアラ（CDMA、など）に関する情報が格納される。
URI/MaxDepth：端末がサポートする DM ツリーの最大深度、つまり URI セグメント数、を定義する。0 は無限
を意味する。
URI/MaxTotLen：ノード又はノードプロパティをアドレッシングする URI の最大総長を定義する。
URI/MaxSegLen：ノード又はノードプロパティをアドレッシングする URI のセグメントの最大長を定義する。
DevTyp：端末の種類、例：PDA、ポケベル、電話、など。
OEM：元々機械を製造した会社名
FwV：ファームウェアバージョン
SwV：ソフトウェアバージョン
HwV：ハードウェアバージョン
LrgObj：SyncML Large Object Handling 仕様をサポートするかどうかを定義する。
5. ブートストラップ（初期プロビジョニング）
ブートストラップとは、一般的にはコンピュータを起動する過程を指す。たとえば PC 互換機では、電源投入時
にはまずシステム ROM 内の小さなコードが実行され、各種デバイスの初期化が行なわれる。続いてこのコード
は、ディスク内にある OS の初期コードに制御を移す。このように、より高レベルなソフトウェアを実行するた
めに、段階を追って初期化を行うことをブートストラップという。SyncML DM の場合は、DM 端末が「空」の状
態から DM サーバと DM セッションをはれるようになるまでの過程を指す。
5.1
5.1.1
実現方法
カスタマイズブートストラップ
この方法では、オペレータが端末メーカから初期設定済みの電話を注文する。オペレータのネットワークとDM
インフラに関する情報は工場出荷時に既に設定されている。この方法だと鍵などをOTAで運ぶことがないのでと
てもセキュアである。しかし、柔軟性が低い上、全てのメーカが対応してくれるとは限らない。
5.1.2
サーバ起動型ブートストラップ
この方法では、端末は空の状態で工場から出荷される。ユーザが端末に SIM を装着するなどしてパーソナライズ
すると、ブートストラップ処理の起動の準備が整う。次にサーバに ID やアドレス、電話番号を伝えるのだが、
それには様々な手段がある：
・販売店で販売システムから管理システムにつないで情報を配信する。
・セルフサービスウェブサイトからユーザが自分で情報を入力する。
・ネットワークに最初にアタッチした時にネットワーク側が情報を取得する。
Page 15
・音声プロンプトシステムで DTMF を使って電話番号を入力する。
いずれの方法を使ったとしても、サーバ側にIDが届いたらサーバはSyncML DMブートストラップメッセージ
（次章のブートストラッププロファイル）を送信する。
5.2
ブートストラッププロファイル
SyncML DMでは様々な端末においてDM要件を満たすためにいろいろ考えているが、現在では主にWAPプロファ
イルを流用する方針である。但し、下位互換性を保つためにプレーンプロファイルというのもあるが、それは後
の版では削除する方向で進めている。
5.2.1
WAP プロファイル
このプロファイルでは OMA プロビジョニングアーキテクチャーを使って SyncML DM をプロビジョニングする
方法を定義する。このプロファイルは WAP プロビジョニングコンテンツフォーマット[PROVCONT]に対するい
くつかの拡張パラメータとその使用方法を定義する。このプロファイルを使うことが推奨される。
DMのDMAccサブツリーはw7 APPLICATION特性の値を使って初期化され、DMクライアントが作成する。Conサ
ブツリーはDMAccサブツリーのConRef値を空にして省略することができる。ConRef値を省略する場合、クライ
アントはDMツリーの外部のプロビジョニングコンテンツ（例：PXLOGICALやNAPDEF）で生成された接続デー
タを使うことができる。
5.2.2
プレーンプロファイル
このプロファイルは SyncML DM フォーマットを使って SyncML DM オブジェクトをブートストラップする方法
を規定する。このタイプのブートストラップメッセージは OBEX や WAP push で伝送できるが、将来的にはスペ
ックから削除される方針である。
6. プロトコル
SyncML DM プロトコルによってノードに対して管理コマンドを実行することができるようになる。SyncML シン
クロプロトコルや SyncML 表現プロトコルに似たパッケージ形式を使う。端末の設定値を格納するノードに対し
てはパラメータキーや値を読み書きすることができる。端末上のソフトウェアアプリの実行環境を格納するノー
ドに対してはソフトウェア要素をインストール、アップグレード、アンインストールすることができる。
6.1
ノードアドレッシング
各ノードは一意の完全 URI でアドレッシングする。各ノードにはそのオブジェクトに対してどのような DM コン
テンツが読み書きできるのかを定義するタイプが割り当てられている。例えば、あるノードが「text/plain」とい
うタイプである場合、テキスト値を設定することができ、他のノードが WAP プロビジョニング文書タイプなど
の複雑なタイプである場合は WAP プロビジョニング文書 MIME タイプの値を設定できる。
SyncML DM プロトコルの場合、コマンドの宛先及び送信元は Target 及び Source 要素で識別される。Target は受
信側を意味し、Source は送信側を意味する。
Page 16
6.2
SyncML DM プロトコルパッケージ
SyncML DM プロトコルは複数の SyncML メッセージを使って 1 つの SyncML パッケージを伝送する機能を提供
する。これは、トランスポートレイヤや端末の制限などで 1 つの SyncML パッケージを 1 つの SyncML メッセー
ジで伝送するには大き過ぎる場合に役立つ。
6.3
認証
SyncML DM プロトコルは SyncML 認証フレームワークを拡張して使う。この節では SyncML レベルとトランス
ポートレベルの認証が使われる時のルールについて記述する。
SyncML DM プロトコルクライアントとサーバの両方がお互いを証明しあっていなければならない。但し、認証
は異なるレベルで行うことができる。トランスポートレベルで認証メカニズムが実装済みの場合、SyncML DM
プロトコルレベルでの認証を省略してもよいが、十分な強度のものがない場合は SyncML DM プロトコルレベル
の認証が使われる。通常は TLS や WTLS のようなセッションレベルの認証を提供するトランスポートプロトコ
ルの上で動作することを想定しているため、認証データはセッションの最初でのみ交換されるが、トランスポー
トレベルの認証がない場合は要求ごとに認証しなければならない。サーバが優先する認証方法は
DMAcc/x/AuthPref パラメータを使ってクライアントに指示される。
6.4
ユーザインタラクションコマンド
SyncML DM プロトコルでは例えば DM 操作に対するユーザ確認を得るための以下のようなユーザインタラクシ
ョンの方法を定義している。
・ユーザ表示可能な通知とそれに関連する動作
・特定の管理操作を実行しても良いというユーザからの承認
・管理操作に関するなんらかの入力を促すプロンプトの表示
・いくつかの項目の中からいずれかを選択するように促すプロンプトの表示
・特定の動作に関する進行状況を示すプログレス通知の表示
7. 通知
「通知（Notification）」とは、SMS やその他データグラムメッセージなどによるメッセージのことで、常にサー
バに接続していなくても届く。DM サーバはこの通知能力を使ってクライアントがサーバに接続するよう促すこ
とができる。そのような「通知起動型アラート」の中身は空でも、メッセージそのものに署名をつけることでク
ライアントがサーバを認証することができる。そのような通知を受けた結果としてクライアントは送信側の DM
サーバに接続することができる。
7.1
通知起動型セッションアラートの一般的な構造
通知起動型セッショントリガメッセージで使われるデフォルトフォーマットは General Package#0 である。
Page 17
以下の図で General Package#0 の内容を示す。
図 7.1：一般通知トリガメッセージ(Package#0)のフォーマット
一般通知起動型セッションアラートメッセージの MIME タイプは application/vnd.syncml.notification で、ContentType コードは 0x44 である。
7.2
WAP push を使った Package #0 の配信
WAP push フレームワークでは PI（Push Initiator）が PPG（Push Proxy Gateway）を介して非同期的に携帯端末に
情報を送信する手段を提供している。SyncML DM サーバは PI として動作することが想定されるが、PPG として
動作すればサーバが直接携帯端末と通信することも可能である。
Package #0 を送信するために WAP push フレームワークが使われる場合、非セキュアの非接続型 WSP セッション
サービスが使われる。
8. セキュリティ
SyncML DMの目的は、SyncML DMプロトコルをサポートする全ての端末に対してリモート管理能力を提供する
ことである。交換される情報には機密性の高いものも含まれるため、セキュリティは十分考慮する必要がある。
8.1
認証データ
端末と DM サーバ間で交換される認証データは基本的には以下から抽出される：
・サーバ ID（DM サーバを識別する一意の ID）
・DM サーバが端末を識別するユーザ名
・ユーザ名又はサーバ ID と共に使うパスワード
・リプレイアタックから逃れるための nonce
端末からサーバに認証してもらう場合、ユーザ名、パスワード、nonce が必要である。
サーバから端末に認証してもらう場合、サーバ ID、パスワード、nonce が必要である。サーバはクライアント毎
に異なるパスワードを使うこと。
SyncML DMにおける全てのセキュリティは上記４つの認証データに基づく。
Page 18
8.2
認証処理
SyncML DM ではクライアントとサーバのどちらもチャレンジを開始することができる。syncml:auth-md5 タイプ
をサポートしなければならない。
8.2.1
パスワードと nonce の使い方
パスワードと nonce は最低 128 ビット（16 乱数オクテット）とすることが推奨される。nonce 値はチャレンジ毎
に必ず発行される。チャレンジが発行される前に認証データが送信されている場合、最後に使われた nonce を再
度使用する。認証する側は認証データの発行側が不正な nonce を使っている可能性があることに注意しなければ
ならない。そのため、認証が失敗した場合、もう一度チャレンジして新しい nonce を提供しなければならない。
セッションごとに新しい nonce を使うべきである。nonce 値のシーケンスは予測が難しくなければならない。
8.3
整合性
SyncML DMメッセージの整合性はHMAC-MD5 [RFC2104]を使って保たれる。整合性チェックは認証チャレンジ
と同じように、同じ時に要求される。syncml:auth-MACとして発行されたチャレンジではsyncml:auth-md5と同じ
Type、Format、NextNonceのMetaデータを使う。チャレンジの受信側が要求された認証タイプで応答しなければ
セッションは終了される。例えば、HMACで要求されたチャレンジに対してBasic Authenticationの認証データで
応答した場合はたとえ認証データが有効であってもセッションは終了される。
8.4
機密性
SyncML DMにおける機密性には2つの主な特徴がある：伝送プロトコル上を移動する情報の機密性の確保、及び
DMサーバ間における情報の機密性の確保、である。
SyncML DM自体は端末と DMサーバ間を行き来するデータの機密性を確保するための能力を持たないが、
SyncML DMはいくつかの技術と互換性を持つ。1つはTLSやHTTPSなどの暗号化をサポートする伝送レイヤのプ
ロトコルの使用である。もう1つはDMオブジェクトを暗号化した状態で暗号化をサポートしない伝送レイヤで送
受信することである。この場合、暗号化されたオブジェクトを受信した時に暗号解除してもよいし、そのまま
DMツリー内に格納しても良い。
SyncML DMではDMサーバが持つデータを他のDMサーバからプライベートにすることができる。これはDMオブ
ジェクトのアクセス権を定義するACL（アクセス制御リスト、3.4.1参照）を使うことで簡単に実現できる。
9. 市場動向
9.1
SyncML 搭載端末
http://www.synchronica.com/products/syncml/syncml_enabled_phones.html
からの抜粋を掲載する。
いつの情報かは明記されていないが、パナソニックの X70 が掲載されていることから、少なくとも 2003 年以降
の情報と思われる。
Siemens：M55、S55、S56 (US)、MC60、SL55、SL56、SX1、CX65
Page 19
Nokia：3300 (US)、3595 (US)、3650、3660、6108 (Asia)、6200 (Am)、6220、6230、6600、6800、
6810、6820、7200、7250、7250i、7600、7650、7700、9210、9210i、9290 (US)、9500、N-Gage
SonyEricsson：T62u (US)、T68i、P800、P900、T610、T616 (US)、T630、Z600、Z1010
Ericsson：T39、T65、T68
Motorola：T720、V300、V400、V500
Kyocera：SE47 (US)、KX414 (US)、7135 (US)
Alcatel：OT715
LG：VX4400、VX6000
Samsung：A530、A610 (US)
Panasonic：X70
9.2
市場動向
以下に日経 BP 社発行の「ケータイ on Business」の記事からの抜粋を掲載する。この記事は SyncML をソリュー
ションとして紹介するものではないが、この例は SyncML の典型的なユースケースといえる。
http://keitai.nikkeibp.co.jp/kotohajime/groupware0527/index.shtml からの抜粋
[2004/05/27]
グループウエアをケータイから使うには
メールに加えてスケジュール共有や電子掲示板，ワークフロー管理など，部署内や全社レベルでの共同作業を支援するグループウエア。多く
の企業が社内ネットワークで活用しているアプリケーションである。
業務の効率化に欠かせないだけに，オフィスに在席しているときはもちろん，外出先でも利用できれば，いっそう効果を発揮する。しかしそ
のために毎日，重いノート・パソコンを持ち歩くのは面倒。いざ使おうと思っても，パソコンが起動するまでの時間を考えると，空き時間にさ
っと見るというわけにもいかない。
携帯電話からグループウエアにアクセスできれば，こうした悩みは解決する。常に身に付けている軽量なツールであるうえ，パソコンのよう
な“
起動”
も不要だ。場所を問わずに素早く社内にある情報を活用できる。
出先からも会議の設定や顧客アドレスの検索，決裁まで可能
携帯電話をグループウエアと連携させると，さまざまなメリットが得られる（図 1）。
Page 20
図 1 グループウエアを携帯電話から使いこなす
社外からグループウエア・システムにアクセスできれば，さまざまな業務が効率化で
きる。
一つはメール。外出先でメールが確認できれば，重要な連絡などを逃さずに済む。メールに記載された電話番号などを“
クリック”
するだけで，
その電話番号に発信できる製品も多く，携帯電話ならではの使い勝手のよさと言える。
二つめはスケジュールやアドレス帳といった，いわゆる PIM（個人情報管理）データへのアクセスである。社内で共有しているスケジュール
ならば外出先から会議の設定もできるし，急な連絡が必要になった顧客の電話番号やメール・アドレスを共有アドレス帳で調べることも可能だ。
承認・決裁といったワークフローの処理が三つめのポイント。管理職が外出がちだと，さまざまなワークフローが滞りやすい。携帯電話でワ
ークフローの処理ができると，管理職が在席していなくても業務が進むことになる。管理職にとっても，実務担当者にとっても，効率が上がる
ことは間違いない。顧客や取引先の満足度向上にもつながる。
そのほか，電子掲示板などに掲示してある共有データにアクセスできれば，「データを調べて出直す」といったことも少なくなる。
携帯電話からグループウエアにアクセスする方法は 2 種類
グループウエアを携帯電話から使えるようにするには，基本的にグループウエア・サーバーのデータを携帯電話で表示させる仕組みを導入す
ればいい。
代表的なグループウエア・ソフトは，モバイル環境からの利用を想定した機能やオプションを備える製品が多い。ノート・パソコンや PDA
（携帯情報端末）に携帯電話や PHS のカード型端末を挿入して利用するだけでなく，携帯電話そのものから社内のグループウエア・システムに
アクセスできるのである。
携帯電話からのアクセス手法は大きく 2 通りに分類できる。携帯電話のブラウザ機能を使って Web ページとして表示する「Web 方式」と，携
帯電話に専用アプリケーションをダウンロードして組み込みデータを蓄積する「アプリ方式」である（図 2）。
Page 21
図 2 グループウエアと携帯電話を連携させる手法は大きく 2 通りある
「Web 方式」は携帯電話のブラウザでデータを閲覧，「アプリ方式」は携帯電話にあらかじめダウ
ンロードしたアプリでデータを取得する。
※ この「アプリ方式」というのを SyncML の技術を使って実現できる。
10.総括
9.2章のユースケースからもわかるように、現代のユーザにとって常に最新の情報を共有することは必須とも言え
る。現状では SyncML 以外にも様々なソリューションが提供されるが、ハード及びソフトベンダー、オペレータ、
プロバイダ、等、多くの登場人物が介在するために導入するにはまだまだコストがかかる。しかし、その利便性
から今後多くの企業が導入を進めていくことが十分に予想される。安価で小規模な仕組みを開発すれば参入する
余地は十分にあると思われる。試しにフジシステムズのグループウエアに携帯電話からアクセスできる仕組みを
開発してみてはいかがだろうか。
Page 22
Appendix A サンプル DTD ファイル
<!-SyncML DM Device Description Framework (SYNCML-DMDDF) V1.1.2 Document Type Definition, modified 02 December 2003.
Copyright Open Mobile Alliance Ltd., 2003-2004
All rights reserved
This DTD defines the device description framework that is used within
the SyncML Dvice Management Protocol. Typical usage:
<!DOCTYPE MgmtTree PUBLIC "-//OMA//DTD SYNCML-DMDDF 1.1.2//EN"
"http://www.openmobilealliance.org/tech/DTD/OMA-SyncML-DMDDF-1_1_2.dtd"
[<?oma-syncml-dmddf-ver supported-versions="1.1.2"?>]>
<MgmtTree>
...
</MgmtTree>
Terms and conditions of use are available from the
Open Mobile Alliance Ltd. web site at
http://www.openmobilealliance.org/useterms.html
-->

<!ELEMENT MgmtTree (VerDTD, Man?, Mod?, Node+)>

<!ELEMENT VerDTD (#PCDATA)>
<!ELEMENT Man (#PCDATA)>
<!ELEMENT Mod (#PCDATA)>

<!ELEMENT Node (NodeName, Path?, RTProperties?, DFProperties, (Node* | Value?))>

<!ELEMENT NodeName (#PCDATA)>

<!ELEMENT Path (#PCDATA)>
<!ELEMENT Value (#PCDATA)>

<!ELEMENT RTProperties (ACL, Format, Name, Size?, Title?, TStamp?, Type, VerNo?)>

<!ELEMENT ACL (#PCDATA)>
<!ELEMENT Format (b64 | bin | bool | chr | int | node | null | xml)>
<!ELEMENT b64 EMPTY>
<!ELEMENT bin EMPTY>
<!ELEMENT bool EMPTY>
<!ELEMENT chr EMPTY>
<!ELEMENT int EMPTY>
<!ELEMENT node EMPTY>
<!ELEMENT null EMPTY>
<!ELEMENT xml EMPTY>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT Size (#PCDATA)>
<!ELEMENT Title (#PCDATA)>
<!ELEMENT TStamp (#PCDATA)>

<!ELEMENT Type (MIME | DDFName)>
<!ELEMENT MIME (#PCDATA)>
<!ELEMENT DDFName (#PCDATA)>
<!ELEMENT VerNo (#PCDATA)>

<!ELEMENT DFProperties (AccessType, DefaultValue?, Description?, DFFormat, Occurrence?, Scope?, DFTitle?, DFType)>
<!ELEMENT AccessType (Add?, Copy?, Delete?, Exec?, Get?, Replace?)>
<!ELEMENT Add EMPTY>
<!ELEMENT Copy EMPTY>
Page 23
<!ELEMENT Delete EMPTY>
<!ELEMENT Exec EMPTY>
<!ELEMENT Get EMPTY>
<!ELEMENT Replace EMPTY>
<!ELEMENT DefaultValue (#PCDATA)>
<!ELEMENT Description (#PCDATA)>

<!ELEMENT DFFormat (b64 | bin | bool | chr | int | node | null | xml)>

<!ELEMENT Occurrence (One | ZeroOrOne | ZeroOrMore | OneOrMore | ZeroOrN | OneOrN)>
<!ELEMENT One EMPTY>
<!ELEMENT ZeroOrOne EMPTY>
<!ELEMENT ZeroOrMore EMPTY>
<!ELEMENT OneOrMore EMPTY>

<!ELEMENT ZeroOrN (#PCDATA)>
<!ELEMENT OneOrN (#PCDATA)>
<!ELEMENT Scope (Permanent | Dynamic)>
<!ELEMENT Permanent EMPTY>
<!ELEMENT Dynamic EMPTY>
<!ELEMENT DFTitle (#PCDATA)>
<!ELEMENT DFType (MIME+ | DDFName)>

Download Report