2009年03月09日

0:说明
本文是如何写作IETF draft并提交文稿的简要指南。作者会随着经验的增长不断完善次文档。
读者如果有任何意见,都可以与本文作者联系。

1: 构思I-D结构
draft name: draft-’authorname’-'groupname’-'drafttopic’-'version’.txt
  (example: draft-linyi-sipping-invite-with-conf-info-03.txt)
Abstract: 
  使用简明的语句描述此I-D的主题和目的。
Body:
  一般会包含如下一些章节(标题名称和标题层次结构可以根据I-D的具体需要来进行安排。):
  Introduction:提供一些背景介绍(例如相关的RFC或者I-D的简介)、Use Case和需求分析。以说明此I-D的必要性。
  Terminology:提供一些约定,例如使用RFC 2119中的Key Word,定义此I-D使用的一些术语等。
  UAC Procedure/UAS Procedure:方案中涉及到的实体的一些流程和约束,即具体的方案
  Examples:提供一些交互流程图和消息实例,有助于方案的理解。
Security Consideration
  一般这个章节是必不可少的,主要是涉及到安全的一些考虑,如果没有特殊的安全问题,可以摘取一些相关RFC中的内容。
IANA Consideration
  涉及到需要注册Option-Tag, Content-Disposition Type, MIME Type的时候,需要在这里提出。
References
  Normative References
  Informative References

2:使用xml或者word模版进行I-D的撰写
ietf提供了xml和word两种模版来进行I-D的协作,并且提供了工具可以将写好的模版转换成正式的I-D文件,不需要自己考虑太多排版的工作。
两种模版各有优缺点:
  xml:有很多编辑xml的工具;文件起来比较复杂,编辑起来麻烦一些。
  word:可以添加批注、支持语法检查,易于review;word支持格式很多,容易出现一些乱码。
RFC 2629 指导如何通过xml方式进行I-D和RFC的撰写
RFC 3285 知道如何通过word方式进行I-D和RFC的撰写

2.1 将英文内容套写为xml文件
http://ietf.levkowetz.com/tools/xml2rfc/authoring/draft-mrose-writing-rfcs.html
RFC2629中详细说明了如何创建一个xml模版。其详细说明了每个xml标签的结构和作用。例如:
<section title="Introduction"></section>就表示是一个新章节。
基本上写过I-D的人都有自己创建的xml模版,具有自己的一套风格,可以借用并根据自己的特点进行修改。

2.2 验证xml模版是否符合规范
将xml文件提交到http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/页面进行验证,其会提示一些error/warning等,只要没有error了就基本上没有问题了

2.3 利用xml2rfc工具将xml文件转化为正式的I-D或者RFC
在线转换地址:http://xml.resource.org/,在转换服务的对话框中输入本地xml文件地址,选择需要生成的文档类型.txt,
选择输出形式(窗口或者文本),即可生成相应的文档。

离线转换:下载rfc2xml工具,并且下载tcl工具到本地,安装以后,使用tcl运行xml2rfc脚本,会弹出类似在线转换的窗口,进行转换,这样效率比较高。下载地址(注意下载最新版本):
ActiveTcl 8.4.14.0 Binary Distribution:
http://downloads.activestate.com/ActiveTcl/Windows/8.5.0/ActiveTcl8.5.0.0b7.278673-win32-ix86-threaded.exe
xml2rfc 1.3.2
http://xml.resource.org/authoring/xml2rfc.zip

2.4 对生成的txt文本进行验证
将txt文件提交到http://tools.ietf.org/tools/idnits/进行验证,同样会提示一些error/warning等,只要没有error基本上就符合向ietf提交的条件了。所有提交的I-D都必须遵循此Check List:http://www.ietf.org/ID-Checklist.html,估计此工具也主要是根据Checklist对文档进行检查,例如检查引用的RFC是否被替换、引用的其他I-D是否有新版本等。

3:评审修改完成后,将I-D提交到ietf
提交I-D到ietf的过程非常简单,就是发送一份邮件:
   发送地址:internet-drafts@ietf.org
   邮件主题:ID Submission : draftname.txt
