北京  也乐英语为了满足广大英语爱好者的需要特推出周末免费英语角服务，

北京英语角的组织形式如下：

    1：由也乐英语派出一名外教和一名助理负责组织英语角的活动。

    2: 英语角每周组织一次活动，也乐英语培训学校提供一间教室为大家的活动场所。

    3：英语爱好者可以免费参加英语角的活动，不收取任何费用，此活动是公益活动，也乐英

语不收取任何费用，也不限制参加次数。

    4：也乐英语免费提供给英语爱好者茶水、咖啡、以及活动所采用的书籍报纸。

    5：每周一到2个话题，由外教提前一周告诉大家，大家可以简单准备，以便在课堂上
        跟外教以及同学交流。
   
    6：外教会纠正大家的发音、语法、词汇上的错误，会形成一些总结，也希望大家能够畅所

欲言，大胆的说英语。

     7：所有参加英语角的爱好者，请您在交流期间把手机调为静音。

     也乐英语地址：北京丰台区马家堡西路15号 时代风帆大厦2区1901
     交通状况：地铁四号线角门西站A口上楼即可。 51、501、54、529、698、646、707 嘉园

二里东门下车
     联系电话：010-58423871  15330275871

  SyncML dm 协议包括 2 个阶段 初始化阶段（认证和终端信息交换的阶段）和管理阶段，管理阶段服务器希望进行重复多次进行管理。 Manage 周期的开始以 package0 开始，本次出发依赖于不可更改的环境，在 SyncML Notifaction 开始的周期里面被指定

下图是描绘了 2 个阶段

 Management 阶段包括了几个协议的交互，从 server 发送到 client 的包的内容决定了这个周期是否进行下去，如果从 server 发送出来的包的管理指令需要得到 client 的回复， client 将会返回针对这些操作指令的回复。这些回复的包开始了新的协议的交互，服务器将发送一个新的管理指令的包并且开始一个新的协议交互的的过程。

     当 server 的 package 里面不包含 management operation 的时候， client 将根据服务器发送过来的包回复一个新的包，这个包里面只包含了 status 和 Synchr ，在这种情况下，真个回复的包不能被发送，协议中止。 Server 必须给任何 client 的包进行回复

     包的处理可能花费的时间是不可预知的，因此在 SyncML dm 协议中没有指定 2 者的超时时间。

     如果不是 operation command 另有规定，终端和 server 可以不按照 package 中的顺序执行指令。因此，在上一条管理指令在执行的顺序是必须的，管理指令必须按照他们发送的顺序进行执行。 Client 不能发送除了包含 Devinfo 的 REPLACE command 、 Result alert 给 server

8 ． 1 session abort

8 ． 1 ． 1 描述

      是 server 还是 client 任何时候都可以中止操作。终端操作的原因可能是 server 关闭， client 没电，或者用户在 client 上的其他交互操作，或者其他操作。这种情况下，最好的方式是发送一个中止的 ALERT 。推荐的做法是： message 包含了管理指令的任何 stauts 和 result

如果发送一个 session 终端给接受方的 MESSAGE ，那么接收方的回应会忽略，（不会回应把，自己也不理解，有待更正）

有些终端是无法控制的， client 不在覆盖范围内或者电池没有电。 Server 和 client 必须也对没有信号的情况做好准备。上面提到的需求只要是为了减少一些回应超时，或者没有回应的情况。

补充说明： request/response 在传输用的角色被倒置的情况， client 是个传输层的 server ， server 是个传输层的 client ，这种情况下 8.1.1 以上的推荐可能不会用到

8.1.2 需求

Alert 1223 是无法预知的操作中止的信号标识，发送方的 session 中断标识包含了 command 的状态和结果，这些指令将在 abort 之前执行，发送方必须包含一个 FINAL 的标识。当 server 收到 alert 提示的时候，必须在回复的 message 中包含状态和 SyncHR ，并且不回复新的 MESSAGE

