OMA-TP-2003-0407- OMA Working Methods OMA Working Methods

1. OMA-TP-2003-0407-OMA Working MethodsOMA Working Methods Submitted To: Technical Plenary Date: 21st August 2003 Availability: Public OMA Confidential Contact: Philippe Lucas ph.lucas@orangefrance.com Source: Technical Plenary vice-chair X USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT. THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.

2. Contents of the Presentation • Group Types • Liaison • Decision making process • Types of documents and document numbering Process • Work activities : process flow

3. OMA structure

4. Group Types

5. Groups • TP Committees (TP Committees) • Work of TP committees is not covered by Work Items • May produce normative and informative documents • Does not produce specifications • Documents to be approved by TP • Birds of a Feather (BoF) • BoF serves as a forum to review issues not covered by WIs • BoF created by TP before they may meet • Request for BoF to address purpose and issue to review • BoFs are not chartered • BoFs do not produce normative documents • May produce an informative report and/or draft WI for TP consideration • BoF duration is limited in time (typically 6 months)

6. Groups • Working Groups (WG) • Working Groups Report to the TP and are chartered to produce work based on WIs • Working groups produce normative and informative docs • WG permanent documents are approved by TP • WGs may create Sub-Working Groups • Sub-Working Groups (SWG) • SWG are chartered by its parent WG • SWG charter is within scope of parent WG • All decisions are agreed by the parent WG • SWG can not be formally subdivided (ie. no SubSubWG) • SWGs may support liaison activities

7. Liaison • Liaison is used to communicate with external organisations • Until a relationship is established – an interim liaison process exists • Once Established Liaisons May Be Exchanged • Scope Limited to Agreement • Info Outside of Scope Require TP/Board Approval • Liaison Contacts Help Manage Flow • Work Groups Empowered to Engage • Work Groups Inform TP of Requirements for Liaison • Once agreed – working groups can directly work with the external organisation

8. Technical Decision Making • Consensus driven approach • Groups Should Seek Consensus on Decisions • Votes Possible When Consensus is Not Achievable – should remain the exception • Consensus in Physical or Real-Time Meetings • Can Determine Status in meeting • Should Not Use Sparse Attendance to Drive Issues Through • Consensus in Non-Real-Time Meetings • Should Permit Delegates Have at Least 7 Days to Respond • Chair Should Consider Outside Factors in Setting Timeline • Holidays, Scheduled Meetings, System Outages • Voting – If needed • Voting may be secret or open as decided by the group • 67% threshold to approve

9. Document Numbering • Permanent Documents • Specifications and Reports • Internal Documents • Documents Submitted to a Particular Meeting

10. Field Use, Format and Remarks Examples <affiliate> This field MAY be provided to indicate the affiliate organisation that produced the spec. The future usage of affiliate names requires further consideration, and it is desirable that any new work initiated in OMA does not have the affiliate name in the document name. SYNCML, LIF, WV, WAP etc. OMA-WV_Arch-V1_1-20021001-A <functional area> This field SHALL be provided. The field provides an abbreviated name of the document function in the working group. It shall be a unique identification of the functional area, distinguishing between different working groups that may be working on the same functional area. DLOTA-REQ, DLOTA-ARCH, WML, etc. <version> This field SHALL be provided. This field shall refer to a version of the document. V1_0, V2_1. <date> This field SHALL be provided and is the date when the document was posted to the document archive. 20020620 <state> • This field SHALL be provided and indicates the state of the specification, these states being: • ‘A’ for Approved ‘C’ for Candidate • ‘D’ for Draft ‘E’ for Expired • ‘O’ for Obsolete ‘R’ for Restricted Draft (OMA Internal) • Existing other states from OMA affiliates not accommodated or mappable into this list should be preserved and not reused if there is any risk of confusion. D, A etc. Permanent Document Numbering “OMA-“ {<affiliate> “-”} <functional area> “-” <version> “-” <date> “-” <state>