发送后会收到系统的自动应答,3-4天后会正式发布出来,即ietf会向i-d-announce@ietf.org邮件列表发送一个通知,此时I-D的提交就正式完成了,可以在相应工作组的页面上看到此draft了。正式发布后或者收到提交确认以后,可以将文稿相关信息转发到相关工作组发起讨论。

4:参考信息
http://www.ietf.org/rfc/rfc2026.txt rfc2026 The Internet Standards Process — Revision 3
http://www.ietf.org/ietf/1id-guidelines.html Guidelines to Authors of Internet-Drafts
http://www.ietf.org/ID-Checklist.html   Checklist for Internet-Drafts (IDs) submitted for RFC publication
http://ietf.levkowetz.com/tools/xml2rfc/authoring/draft-mrose-writing-rfcs.html draft-mrose-writing-rfcs.html Writing I-Ds and RFCs using XML (revised)
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt draft-rfc-editor-rfc2223bis-08.txt Instructions to Request for Comments (RFC) Authors
http://www.ietf.org/rfc/rfc2629.txt rfc2629 Writing I-Ds and RFCs using XML
http://www.ietf.org/rfc/rfc3285.txt rfc3285 Using Microsoft Word to create Internet Drafts and RFCs 
http://www.rfc-editor.org/howtopub.html   How to publish an RFC
http://www.ietf.org/rfc/rfc2119.txt rfc2119 Key words for use in RFCs to Indicate Requirement Levels
http://www.ietf.org/rfc/rfc2434.txt rfc2434 Guidelines for Writing an IANA Considerations Section in RFCs
http://www.ietf.org/rfc/rfc2234.txt rfc2234 Augmented BNF for Syntax Specifications: ABNF
http://xml.resource.org/authoring/README.html xml2rfc readme

http://www.tech-invite.com/Ti-sip-RFCs.html

5.Tips:
(1)对于需要直接显示带特殊符合且有格式的内容时,可用下述方式
<artwork>
<![CDATA[
...(直接显示内容)
]]>       
</artwork>
这个在画图的时候特别有用。

(2) 转义字符表:
转义后字符        转义前字符 
amp; 或 &#38;         &      
&lt; 或 &#60;         <      
&gt; 或 &#62;         >
&quot;                "
&nbsp;                空格
&copy;                ?          版权符
&reg                  ?          注册符
其中&lt;和&gt;最常用,对于I-D内容中包含的xml元素时,需要对<和>进行转义。

6.除了以上介绍的XML2RFC工具生成draft之外,还可以使用Word工具生成draft。这种方法使用起来比较简单,但也存在一些不足,如果使用WORD工具,需要特别注意:
   6.1 在写作过程中不能使用任何非ASCII字符。这适用于采用所有的生成工具和方法。
   6.2 Word工具对一些符号字符的处理中存在一些问题,使用Word生成draft之后需要仔细检查一遍防止提交的draft存在乱码的问题。已经发现的字符有“‘”和“"”。
   6.3 Word工具生成的draft左侧没有从第一个字符位置开始,因此在生成draft之后需要手工删除左边的8个空白字符列。可以使用Ultra Edit列编辑模式搞定。
   虽然存在以上不足,但总的感觉还是比较好用的。特别是具有编辑简单、可以使用Word版本进行review等。

7.draft的声明等部分的内容比较固定,因此在写作一个新的draft时可以直接在其它的draft的基础上修改文档内容、安全性考虑、作者列表、文档页眉、页脚等部分内容即可,这样即可以快速完成draft,又可以最大限度的避免出现这些方面的问题。

2009年01月07日

后续此博客将不再发表文章,全部转到新博客发表。

原文已经发表在新博客:http://tianlinyi.blogcn.com/diary,22407807.shtml

RD Formal Review是OMA给成员厂商机会去澄清和确认需求的一个流程,负责此流程运作的工作组是OMA REQ(需求工作组)。Review一般在RD开发结束后由Work Item的Owner工作组发起,流程如下:

