Separate Delivery

·         OMA DRM separate delivery protected MIDlet suite has its JAR file in the      DRM content Format.

1． DCF (DRM Content Format) used in the OMA DRM separate delivery method. The format for encrypted media object and associated meta data 。

2． Jad 文件里面的 MIDlet-Jar-URL 存放的是 DCF 文件地址。

 

·         JAD 文件存在的情况

1.        通过浏览器或者别的应用程序下载 JAD

2.        如果用户同意下载，通过 MIDlet-Jar-URL 去下载 DCF 文件

只有 JAR 文件的情况

1.        直接下载 DCF 文件

 

·         对服务器请求 DCF 文件得到的回答是包含 JAR 文件的 DCF 文件

1.       DCF 文件的 MIME type 是 application/vnd.oma.drm.content

 

·         服务器传送 DCF 文件的时候可以包含下面说明的内容

2.        该头内容的名字 X-Oma-Drm-Separate-Delivery-Notify

3.        如果包含了，保存该值留待后用（该值在安装的时候保存在什么结构体里面？）

 

·         Oma-Drm-Delivery-Notify

1.          如果 JAD 文件里面有该属性，并且该属性有效即是可以访问的 URL. 当 DCF 文件下载后，设备通过这个地址 HTTP POST 来把结果告诉服务器。

问题点

1.        如果该属性无效呢？？即该 URL 不可访问

2.        传送过去的状态码

l 900 Success

l 901 Insufficient memory

l 902 User cancelled

l 903 Loss of Service

l 953 Non-Acceptable Content

问题点：

l 和 stall-Notify 不一样，从新定义头文件的必要性？？？分开在传送？

l 前面的 Forward-lock 和 Combined delivery 的式样里面都提到了正常的 MIDP status codes 继续使用再加上 953. 这次说的 953 和以前的 953 是往不同的属性值里面发送，处理有没有问题？？？？

l 900 以外的情况需不需要继续？？？？等待的同时 right object 来了如何？还是说只能等待回信后（不回信重试）才能开始进入 right object wait time

 

·         In response to the download report the server replies with a “200 OK” response.

No content is sent in the server’s response, but if sent it is ignored by the device

1.        这里的 download report 指的是什么？指的是前 OMA-Drm-Delivery-Notify 里面发送的报告么？？？？

2.        如果是的话，后面接着说 response 里面是不包含 content ，即使包含了也忽视不看。但是又接着说， If any response was received from the server, sending is not retried. 这里的 any response 到底指的是什么？？？难道说上面的忽视的返信也算么？？？问题还有 if the download report cannot be sent or if the server reply is not received, sending should be retried and provisioning of the suite continues as normal. 着难道说刚刚得不正常，关键是 retry 是自动的还是 给客户选择的，如果是对方需要认证的情况下该如何处理。一直得到回信 200 成功后才能后面的处理是么？不成功就安装终了？？？

3.        式样最开始讲述 JAD 文件里面增加的新的属性值的时候说刚刚那个属性是 Contains a URL to which the device reports the outcome of download of OMA DRM protected JAR file to trigger sending of the rights object. 如 1 和 2 里面说的如果报告发送了失败或者回信不正确的情况下该如何处理

·         If there was an error while downloading a DCF file, or if the downloaded DCF file is invalid, the user is informed.

也就是说如果下载过程中发生错误，或者是下载的 DCF 文件是无效的，要通知用户

判断 DCF 无效是由 DRM Agent ？通知用户的 UI?

 

·         正常下载并结束的时候 ,2 种情况可能性

1． After the report(900 success) was sent and if the X-Oma-Drm-Separate-Delivery header was present in the provisioning server ’s reponse with the DCF file, the device starts waiting for rights object to be pushed

有就等待 Push 版权文件

2． In the situation when X-Oma… header is missing from the server’s response, this means that the user needs to acquire rights separately

没有的话要单独获得版权文件（通过什么方法不在下载 midlet 文件中）

该怎么设计？本次实装么？

 

·         等待版权文件被 push 的时间如下算法去计算。 P13

如果最大时间和 0 之间的话，选择 X-Oma-Drm-Separate-Delivery, 否则最大时间

 

·         正常系的版权文件在时间内来了， the process continues as normal MIDP OTA