8.2 package 0 ， server 发起的初始化 指令

  许多终端不能持续的侦听服务器的连接，由于安全原因一些终端只是不想开方一些端口。大部分终端可以接受一些主动提供的 MESSAGE, 称作通知 (notifaction).

  Server可以用通知的这种能力使终端初始化一个连接回server， SyncML dm 协议规定了几种管理初始化通知的发送方式。发送者和通知的内容可以参考Notification Initiated Session, Version 1.1.2

      需要说明的是：接收一个管理初始化的通知会受其他方面影响。如终端设备可能会允许用户操作设备去初始化管理周期，另外，终端用户也可以管理超时的管理周期，一些错误得操作也会使终端发起一个管理周期。

8 ．3 package1 ：客户端发起初始化指令

   管理阶段跟SyncML dm 数据协议得描述完全相同，客户端发起包的意图如下：

1 ：发送终端信息(厂商，版本，其他)给DM server，终端必须在第一个message中管理周期中发送设备信息

2 ：根据SELECTION 9中的规则终端向DM server确认身份

3 ：通知dmserver本次SESSION由客户端发起还是由Dmserver 发起（package0往往不会用到，如果是客户端发起的话）。

  客户端发起得初始化package得具体需求如下：

  1 ：在SyncHdr 元素里面得需求

VerDTD 的值必须是1.1

VerProto 的值必须是“DM/1.1”

Sessionid 必须能标明但前Management session 的身份，如果client 回复通知，那么Alert（1200）标识由server发起的，sessionid必须跟notifaction里面的sessionid相同，否则client产生的sessionid不会唯一，sessionid会贯穿整个session

MsgID 必须明确的指出message属于哪个management session

Target 元素必须指明是个那个目标server

Source 元素指明的是哪个client 的service

Cred element 可能包含再认证的message里面，一般是从client发起，section9将会详细描述

  2 ：Syncbody中必须包含alert信息无论client发起还是server发起

Alert command 的需求如下

  CmdId 是必须的

  存放management session type 的Data element或者由server发起（1200）或者由client发起（1201）

  3 ：终端的信息必须在syncbody中包含Relpace command，replace command需求如下

  Cmdid 是必须的

  Dm tree 每个节点的item都可以被找到，在DMSTDOBJ中有详细描述

  Source element 必须包含一个指定的URI 节点

  Data element 用来装载device 信息数据

Final element 必须包含在Syncbody 的最后一个message 中

Dm 协议允许管理指令在节点上执行，跟 SyncML 同步协议和 SyncML 表示协议类似都采用的是包的形式。设备的一个节点表示为一组可配置参数，可以这个节点进行读和设定参数的键、值操作，而终端的应用软件另外一个节点可能是的正在可运行环境中（意思是不会影响到别的节点的功能），对这类型的节点操作可以对软件的一部分功能进行下载、升级或者卸载 .

SyncML DM 这些指令代表这些操作，在 SymcML 表现协议和 SyncML 表现协议 DM 的用户手册中有描述。这些指令和消息的结构等同于 SyncML 数据同步协议，并且管理协议的 DTM 就是来源于 SyncML 数据同步协议的 DTD

5 ：节点处理

每一个节点的路径就是设备的唯一统一资源标识，这些标识必须遵循这样一些指定的需求： SyncML DM 树和描述加以限制和指定

每一个节点都有一个可以决定什么样的管理内容可以用来设置或者读的类型，在节点上操作需要实现定义这个类型的值，当节点被读的时候，这个类型的值将被返回。

举例说明，有的节点只是一个简单文本类型，需要设置，而有的节点是 WAP Provisioning document MIME 的复杂类型，甚至其他节点可能象 WAP 设置或者软件安装这样更复杂的值

SyncML DM 协议的指令的 target 和 souce 由 目标和来源 元素分别指定 target 是接纳着， source 是来源，这些过程出现的异常都会在管理命令需求中的异常中会被提及

6 ：包中的多消息