(一)发起RD Formal Review
(1)向REQ提交一个Input Contribution,其中包含如下内容:
A)Cover sheet with:
       a) The checklist table of the RD Best Practices <http://www.openmobilealliance.org/ftp/Public_documents/REQ/Permanent_documents/OMA-ORG-RequirementsBestPractices-V1_1-20071211-A.zip> , appendix C
       b) The name of the RDRR Editor
       c) The proposed times for the RD Formal Review
B)The clean RD version to review
C)The clean ERELD version to review
此文档准备就绪后,REQ主席将发送RD Formal Review Announcement timely到相关工作组(REQ、SEC、Work Item Onwer WG)

Note: RDRR=Requirement Document Review Report
          ERELD=Enabler Release Definition

(二)收集汇总意见到RDRR中
厂商可以通过提交提案、发送comments到RD Review的邮件列表或者在会议上发言的方式(记录到Minutes)来提交Review意见,Editor完成意见的收集汇总成RDRR文档。

(三)Owner工作组解决comments
Owner工作组逐条对comments进行讨论,达成一致意见后关闭comments并注明原因。

(四)RD Candidate Approval
所有意见解决后,由Owner工作组通知REQ确认所有comments已经关闭,获得确认后向TP提交提案,其中包含最终版本 RD,REQ组确认后的RDRR(-I状态),Candidate Approval申请;TP批准后向Board寻求Ratification,最终完成Candidate Approval并发布。

AD 的Review和批准流程类似,只是负责运作此流程的工作组变为ARC(架构工作组)。Enabler所有规范开发完成后的Consistency Review也是类似,负责运作此流程的工作组变为REL(发布工作组),同时这个Review的范围更广,是检查RD/AD/TS/ETR(从需求、架 构、规范、测试需求)来整体看需求是否完全得到了最终的实现。

REQ、ARC、REL负责运作Review的过程,TP是从技术角度负责批准Enabler规范,Board是批准规范的发布。

已发表到新博客中:http://tianlinyi.blogcn.com/diary,22405874.shtml

2008年OMA DM工作组完成了大部分Enabler的主要工作,多数Work Item完成发布,或者即将发布,同时完成了新Work Item的批准开始着手新版本DM的开发,因此是一个重要的里程碑。

让我们来看看DM工作组主要的工作项的进展情况:
(一)DM基础协议Enabler
(1)DM(Device Management设备管理)
:完成了Approved Release,逐步开始实现市场部署

(二)应用层MO Enabler
(1)FUMO 1.0(Firmware Update固件升级)
:用于完成终端的固件升级。完成了Approved Release,是DM最早的应用
(2)SchedulingMO 1.0(离线任务)
:用于离线任务的管理,根据设置的时间或者事件触发离线任务的执行。完成了Candidate Release,目前正在开发测试规范ETS,为Test Fest测试做准备。
(3)DCMO 1.0(Device Capability终端能力)
:用于管理终端的硬件、I/O、网络连接能力的启用和禁止等。设备能力举例为摄像头、键盘、WLAN和WCDMA等网络连接能力。完成了Candidate Release,目前正在开发测试规范ETS,为Test Fest测试做准备
(4)SCOMO 1.0(Software Component软件组件)
:用于管理终端上的软件的下载、安装和升级等。完成了Candidate Release,目前正在开发测试规范ETS,为Test Fest测试做准备
(5)LAWMO 1.0(Lock and Wipe锁定和数据擦除)
:用于锁定手机或者擦除手机数据,用于手机的遗失管理或者企业用于删除企业手机上的敏感数据。即将提交OMA TP申请Candidate Approval,预计09年2月份将Candidate Release,开始着手测试规范ETS的开发
(6)DiagMon 1.0(Diagnostics and Monitoring诊断和监控)
:用于采集手机日志、应用程序事件等数据,以诊断手机故障;或者监控手机状态,例如电池电量、内存等。DiagMonMO 1.0中仅定义Framework(含DiagMonMO和TrapMO),即不定义具体的诊断功能;诊断功能放到DiagMon 1.1中完成。08年底完成Framework TS规范开发,09年1月份提交Consistency Review,预计09年4月份Candidate Approval