download. 所有的必要 verification 进行，注意点和前面 2 种方式一样，需要关心的 MIDlet-Jar-size 不是 DCF 文件大小，而是真实的 jar 文件大小。

 

·         MIDP installation status report 也和以前一样。不过加上了 953

 

·         In situations when there are multiple rights objects for the same OMA DRM separate delivery protected MIDLet suite the behaviour is the same as defined in the Implementation Best Practices for DRM 1 document.??????? 这部分的文档要调查，现在不明？？？？？？？？？？？？？？？？？？？？？？

 

·         异常系：如果版权文件没有按时到达。

1 ． The User is informed that rights did not arrive. 也就是说给用户一个 UI 界面告诉用户哇，咋子版权文件没有来呢

2 ． The user then has the choice either to start the rights acquisition procedure immediately or to do it later. 也就是说刚刚告知用户的对话框里面最少还有 2 个按钮，一个是为了立刻取得版权文件，一个是这次算了，以后再说。

3 ． If the user selects to acquire rights later, MIDlet suite files(DCF and JAD, if present)are saved in the device. 不管取得与否 , 如果存在的话（ DCF,JAD ）都要被保存。保存后显示如何解决？？？？？菜单是什么呢？？？？

4 ． Such MIDlets suites(downloaded, but not installed due to the absence of the rights object) are accessible from the device UI, so the user can always start the rights acquisition procedure or delete the suite. 正如 3 里面想到的，没有安装版权文件的 MIDlet 也应该被显示个用户，好让用户起码有 2 种选择，即菜单里面最少有 2 个，一个是取得版权，一个是删除该 MIDlet 。（删除的时候也是一个要注意的地方，需要删除什么文件，还有每次安装下来的东西是不一样的，要调查）。

5 ．更加难以处理的是没有来就算了吧，他过了这个时间来。 P14. In this suituation the installation is continued (with/without User interaction) from where it stopped (after DCF file download). 说开始就开始了，绝对不可能，最少也要和用户 Interaction 一下吧。然后呢？？？？？如何从微妙的状况（比如说 下载后我都开始干别的，甚至我退出 Jam 的时候），再次唤醒并且进入的是 install 的流程。或者最简单不 support ，应为情况太难考虑，而且实现难，出 bug 易。谁叫你不快点送过来，等的时间长不关我的事情哦。？？？？？？？？

 

·         Special case: forward-locked Jar file in the DCF

也就是说 Dm 里面是 DCF 文件

The rights object for the DCF is pushed separately

Superdistribution does not apply to MIDlet suites delivered using this method

超分不支持该方法

 

·         更新 - 〉就说了句废话去看 midp2.0 ，也就是说新的情况没有完整说明的文档

 

·         关于没有版权文件或者版权文件无效的时候

必须让用户可以看见并且可以删除这类 MIDlet suite. 并且可以在 ui 来要求版权文件

 

·         许可

Right Expression Language(REL) 里面有四种许可， play,display,execute,print. 但是对于 midlet 来说只有 execute 是有效的。其他 3 种都无视

 

·         约束

count, datetime, interval

Permissions for MIDlet suites delivered via forward-lock method is always execute, without any constraints.

Permissions for MIDlet suites delivered via combined delivery or separate delivey method are read from corresponding rights objects.

 

·         Count 问题

指的不是 Suite 可以被执行的次数，而指的是 Suite 里面单独的 Midlet 的执行次数。也就是说计算每次消耗的 count 的时候， 2 种实装可能性。

1． One midlet 并且直接开始执行的时候， count 检查并且不足的话出错误画面

2． 如果不是的话，可以先出 midlet list 画面，具体选择一个的时候才开始检查

3． 还可以同一一样，开始就检查，没有的话连 list 画面都不让入。但是如果这样，比如说 1 个权力， 2 个 midlet 的时候。进入 list 可能，一个可以运行，结束回到 list 画面，没有权利，但是 list 不检查的话，岂不是还可以继续使用？什么地方对约束来检查？？？？？？？？？？现在如何实装的？？？？。

4． Permission and constrains are checked each time Midlets from the suite are lauched. If rights are invalid,Midlets from the suite are not lauched. 这样看来还是要采用 2 的方案，因为进入 list 并没有 lauch midlet from the suite. 所以无论如何进入 list?0 次也是么？？？