6 ． 1 描述

  DM 管理协议中中提供用多个 MESSAGE 来传输一个包的功能，当一个包非常大的时候，分成多个 MESSAGE 进行传输是非常有必要的，这样的局限是可能由传输协议或者终端的功能限制决定，（分成多个 MESSAGE 就可以解决这个问题）。

  DM 管理协议中，包作为一个逻辑组的作用是非常有限的，大部分的限制在 MESSAGE 上，而不是在 PACKAGE 上，举例：一个 COMMAND 必须完全适从一个 MESSAGE 。

为了避免大量客户端而有限的资源，服务器等待从客户端的包的 command 返回一个状态，

如果上一个 COMMAND 没有返回一个状态服务器不允许发送一个新的 COMMAND ，换句话来说，大部分 server 发送到客户端的 COMMAND 都会收到 CMMAND （ package ）的返回信息，除非 SERVER 发送一个大的对象或者请求更多的 MESSAGE （用 1222 ALERT ）

一个 PACKAGE 包含大对象数据将会被分成很多 MESSAGE 传输，在第七部分会详细描述

  说明 server 在处于一下一种包的边界的状态的时候：

   1 ： server 有一个完全大的包，在这种状况下， server 等待从 client 的 COMMAND 返回状态，由于状态和结果非常大（如 GET COMMAND 的结果）， client 将发送多个 MESSAGE 回 server ，然后结束他的回应

   2 ： server 从 client 接受到一个完整的包， server 将会发送一个新的 COMMAND 给 client

   3 ： server 发送了包中的一个或多个指令，但是没有发送包中的最后一个指令的时候，只有当 package 中的最后一个指令被发送出去的时候，这次状态才被认为是有效的

由于 SyncML 的传输形式是 request/response    的形式，无论是客户端还是服务器端在传输消息的时候都不应该包含一个开始命令或者一个结束的标志，以便保证 response/request 循环进行下去（言外之意就是有个这个标志就是开始和结束的时候） .

举例：当 server 在 STATE1, 他可能收到客户端的很多 MESSAGE, 这些 MESSAGE 包含了 status 和 result 。 Server 会对任何一个 message 回应，除了对 NEW COMMAND 进行回应外。

Server 对发送的回应在 SyncHdr 中包含了一个 1222 ALERT ， client 也指定了，（表示没有结束还有消息）。 STAUTS 必须对 ALERT 的回应进行发送而不是对 RESULT 的回应进行发送

ALERT1222 可以被 ALERT 1223 替换，因为服务器可以主动结束一个过程

下图展示了多个 message 被发送

6 ． 2 需求

  如果 SyncML package 分成多个 MESSAGE 被传送，最后一个 MESSAGE 必须包含一个 FINAL 的标志，其他么 message 一定不能包含 final 标志。 Final element 由 server 发送而不是由 client 发送，最终停止本次的 PACKAGE 操作。

   Server 在每个 MESSAGE 必须发送 FINAL message ，不过在发送大的对象的时候或者发送 NEXT MESSAGE 的相应的时候不会发送

7 ：大对象的处理

  SyncML dm 协议中，大对象不能完全在一个 Message 中传输，根据 SyncML data 同步协议指定的大对象处理方案可以分成多个 Message 。规则如下：

第一个限制就是支持大对象处理的终端必须显示的之处 DevDetail/LrgObj 的标识为 true

第二个限制是在 server 和 client 传输的 MaxObjSize 有多大，在 SyncML data 同步协议中 MaxObjSize 会在 Meta information 中指定。 DM 协议中被发送着接受的最大对象的大小（ MaxObjSize ）包含在 syncHdr 中（ message 的 META INFO ） ,syncHdr 中指定的 MaxObjSize ，发送者发送的单个对象都不能超过这个大小，如果 MaxObjSize 没有被发送，接收者可以自由发送任何大小的 message 给 server 。

需要指出的是： MaxObjSize 会影响整个 DM session ，如果在随后的 message 中没有对这个值进行重新设置。新的 MaxObjSize 在后来的 message 指定一个可能的原因是 client 的 free memory 大小的依赖，（有东西创建在 MEMORY 的时候或者删除的时候 FREE MOMORY 会发生变化）。

第三个限制：在上一个单元结束前终端会检测新的对象（ messge ），终端会回复一个 1225 的 alert