(三)Reference Release(非功能性MO和白皮书)
(1)ConnMO 1.0(Connectivity网络连接)
:定义了多种网络的连接参数,包括3GPPCS、3GPPPS、3GPP2、WLAN、HTTPProxy、WAPProxy、EAP和IP。完成了Approved Release。
(2)ACMO 1.0(
Application Characteristics & Management Object Whitepaper)为白皮书而非技术规范,其介绍了AC和MO的作用以及关系,提供了如何开发和注册AC/MO的详细指导,是非常好的DM入门材料。
下面是DM工作组目前进行的一些新的工作:
(3)DM 1.3
:主要是针对DM 1.2基础协议的一些问题修复、改进和增强,将向后兼容;预计需求和架构在09年4月份完成开发,TS规范在年底完成,2010年初完成Candidate Release
(4)DM 2.0
: 主要目标是Converged Device Management,应对固定移动融合的趋势;目前还在头脑风暴阶段,已经向3GPP、3GPP2、WiMAX、uPnP Fourm、Broadband Forum、Femto Forum、HGI、CabelLabs、DMTF和NFC发送了联络函寻求需求输入和合作。2009年此工作项的一个最大挑战是方向选择的问题,如何协 调和TR069、uPnP DM等一些相关技术的关系成为方向选择的一个重点。
(5)DiagMon 1.1
:主要是定义DiagMon Functions,目前已经完成了BatteryInfo、BatteryStandbyTime、PanicLog、SmsUsage、SmsOptions等诊断监控功能的开发,预计2010年中完成Candidate Release
(6)BMO(Browser浏览器)
:主要完成浏览器的参数配置,第一个基线版本已经通过,预计09年中即可Reference Release。另外DM组的WSI(Web Service Interface)、SC(Smart Card)两个工作项进展缓慢,关注厂商很少,前景堪忧,不排除存在被暂停或者关闭的可能。

从 部署和应用来看,目前DM和FUMO部署较广,SCOMO和DCMO有可能成为下一步被部署的重点应用。在这里要提一下的是,DCMO是华为公司在OMA 主导立项并顺利完成的第一个项目,也具有一定里程碑式的意义,同时华为公司在其他所有项目中都是积极的贡献者。今年取得较大进展的SCOMO、DCMO、 LAWMO、DiagMon、ACMO等项目中华为都是主要贡献者和推动者。

2009年01月06日

我最大的毛病就是虎头蛇尾
正像那个网友说的我干脆改名叫半途而废好了

找一个客观的理由来垫背吧
donews的博客系统真是难用

我的一个优点就是永不放弃
这不我又再考虑东山再起了

一块风水宝地是很重要的
至今没有发现特别满意的地方
blogcn是我目前的新的选择

近期我将针对大家提出的问题集中在新博客中给大家答疑
新博客地址为http://tianlinyi.blogcn.com

我增加了一个和博友的互动专栏,希望大家多提意见

2007年12月20日
 Source:OMA TP主席邮件
The Open Mobile Alliance has now been in existence for over 5 years and has continued its objectives of enabling and facilitating interoperable converged multimedia services. In 2007 we held 6 main meetings (commencing in San Francisco and recently in London), with many groups also holding additional interim meetings to progress their work.
 
During 2007 the Technical Plenary delivered many key leading technical specifications to facilitate data services covering personal communications, access to content, common services enablers and other domains, resulting in the Board (see attachment) ratifying:-
  • 37 new/revised Candidate, Approved and Reference Releases
  • 21 new/revised Requirements and Architecture Documents (as stand alone specs)
  • 37 new/revised Enabler Test Specifications and Validation Plans
  • together with Organisational documents, White Papers and other documents
Our successful interoperability programme held TestFest events around the world ensuring and demonstrating the interoperability of implementations based on our specifications:- 
  • 5 TestFests
  • 75 server implementations tested
  • 115 client implementations tested
  • around 365 TestFest participants
which will also assist certification efforts in other organisations.
 
