机密▲
SyncMLDeviceManagementStandardizedObjectsVersion1_2
Approvedversion1.2-09Feb-2007
OpenMobileAlliance
OMA-SyncML-DMStdObj-V1_2-20070209-A
<本文中的所有信息均为中兴通讯股份有限公司内部信息,不得向外传播。>目录
1 范围 1
2 参考资料 2
2.1 标准 2
2.2 资料 2
3 术语和约定 3
3.1 约定 3
3.2 定义 3
3.3 缩略语 3
4 介绍 3
5 标准对象 3
5.1 管理对象 3
5.1.1 管理对象的定义和描述 3
5.1.2 DDFcompliance 5
5.2 其它组织制定的管理对象标准 6
5.3 OMADM管理对象 6
5.3.1 DMACC管理对象 7
5.3.2 DevInfo管理对象 10
5.3.3 DevDetail管理对象 11
5.3.4 TheInboxURI 14
6附录 15
范围
本文档定义了一套管理对象。对OMADM来说有些是必选的，有些是可选的。这些对象在OMADMDeviceDescriptionFramework中定义。
SyncML是许多公司联合起来为解决数据同步和终端管理的非营利机构。在SyncML之前，数据同步和终端管理建立在一套相异的私有协议之上，每个功能都只具有少数的设备、系统和数据类型，这些相互独立的技术使得用户、厂商、服务供应商和开发者的工作都变得复杂。同时，随着用户私有数据增加，终端管理协议就限制了用户移动设备的扩展，减小了用户使用的灵活性。
SyncML组件：
AnXML-basedrepresentationprotocol
一个基于XML的描述协议
Asynchronizationprotocolandadevicemanagementprotocol
同步协议和设备管理协议
Transportbindingsfortheprotocol
协议的捆绑传输
Adevicedescriptionframeworkfordevicemanagement
设备管理的描述框架
参考资料
标准
[DMBOOT] “SyncMLDeviceManagementBootstrap,Version1.1.2”.OpenMobileAlliance?.OMA-SyncML-DMBootstrap-V1_1_2.URL:http:www.openmobilealliance.org/tech/docs [DMCONF] “DeviceManagementConformanceRequirements,Version1.1.2”.OpenMobileAlliance?.OMA-SyncML-DMConReqs-V1_1_2.URL:http:www.openmobilealliance.org/tech/docs [DMPRO] “SyncMLDeviceManagementProtocol,Version1.1.2”.OpenMobileAlliance?.OMA-SyncML-DMProtocol-V1_1_2.URL:http:www.openmobilealliance.org/tech/docs [DMTND] “SyncMLDeviceManagementTreeandDescription,Version1.1.2”.OpenMobileAlliance?.OMA-SyncML-DMTND-V1_1_2.URL:http:www.openmobilealliance.org/tech/docs [GFS] “GeneralformatsSpecifications”.OpenMobileAlliance?.WAP-188-WAPGenFormats.URL:http:www.openmobilealliance.org/tech/docs [RFC1766] “TagsfortheIdentificationofLanguages”.H.Alvestrand.March1995.URL:http://www.ietf.org/rfc/rfc1766.txt [RFC2119] “KeywordsforuseinRFCstoIndicateRequirementLevels”.S.Bradner.March1997.URL:http://www.ietf.org/rfc/rfc2119.txt [RFC2373] “InternetProtocolVersion6AddressingArchitecture”.R.HindenandS.Deering.July1998.URL:http://www.ietf.org/rfc/rfc2373.txt [RFC2396] “UniformResourceIdentifiers(URI):GenericSyntax”.T.Berners-Lee,R.Fielding,L.Masinter.August1998.URL:http://www.ietf.org/rfc/rfc2396.txt [RFC791] “InternetProtocol:DarpaInternetProtocolProgramSpecification”.September1981.URL:http://www.ietf.org/rfc/rfc791.txt [SYNCDEV] “SyncMLDeviceInformation,version1.1.2”.OpenMobileAlliance?.OMA-SyncML-DevInfo-V1_1_2.URL:http:www.openmobilealliance.org/tech/docs [DMDDFDTD] “SyncMLDMDeviceDescriptionFramework,Version1.1.2”.OpenMobileAllianceTM.
OMA-SyncML-DMDDFDTD-V1_1_2.
URL:http:www.openmobilealliance.org/tech/DTD 资料
无
术语和约定
约定
本文档中，关键字MUST、MUSTNOT、REQUIRED、SHALL、SHALLNOT、SHOULD、SHOULDNOT、RECOMMENDED、MAY以及OPTIONAL等的说明参见RFC2119。
本文档中，除了“范围”以及“介绍”两个章节外，其余各章节均为标准化的（normative），除非在文中特别注明为（informative）。
定义
相关管理树的术语参见DMTND。
缩略语
无
介绍
某些SyncMLDM规范定义了OMDDM协议的语法和语义。但是如果被管理的实体要求显示不同风格以及不同时间格式，那些规范就存在局限性。为了避免这种情况，本规范定义了设备中用到的大量必选的管理对象。这些对象以SyncMLDM和SyncML配置为基础。
由于设备厂商总会增加新功能，这些功能都是私有性质的，没有标准的管理对象。为了让这些功能易于管理，就出现了一个可向服务器传送必要的信息的设备描述框架，设备厂商就可以在出厂时标明设备的描述信息。设备管理服务器仅通过传送新的描述到服务器，服务器就能自动识别和管理这些新功能。
标准对象
管理对象
管理对象是SyncMLDM协议中便于管理的实体。一个管理对象可以小至一个整形数据，大至一张背景图片或屏保。OMADM协议对这些管理对象的内容或值是不可知的，它们被当作不透明数据处理。
管理对象的定义和描述
SyncMLDM管理对象是在DMTND或DDF中定义的，这个描述框架在问题中详细描述了细节信息。但由于某些信息太细节化了，所以有时人们很难理解，并且要获得对象结构的整体认识要花费大量时间。
为了迅速理解管理对象的结构和用途，本文采用了一些简单的可打印的图形符号，例如：一个节点出现的次数。它们都是借鉴于DTD中的语法。这些符号定义如下：
如果没有用到任何符号，那么默认为出现且仅出现了一次。
DDF还有一个特性，就是需要相应的图形标识，例如：未命名字段。它们作为占位符，在运行时提供实际信息。未命名字段在描述符中以斜体字的形式来描述，例：x。
图形标号中的每一个字段都与被描述的节点相符合，并且文本就是节点名称。如果一个字段中含有x，就意味着名字未知，需在运行时给其赋值。所有父节点的名字用于为管理对象的每个节点构建URI。此外，通过图形标号不能看到节点的实际属性和数据。
下面是一个用图形标号描述的管理对象的例子，这些对象均为SyncMLDMDeviceInformation管理对象。
图1
该图形标识并没有显示出该MO的所有详细信息，但是通过上图管理对象的整体结构，我们可迅速找出每个节点。不过仍有些地方需注意，上图中除可选的Ext和Bearer外，其余所有字段均出现且仅出现了一次。其中命名节点DevInfo有子节点，是一个内部节点。除Ext和Bearer外的其余节点都没有子节点，它们被称作叶子节点。未命名的叶子节点用“”标记，表示在管理树中只包含了一个节点，但在运行时可能是任意数，包括0。唯一限制是节点名称必须是唯一的，并且有足够的内存空间来存储这些节点。
下图描述了运行时终端信息管理对象的结构。
图2
图2和图1的区别在于未命名字段已经有实际名称，同时也说明了“”表示可出现0次或多次。注意叶子节点存储的数据并不会在图中表示出来，我们能只能看到节点名称。
DDFcompliance
本文档中的管理对象描述都是规范性的，但为了提高可读性，描述中也包含了大量的资料性的，比如对ZeroOrMore和OneOreMore元素而言，资料性内容就存在于那些实现中会引入约束的地方。所有例外的情况列表如下：
所有XML文档中的注释，例如“”，都是informative
描述中不包含RTProperties元素或它的子元素，但执行时却包括RTProperties元素。
如果叶子节点的默认值通过DefaultValue元素指定，执行时必须提供与其相符的元素值。如果DefaultValue存在于描述节点中，那么也必须存在于implementation中，不过值可能不相同。
元素Man、Mod、Description、DFTitle的所有值都是informative
在内部节点Ext和Bearer下，implementation可能添加更多节点
元素AccessType的内容可能被implementation扩展
如果AccessType值是Copy,Delete,Exec,Get,和Replace中任意一个，那么它们在implementation绝不能被移除
如果AccessType值是Add，那么implementation如果只支持固定个数的子节点时它们可能被移除
Implementation可能会replace元素ZeroOrMore或OneOreMore为ZeroOrN或OneOrN，N的值也必须由元素…OrN提供。
其它组织制定的管理对象标准
OMADM已经被设计为由管理对象进行管理的了.一般而言，这些已存在的管理对象已经被其他标准组织标准化了.
当前使用SyncMLDM时还没有其它组织为管理对象制定标准。
OMADM管理对象
客户端执行OMADM必须支持OMDDMAccount管理对象，DevInfo管理对象和DevDetail管理对象。OMADM服务器必须支持所有上述三种管理对象。
Management
Object
管理对象 ClientSupport
ServerSupport Description DMACC MUST MUST SettingsfortheDMclientinamanageddevice.
DM客户端的设置 DevInfo MUST MUST DeviceinformationfortheOMADMserver.Sentfromtheclienttotheserver.
客户端发送给服务器的终端信息 DevDetail MUST MUST Generaldeviceinformationthatbenefitsfromstandardization. Inbox MAY MAY ReservedURIwherethedeviceSHOULDusethemanagementobjectidentifiertoidentifytheabsoluteURI.
保留的URI ThedifferencebetweenDevInfoandDevDetailisthattheDevInfoparametersareneededbythemanagementserverforproblemfreeoperationoftheSyncMLDMprotocol.TheDevInfoobjectissentfromclienttoserverinthebeginningofeverysession.
DevInfo和DevDetail的不同在于：参数DevInfo是管理服务器必需的，SyncMLDM协议中允许其可以自由处理出现任意的问题。DevInfo对象在每次会话的一开始就从客户端发送到服务器。
DevDetailcontainsotherdevicespecificparametersthatbenefitsfrombeingstandardizedandmandatory.Theonlydifferenceisthattheseparametersarenotsentfromclienttoserverautomatically.Instead,theseparametersaremanagedbyserversasanyotherparametersandcanbemanipulatedusingSyncMLDMcommands.
DevDetail包括了标准中另外的必选的详细参数。唯一的区别是这些参数不会自动从客户端发送到服务器，它们是被服务器直接管理的，并且可通过SyncMLDM命令进行操作。
DMACC管理对象
DMACC用于管理SyncMLDM协议的设置信息。
管理对象标识符urn:oma:mo:oma-dm-dmacc:1.0
图3
在DeviceManagementApplicationCharacteristicregistrationdocument[w7]文档中，同时也DM参数进行了描述，该文档时OMA客户端规定条例的一部分。一般的OMA参数映射规则在[DMBOOT]文档中进行的描述。当DMACC的参数从w7文档继承的时候，可以从附录C中参见更多的参数映射信息。
DMACC完整的DDF描述请见[DMAccDDF]。
5.3.1.1Node:
这个内部节点是作为一个占位符，这个占位符是针对于一个或者多个账户或者一个固定节点而言
??Occurrence:OneOrMore/One
??Format:Node
??AccessTypes:Get
??Values:N/A
5.3.1.2Node:/AppID
该节点指定设备管理账户对象的应用程序ID.
??Occurrence:One
??Format:Chr
??AccessTypes:Get
??Values:w7
5.3.1.3Node:/ServerID
给节点为用于管理会话的管理服务器指定一个服务器标识符.
??Occurrence:One
??Format:Chr
??AccessTypes:Get
??Values:
5.3.1.4Node:/Name
给节点为管理服务器指定显示出来的用户名字.
??Occurrence:ZeroOrOne
??Format:Chr
??AccessTypes:Get
??Values:
5.3.1.5Node:/PrefConRef
该节点指定一个首选链接的引用.此处应为一个代理或者NAPMO（接入点管理对象），但对于其他指定的连接而言，也可能会被引用。
??Occurrence:ZeroOrOne
??Format:Chr
??AccessTypes:Get
??Values:URItoamanagementobjectorimplementationspecificidentifier.
5.3.1.6Node:/ToConRef/
ToConRef这个内部节点用于允许应用程序引用一个连接定义的集合.其下可能会列出一些已有的连接。
??Occurrence:ZeroOrOne
??Format:Node
??AccessType:Get
??Value:N/A
5.3.1.7Node:/ToConRef/
这个运行时节点作用是一个或者多个连接参数的占位符.
??Occurrence:OneOrMore
??Format:Node
??AccessType:Get
??Value:N/A
5.3.1.8Node:/ToConRef//ConRef
这个ConRef叶子节点表明了这些连接性参数的链接.
??Occurrence:One
??Format:Chr
??AccessType:Get
??Value:指向一个管理对象或者实现标准的标识符.
5.3.1.9Node:/AppAddr
这个地址用于指定多个管理服务器的地址.
??Occurrence:One
??Format:Node
??AccessTypes:Get
??Values:N/A
5.3.1.10Node:/AppAddr/
这个内部节点作用就是分隔一个或者多个服务器地址的占位符.
??Occurrence:OneOrMore
??Format:Node
??AccessTypes:Get
??Values:N/A
5.3.1.11Node:/AppAddr//Addr
该节点指定一个管理服务器地址.
??Occurrence:One
??Format:Chr
??AccessTypes:Get
??Values:DependentuponAddrType.
5.3.1.12Node:/AppAddr//AddrType
该节点指定一个管理服务器地址类型.
??Occurrence:One
??Format:Chr
??AccessTypes:Get
??Values:“URI”,“IPv4”or“IPv6”.IfnovalueexiststhedefaulttypeMUSTbe“URI”.
5.3.1.13Node:/AppAddr//Port
给节点指定管理服务器地址的Port信息.
??Occurrence:ZeroOrOne
??Format:Node
??AccessTypes:Get
??Values:N/A
5.3.1.14Node:/AppAddr//Port/
该内部节点起到分隔一个或者多个Port设置的占位符作用.
??Occurrence:OneOrMore
??Format:Node
??AccessTypes:Get
??Values:N/A
5.3.1.15Node:/AppAddr//Port//PortNbr
指定端口号.
??Occurrence:One
??Format:Chr
??AccessTypes:Get
??Values:这个端口号必须是一个十进制数而且范围必须在16位无符号整数中.
DevInfo管理对象
下图显示了DevInfo管理对象的概况：
图4
组成DevInfo的节点有如下含义：
Ext
Anoptional,internalnode,designatingtheonlybranchoftheDevInfosubtreeintowhichextensionscanbeadded,permanentlyordynamically.
一个可选的内部节点，指定DevInfo子树的唯一分枝，对该分支的扩展可以永久地或动态地增加。
Bearer
Anoptional,internalnodeoftheDevInfosubtreeinwhichitemsrelatedtothebearer(CDMA,etc.)arestored.Useofthissubtreecanbemandatedbyotherstandards.
一个可选的DevInfo子树的内部节点，该节点的item与已存储的bearer（CDMA等）相关，其他标准可以强制要求使用该子树。
DevId
设备的唯一标识符，应该是全球唯一的，格式必须写成RFC2141中定义的URN。
Man
厂商ID
Mod
ModelID
DmV
客户端版本标识
Lang
设备当前的语言设置，语言标签的语法和它们的使用被定义在RFC1766中，语言编码被ISO定义在ISO639标准中。
管理对象DevInfo的DDF描述语言参见附录D。
DevDetail管理对象
管理对象标识符：urn:oma:mo:oma-dm-devdetail:1.0。
下图概述了DevDetail管理对象:
该对象是最关键的设备管理对象，其下挂接了大量业务相关的对象节点。在[2]中仅仅定义了一个DevDetail对象的基本子节点，用以描述终端设备类型、硬件版本、固件版本等信息，在标准对象模型中定义了一个子节点Ext，作为业务扩展节点，运营商的业务需求，比如管理的网络配置参数和可升级配置的固件对象都是挂接在此节点下面。基本的DevDetail对象类似下图：
图5
以下是节点说明
Ext
Anoptional,internalnode,designatingtheonlybranchoftheDevDetailsubtreeintowhichextensionscanbeadded,permanentlyordynamically.
一个可选的内部节点，指定DevDetail子树的唯一分枝，对该分支的扩展可以永久地或动态地增加。
Bearer
Anoptional,internalnodeoftheDevInfosubtreeinwhichitemsrelatedtothebearer(CDMA,etc.)arestored.Useofthissubtreecanbemandatedbyotherstandards.
一个可选的内部节点，指定DevInfo子树的分枝，其条目与已存储的bearer（CDMA等）相关，其它标准可通过此子树进行管理。
URI/MaxDepth
设备支持的设备管理树的最大深度，树的最大深度被定义成设备支持的URI的最大分段数。该值为一个16位无符号二进制整数，当值为“0”时表示设备支持无限深度。
URI/MaxTotLen
指定用于描述节点地址或者节点属性的URI的最大总长度。一个URI的最大总长度定义成设备可以支持的描述URI的特性的最大字符长度。注意根据字符设置的此值可能会和字节的数值不同。该值为一个16位无符号二进制整数，当值为“0”时表示设备支持无限长度。
Notethatdependingonthecharactersetthismightnotbethesameasthenumberofbytes.
URI/MaxSegLen
指定用于描述节点地址或者节点属性的URI里面的所有URI段的最大总长度。URI段的最大总长度定义成设备可以支持的单个URI段中的最长字符数。注意根据使用的字符设置的此参数可能和使用byte数设置的此参数不同。该值为一个16位无符号二进制整数，当值为“0”时表示设备支持无限长度。
Notethatdependingonthecharactersetthismightnotbethesameasthenumberofbytes.
DevType
设备类型说明，比如“PDA”、“phone”
OEM
OEM（OriginalEquipmentManufacturer）厂商
FwV
固件版本号
SwV
软件版本号
HwV
硬件版本号
LrgObj
指明设备是否支持[DMPRO]中定义的OMADM大对象处理规则。
推荐使用HwV、SwV、FwV、Man、Mod以及OEM组成的组合来提供一个描述软件版本细节的唯一标识，基于此标识可以提供一个为其他执行动作做特殊规定的方法。
ItisRECOMMENDEDthatthecombinationofHwV,SwV,FwV,Man,Mod,andOEMprovideauniquesignatureidentifyingthespecificversionofsoftware,thusprovidingameansforotherimplementationstomakespecialprovisionsbasedonthatidentification.
该对象完整的DDF描述参见[DevDetailDDF]。
TheInboxURI
MO标识urn:oma:mo:oma-dm-inbox:1.0
在有些情况下，MO的URI并不是优选的寻址方式，这时，MO需要提供足够的信息，以便设备能解析出正确的地址。于是，”./Inbox”就是出于这个目的而成为了保留节点。
例如，某设备的DDF描述中指明了是否其支持Inbox。这样，就可以为Inbox定义accesstype，但是必须为add。当某服务器用URI：./Inbox发送MO标识给设备的时候，设备应该能够根据该MO标识，解析出MO在管理树上正确的位置，从而进行添加。当添加完成后，服务器不能从Inbox中get该MO对象。同时，客户端上的Inbox也应该设置合适的权限，以便只有一些服务器能使用到Inbox的这个功能。
DM客户端必须禁止对Inbox进行Get操作。如果客户端收到了针对./Inbox的Get命令（包括./Inbox的子节点），那么客户端应该返回状态码405（命令不允许）。
6附录
机密▲
3
<本文中的所有信息均为中兴通讯股份有限公司内部信息,不得向外传播>第1页共20页
XX软件子系统设计方案<版本号>
第1页共12页
|
|