11. Field Use Remarks <x> Major Version Indicator This field shall identify the major version of the document, as determined by the working group. This field SHALL be provided. Major versions are likely to contain major feature additions; may contain incompatibilities with previous document or specification revisions; and though unlikely, could change, drop, or replace standard or existing interfaces. Initial releases are “1_0”. <y> Minor Version Indicator Minor version of the document. This field shall be provided. It is incremented every time a minor change is made to the document by the working group. Minor versions are likely to contain minor feature additions, be compatible with published the preceding Major_Minor specification revision including existing interfaces, although it may provide evolving interfaces. The initial minor release for any major release is “0”, i.e. 1_0 <z> Service Indicator Service indicator for the document. Incremented every time a change is made to the published document by the working group. This field is optional, i.e. the equivalent of “_0” for initial Major_Minor releases but SHALL be provided whenever a service release of the document is made. The first service indicator release SHALL be “_1” for any Major_Minor release. Service indicators are intended to be compatible with the Major_Minor release they relate to but add bug fixes. No new functions will be added through the release of Service Indicators. Permanent Document Version <version> = “V” <x> “_” <y> { “_” <z> }

12. Work with other Fora Eg. 3GPP (MMS) WORK ITEM CREATION Step1 DETAILED TECHNICAL WORK Step4 ASSIGNMENT BY TP TO WG Step2 VALIDATION & IOP Step5 REQUIREMENTS Step3 Approved Specs Work Activities : Process Flow

13. Work Activities : Process Flow (1 of 3) • Work Item Development • Stage 1: WI Creation • Stage 2: WI Refinement (Following Failure to Approve) • Stage 3: Submission of a WI to the TP • Stage 4: Technical Plenary Approval of WIs • Charters Reflecting the WI Scope • Stage 4.1: Assignment of WI in the Scope of WG • Stage 4.2: Assignment of WI not in the Scope of WG • Stage 4.3: Assignment to a New WG • Stage 5: Review of Revised / New Charters for Assigned WIs • Stage 6: Approval of Revised / New Charters for Assigned WIs

14. Work Activities : Process Flow (2 of 3) • High Level Requirements Document (RD) • Stage 7: Producing the Requirements Document • Stage 8: Requirements Document Review • Stage 9: R&A of the RD by the Technical Plenary • Detailed Specification Creation • Stage 10: Creation of the Architecture Document • Stage 10.1: Architecture Document Review • Stage 11: Creation of the Enabler Package • Stage 11.1: Consistency Review • Stage 12: Candidate Submission for Review and Approval • Stage 13: Approval of the Candidate Specification

15. Work Activities : Process Flow (3 of 3) • Candidate Validation and Approval • Stage 14: Public Review • Stage 15: Validation Task Transfer to IOP • Stage 16: Enabler Test Plan and Enabler Test Specification Document Creation • Stage 17: Interoperability Testing, Problem Report Generation and Handling • Stage 18: Submission of Final Candidate Spec(s) for Approval • Stage 19: Approving the Candidate as an Approved Spec • Stage 20: Post Technical Plenary Approval Process

16. Process reviews • Required reviews • Requirements Document • Architecture Document • Enabler Packages : collection of specifications suite defining an enabler • Handling Reviews • Preliminary Reviews • Scheduling of Formal Reviews • Availability of Material • Handling of Comments • Update of Material and Review Response • Follow-up Reviews • Submission to Technical Plenary

17. Access to OMA specifications • Specifications can be retrieve from the public web site • www.openmobilealliance.org • Traditionally this has been approved and candidate specification • New policy of openness will expose draft specification, … • Technical reflector for comments from anyone outside OMA

18. Summary • TP is fully responsible for the technical work in OMA • Decisions are consensus driven • A well defined process exists to create technical specifications • Non blocking process • WI driven & market driven requirements

19. Thank you!