Our major deliverable in 2007 was Mobile Broadcast, and as we look forward to 2008 major activities such as Converged IP Messaging are making significant progress, and recently started activities such as Mobile Advertising and 2D Mobile Codes will be exciting developments. However at the same time we must to continue evolving our internal structure and processes to more quickly meet the market’s timeframe expectations by improving the phasing and profiling our deliverables.
 
2007年12月05日

In anticipation of the WG session tomorrow, the spreadsheets
tracking the WG chartered items have been updated, with a few
highlights summarized below:

http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html

(sorted by Review due date – most useful for WG to know what they should be reviewing now)

http://www.softarmor.com/sipping/process/wg-review/sipping-rt-rev-due.html
(sorted by revision due date – most useful for doc editors to know when their next update is expected)

2007年11月19日

The Work Programme reports, refreshed with the Vancouver updates are available at
 
http://www.openmobilealliance.org/tech/OMAWP/Current/menu.htm

这个地址长期有效,可以看到每次会议之后Enabler的进展情况,聪明的朋友可以把那个Access的数据库下下来,自己写个程序来输出更加形象化的数据以供分析。或者直接把URL指向这个文件来获取更新的数据,这个是我一直想做的事情,如果有哪位朋友好心做了,可以共享给大家哈。。

等我有时间,也许我会做一个挂到网上,不过最近实在太忙了。。。有心无力啊。。

2007年11月06日

         同步标记语言(SyncML,Synchronization Mark-up Language)是为了实现多个平台及网络之间个人信息及企业内数据的同步而开发出的协议,其定义了参与操作的实体之间使用的一系列操作,同时定义了承载这些操作的一套消息格式。在发展过程中设备管理技术DM(Device Management)也选择了SyncML作为其表示层技术。因此在SyncML Initiative加入OMA以后,DS和DM工作组将SyncML语法和基础语意作为单独的SyncML Common Enabler被DS和DM两个Enabler所共用,其独自在各自的规范中定义基于SyncML标签的特定语意。
        DM是一种通过空中下载技术(OTA,Over The Air)将管理指令数据从网络侧下载到终端设备上,并由终端设备自动运行,进而完成终端软硬件升级、参数配置、诊断等的低成本远程管理解决方案,同时DM还可以将运营商需要的业务信息和终端设备的功能信息等从终端设备传递到服务器侧,以支持其它业务的开展。
        在设备管理技术的发展初期,CP(Client Provisioning)技术作为主要的参数配置技术被广泛使用起来,比如在WAP消息中承载的SMS、MMS业务的参数配置的应用。其对应的参数描述格式为AC(Application Characteristic),发展到DM中则主要为MO(Management Object)。
        下面这个ACMO Whitepaper是DM入门的比较好的学习资料。
http://www.openmobilealliance.org/ftp/Public_documents/DM/AC_MO_WP/Permanent_documents/OMA-WP-AC_MO-20071005-D.zip 
         其内容主要包括:

  •  DM Enabler的功能介绍
  • AC和MO的对比,应该选择创建哪个
  • AC、MO如何在OMNA注册等
2007年11月01日

         华为加入了ITU、3GPP、IEEE、IETF、ETSI、OMA、TMF、FSAN和DSLF等七十个国际标准组织。2006年,华为向这些组织提交文稿2900多篇。华为担任ITU-T SG11组副主席、3GPP SA5主席、RAN2/CT1副主席、3GPP2 TSG-C WG2/WG3副主席、TSG-A WG2副主席、ITU-R WP8F技术组主席、OMA DM/MCC/POC 副主席、OMA Bod成员、IEEE CaG Board成员等职位。

  华为持之以恒对标准和专利进行投入,掌握未来技术的制高点。

Reference:
[1] http://china.maoyiba.com/?uid-13-action-viewspace-itemid-1211
[2] http://www.huawei.com/cn/technology/standards/standards_organizations.do
[3] http://www.huawei.com/cn/technology/standards/position.do
[4] http://www.openmobilealliance.org/news/Newsletter19/NewsletterVol2_2007.html

2007年19期OMA News Letter [4]中Announce了我当选DM Vice Chair的情况。

14 January 2007

Linyi Tian, Huawei Technologies elected as Vice-Chair of Device Management working group