विशिष्टता व्यवस्थापन प्रक्रिया कागजात (SMPD)

ब्लूटूथ - प्रक्रिया कागजात

• संशोधन: V27
• संशोधन मिति: २०१-2019-०05-१।
•  प्रतिक्रिया ईमेल: BARB-feedback@bluetuth.org

सार:
यस कागजातले ब्लुटुथ विशिष्टताहरू र सेतो कागजातहरू सिर्जना गर्न र विस्तार गर्नको लागि विकास प्रक्रियाहरू परिभाषित गर्दछ।

संशोधन इतिहास

हालसालैको संस्करणमा योगदानकर्ताहरू

यो कागजात, यसको शीर्षक वा सामग्रीको पर्वा बिना, ब्लुटुथ निर्दिष्ट इक छैन ब्लुटुथ हस्ताक्षर इंक ("ब्लुटुथ हस्ताक्षर") द्वारा ब्लुटुथ पेटेन्ट / प्रतिलिपि अधिकार इजाजतपत्र सम्झौता र ब्लुटुथ ट्रेडमार्क इजाजत पत्र सम्झौता अन्तर्गत यसका सदस्यहरू द्वारा प्रदान लाइसेन्सको अधीनमा।

यस कागजातलाई "जैसा छ" र ब्लुटुथ हस्ताक्षर प्रदान गरिएको छ, यसको सदस्यहरू छन्, र उनीहरूको अफरियलले कुनै प्रतिनिधित्व वा वारेन्टी बनाउँदैन र अस्वीकृत सबै वारेन्टीहरू, स्पष्ट वा उत्तरार्जित, कुनै पनि वारेन्टीमा हस्ताक्षर गर्दछ यस कागजातको सामग्री त्रुटिहरूको नि: शुल्क हो।

कानून, ब्लुटुथ हस्ताक्षर, यसको सदस्यहरू, र उनीहरूले यस कागजात र कुनै पनि सूचना, यस संस्थाको अन्तर्गत कुनै पनि सूचना, प्रयोगका माध्यमबाट कुनै पनि जानकारीको प्रयोग गर्न सम्बन्धित सबै दायित्व वा यसको अस्वीकरणबाट अस्वीकार गरेको विस्तारमा रुचि, वा विशेष, व्यक्तिगत, वाणिज्यिक, दंडात्मक क्षतिहरू, यद्यपि कारण तथा दायित्व सिद्धान्तको नियमित र यदि ब्लुटुथ हस्ताक्षर छ भने, यसको सदस्य वा तिनीहरूको अफसोस सम्भव छ।

यो कागजात ब्लुटुथ SIG को स्वामित्व हो। यो कागजातले ब्लुटुथ SIG र यसको सदस्यहरूको बौद्धिक सम्पत्ति हो वा विषय समावेश गर्न सक्छ। यस कागजातको प्रस्तुत गर्नाले ब्लुटुथ SIG वा यसको सदस्यहरूको बौद्धिक सम्पत्तीलाई कुनै अनुमति दिदैन।

यो कागजात सूचना बिना परिवर्तनको विषय हो।

प्रतिलिपि अधिकार © २००––२०१ Bluetooth ब्लूटूथ SIG, Inc द्वारा। ब्लुटुथ शब्द मार्क र लोगोहरू ब्लुटुथ SIG, Inc द्वारा स्वामित्वमा छन्। अन्य तेस्रो-पार्टी ब्रान्ड र नामहरू उनीहरूको सम्बन्धित मालिकहरूको सम्पत्ति हुन्।

 

1. परिचय

विशिष्टता प्रबन्धन प्रक्रिया कागजात (SMPD) प्रक्रियाहरु कि निर्दिष्टीकरण लेखक र पुनः वर्णन गर्दछviewers नयाँ विनिर्देशों को विकास गर्न को लागी र विद्यमान विनिर्देशों को बृद्धि गर्न को लागी पालन गर्नु पर्छ (यानी, कार्यक्षमता थप्न वा हटाउन को लागी वा एक अपनाईएको विशिष्टता मा विशिष्ट कार्यक्षमता परिवर्तन गर्न को लागी), अपनाईएको विशिष्टताहरु लाई कायम राख्न को लागी, र अपनाईएको विशिष्टता को जीवन को अन्त को प्रबंधन को लागी। यसको अतिरिक्त, यो कागजात सिर्जना को लागी प्रक्रिया को वर्णन गर्दछ, पुनview, र श्वेत पत्रहरु अनुमोदन।

त्यहाँ नयाँ विशिष्टताहरू विकास गर्न र ती कार्यहरूको दायरामा अन्तरनिहित भिन्नताका कारण अवस्थित विनिर्देशहरू बढाउने बीच विशिष्टता विकास प्रक्रियामा भिन्नताहरू छन्; ती कागजातहरूमा ती भिन्नताहरू हाइलाइट गरिएका छन्।

विशिष्टता विकास प्रक्रिया समावेश:

• एक आवश्यकता चरण (सेक्शन in मा वर्णन गरिएको) कार्यात्मक आवश्यकताहरूलाई परिभाषित गर्न
• एक विकास चरण (धारा ४ मा वर्णन गरीएको) को विकास र पुनःview विनिर्देशहरू
• एक प्रमाणीकरण चरण (सेक्सन in मा वर्णन गरिएको) इंटरोपेरेबल प्रोटोटाइप (IOP) परीक्षणको माध्यमबाट विनिर्देशहरूलाई मान्य गर्न।
• अंगीकरण / स्वीकृति चरण (धारा in मा वर्णन गरिएको) ब्लुटुथ हस्ताक्षर बोर्डको निर्देशक (BoD) लाई पेश गर्ने / अनुमोदनको लागि निर्दिष्ट गर्न।

विशिष्टता इरेटा प्रक्रिया कागजात (EPD) [3] प्रस्ताव र पुनः को लागी प्रक्रिया को वर्णन गर्दछviewआईएन स्पेसिफिकेशन इरेटा, र उनीहरुलाई इरेटा सुधारको रूपमा अनुमोदन (जस्तै उपनियम [2] मा परिभाषित) अपनाईएको स्पेसिफिकेशन्स को लागी। अन्यथा उल्लेख नभएसम्म, यो SMPD मा इरेटा को सबै सन्दर्भ विनिर्देशन इरेटा मतलब।

१.१ प्राथमिकता

ब्लुटुथ SIG, Inc. (Blaws) र सदस्यता सम्झौता [2] का Bylaws ती कागजातहरू र SMPD मा कुनै पनि विवादास्पद सामग्री भन्दा प्राथमिकता लिन्छ। यस कागजातमा केहि पनि नभए पनि बोडले कार्यवाही गर्ने र निर्णय गर्ने अन्तिम विवेक र अधिकार राख्छ यदि ती कार्यहरू र निर्णयहरू यस कागजातको कुनै पनि कुरासँग पछ्याउँदैनन् वा विवादास्पद हुँदैनन्, र यस कागजातमा केहि पनि बोअडको स्वतन्त्र अधिकारलाई सीमित वा सीमित गर्दैन। र विवेक

यदि त्यहाँ SMPD र आंकडामा पाठको बीचमा कुनै द्वन्द छ भने, पाठ प्राथमिकता लिन्छ।

१.२ सन्दर्भित समूह र समितिहरू

समूह को निम्न प्रकार यस दस्तावेज मा सन्दर्भित छन्: अध्ययन समूह (एसजी), विशेषज्ञ समूह (ईजी), र कार्य समूह (डब्ल्यूजी)। एक WG सँग एक उपसमूह पनि हुन सक्छ जो WG लाई रिपोर्ट गर्दछ। यसै गरी, समितिका निम्न प्रकार यस दस्तावेज मा सन्दर्भित छन्: ब्लूटूथ वास्तुकला रेview बोर्ड (BARB), ब्लुटुथ परीक्षण र अन्तरक्रियात्मकता (BTI), र ब्लुटुथ योग्यता पुनःview बोर्ड (BQRB)। यो कागजातले ब्लुटुथ SIG टेक्निकल स्टाफ (BSTS), र BoD लाई बुझाउँछ।

१.३ समिति पुनःviewर अनुमोदन

एक समिति पुनview पुन होview कि एक समिति (सामान्यतया ३ सदस्य) का सदस्यहरु द्वारा एक निर्दिष्ट समय (सामान्यतया २-३ हप्ता) मा प्रतिक्रिया प्रदान गर्न को लागी आयोजित गरिन्छ, तर पुनःview समय लम्बाइ र सामग्री को जटिलता र समिति भित्र अन्य प्राथमिकताहरु को आधार मा भिन्न हुन सक्छ। पुनः अनुरोध गर्ने समूहview र पुनः सञ्चालन गर्ने समितिview प्रत्येक पुनः को अवधि मा सहमतview। समूह र समितिका सदस्यहरु ब्लुटुथ SIG उपकरणहरु को उपयोग गर्न को लागी सूचित र पुनः को शुरू र अन्त्य रेकर्ड गर्न को लागीview। समूह सामान्यतया समिति प्रतिक्रिया प्रक्रिया हुनेछ जब यो प्राप्त हुन्छ। जब समिति पुनview समय समाप्त हुन्छ, समूह समिति को प्रतिक्रिया लाई सम्बोधन पूरा गर्दछ, र कुनै पनी ढिलो आउने पुनः विचार गर्नु पर्छview प्रतिक्रिया दिमागमा राख्दै कि सामग्री समिति द्वारा अनुमोदन को अधीनमा हुन सक्छ।

कार्यसमिति प्रक्रिया कागजात []] अनुपालनमा समिति सदस्यहरूको मतले समितिको स्वीकृति प्राप्त हुन्छ।

१.1.4 सदस्यहरूलाई सूचना र सामग्रीको पहुँच

यस कागजातको अनुसरणकर्तालाई प्रदान गरिएका सबै सूचनाहरू ईमेल द्वारा प्रदान गर्न सकिन्छ, जस्तै आवधिक टेक्निकल अपडेट। सबै सदस्यलाई प्रदान गरिने सूचनाहरू सबै सक्रिय सदस्यहरूलाई पठाइने छ (उदाहरणका लागि, जहाँ सदस्यता निलम्बित गरिएको छैन, समाप्त भएको छ, वा फिर्ता लिइएको छैन)। सूचनाहरू ईमेल भए पछि तिनीहरू अन्तिम-ज्ञात ईमेल ठेगानामा पठाइने छ (ब्लुटुथ सिगको तत्कालीन रेकर्डमा प्रतिबिम्बित) प्रत्येक व्यक्ति जसले सदस्य कम्पनीको सदस्यता खाता अन्तर्गत दर्ता गरेका छन् र जसले ईमेल सूचनाहरू प्राप्त गर्न अप्ट-आउट गरेनन्। यस कागजातमा केहि पनि ब्लुटुथ हस्ताक्षर दायित्व वा आवश्यकताहरू बदल्छ बाइलेज अन्तर्गत सूचनाको प्रावधानको सन्दर्भमा वा ब्लुटुथ हस्ताक्षर र कुनै पनि सदस्यको बीचमा कुनै अन्य सम्झौतामा।

जहाँ पनी यो कागजात एक जनाउँछ webसाइट जुन सबै सदस्यहरु को लागी सुलभ छ, यो व्यक्तिहरु जो एक सक्रिय ब्लूटूथ SIG खाता छ को लागी पहुँच लाई जनाउँछ। सदस्यहरु जो एक सक्रिय खाता छैन ब्लुटुथ SIG मार्फत एक खाता बनाउन सक्छ webसाइट।

1.5 टेम्प्लेटहरू

प्रत्येक कागजात प्रकार को लागी (उदाहरण को लागी, निर्दिष्टीकरण, सेतो कागजात, परीक्षण कागजात) यो SMPD मा निर्दिष्ट, ब्लूटूथ SIG एक टेम्पलेट प्रदान गर्दछ। टेम्पलेट यो SMPD अनुसार उत्पादन प्रत्येक कागजात को लागी एक आधार को रूप मा प्रयोग गरीनु पर्छ। सही टेम्प्लेट प्रयोग गर्न असफलता कागजात अनुमोदित नहुन सक्छ। टेम्पलेट्स ब्लुटुथ SIG मा उपलब्ध छन् webसाइट [8]।

१.1.6 विशिष्ट प्रकारहरू

त्यहाँ ब्लुटुथ SIG विशिष्टताहरु को धेरै प्रकार छन्। पदानुक्रम, सबै विशिष्टताहरु ब्लुटुथ कोर विशिष्टता मा निर्भर गर्दछ। परम्परागत प्रो जस्तै निर्दिष्टीकरणfiles; परम्परागत प्रोटोकल; र GATT- आधारित प्रोfiles, GATT- आधारित सेवाहरु, र GATT- आधारित प्रोटोकल सबै कोर विशिष्टता भित्र सुविधाहरु मा निर्भर गर्दछ। अन्य विशिष्टताहरु, जस्तै मेष मोडेल विशिष्टताहरु, मेष प्रो मा निर्भर गर्दछfile विनिर्देश जो बारी मा कोर विशिष्टता मा निर्भर गर्दछ।

कोर विशिष्टता पूरक (CSS) विनिर्देशन डेटा प्रकार, डाटा ढाँचा, र साधारण प्रो परिभाषित गर्दछfile र सेवा त्रुटि कोडहरु कि कोर विशिष्टता र अन्य विशिष्टताहरु द्वारा प्रयोग गरीन्छ र आफैं कुनै व्यवहार को परिभाषित गर्दैन।

GATT विशिष्टता पूरक (GSS) विनिर्देशन विशेषता र डिस्क्रिप्टर ढाँचा कि प्रो द्वारा प्रयोग गरीन्छ परिभाषित गर्दछfileर सेवाहरु र आफैंमा कुनै पनि व्यवहार परिभाषित गर्दैन।
मेष उपकरण गुण (MDP) विनिर्देश जाल प्रो द्वारा प्रयोग जाल गुण परिभाषित गर्दछfile र जाल मोडेल विशिष्टताहरु र आफैं कुनै व्यवहार को परिभाषित गर्दैन।

 

१. ओभरview

यो खण्ड एक ओभर प्रदान गर्दछview प्रक्रियाहरु को र सबै विवरणहरु लाई समेट्ने उद्देश्य छैन।

चित्र २.१ ले छ वटा प्रमुख चरणहरू देखाउँदछ जसले विशिष्टता व्यवस्थापन प्रक्रिया गर्छ।

पहिलो चार चरणहरू विशिष्टता विकास प्रक्रियाको क्रममा देखा पर्दछ र आवश्यकता चरणहरू (सेक्सन)), विकास चरण (सेक्सन)), मान्यकरण चरण (सेक्सन)), र दत्तक / स्वीकृति चरण (सेक्सन)) समावेश गर्दछ। यो पछाडि दुईपश्चात अपनन चरणहरू छन्: निर्दिष्ट रखरखाव चरण (सेक्सन 3) र विशिष्ट जीवन अन्त चरण (सेक्सन))।

चित्र २.२ ले विशिष्टता विकास प्रक्रिया भित्र चार चरणहरूको विवरण चित्रण गर्दछ। खैरो बक्सहरूले प्रत्येक चरणको लागि प्रमुख छुटकारा स indicate्केत गर्दछ। सुन्तला बक्सहरूले प्रक्रियाका माइलस्टोनहरू सारांश गर्दछ।

आवश्यकता चरणमा (सेक्सन in मा वर्णन गरिएको) नयाँ काम सुरु गर्न प्रस्ताव (नयाँ कार्य प्रस्ताव (NWP)) यदि नयाँ काम अगाडि बढ्छ भने सक्षम हुन प्रयोगकर्ता परिदृश्यहरू परिभाषित गरेर विशिष्टता विकास प्रक्रिया सुरू गर्दछ। यदि NWP स्वीकृत भयो भने, एउटा निर्दिष्ट समूहले एक फंक्शनल आवश्यकता कागजात (FRD) सिर्जना गर्दछ। एक पटक FRD स्वीकृत हुन्छ र एक समूह को लागी, विकास चरण शुरू हुन्छ।

विकास चरण को दौरान (धारा ४ मा वर्णित), विनिर्देशन विकास एस को एक अनुक्रम को माध्यम बाट प्रगतिtages (०.५/डीआईपीडी ०.0.5/सीआर) विनिर्देशन को एक पूरा मस्यौदा मा समाप्त। ०.0.9/सीआर विनिर्देशन सबै सदस्यहरु को लागी उपलब्ध गराईन्छ, त्यसपछि BoD लाई पेस गरीयो जो अनुमोदन को लागी विनिर्देश लाई विचार गर्दछ। एक पटक अनुमोदित, प्रमाणीकरण चरण शुरू हुन्छ।

विनिर्देशन विकास को मान्यीकरण चरण को दौरान (धारा ५ मा वर्णित), BoD द्वारा अनुमोदित ०.5/सीआर विनिर्देशन सबै सदस्यहरुलाई पुन: उपलब्ध गराईन्छ।view र मान्य, र सदस्य पुनview सुरु भएको छ। प्रमाणीकरण अन्तर्क्रिया (IOP) प्रोटोटाइपहरु को बीच सदस्यहरु द्वारा बनाईएको बीच परीक्षण को माध्यम बाट पूरा गरीन्छ। एक पटक IOP परीक्षण पूरा भएपछि (यदि स्पेसिफिकेशन को लागी आवश्यक छ) र BARB IOP परीक्षण रिपोर्ट लाई अनुमोदन गर्दछ, तब दत्तक ग्रहण/अनुमोदन चरण शुरू हुन्छ।

दत्तक / स्वीकृति चरणको समयमा (सेक्सन in मा वर्णन गरिएको), विशिष्टता र सम्बन्धित परीक्षण कागजातहरू अन्तिम हुन्छन्; BARB, BQRB, र BTI अनुमोदनहरू प्राप्त भयो; र अन्तिम विशिष्टता प्याकेज BoD लाई पेश गरिएको छ जसले अपननको लागि विशिष्टतालाई विचार गर्दछ (उदाहरणका लागि अन्तिम अनुमोदन)।

एक विनिर्देशन एक अघिल्लो चरण वा s मा फर्कन को लागी आवश्यक हुन सक्छtage यदि महत्वपूर्ण परिवर्तन गरीन्छ। केहि अवस्थामा, यो पनि एक चरण को भाग माफ गर्न को लागी सम्भव हुन सक्छ धारा ४.४ मा वर्णन गरीएको छ।

विशिष्ट रखरखाव चरण (सेक्सन in मा वर्णन गरिएको) BoD द्वारा अपनाईएको विनिर्देशको पछि सुरू हुन्छ। यस चरणको अवधिमा एक अपनाईएको विशिष्टतामा भेटिएका सम्भावित त्रुटिहरू रिपोर्ट गरीएको र मूल्याated्कन गरिन्छ, र (यदि आवश्यक भएमा) एर्राटा सुधारहरू विशिष्टिकरणमा गरिन्छ। विशिष्ट रखरखाव चरण जारी रहन्छ जबसम्म विनिर्देशन अस्वीकृत वा फिर्ता लिइदैन (निम्नलिखित अनुच्छेदमा विशिष्ट चरण अन्त-जीवन चरण हेर्नुहोस्)।

विशिष्टताको अन्त्य-लाइफ फेज (सेक्सन described मा वर्णन गरिएको) ले अपनाईएको विशिष्टताहरू अस्वीकृत गर्ने र फिर्ता लिने प्रक्रियाको वर्णन गर्दछ।

 

Ire. आवश्यकता चरण

आवश्यकता चरण या त एक NWP (जसले एक वा बढी प्रयोगकर्ता परिदृश्यहरूमा काम सुरू गर्ने इच्छालाई दर्साउँछ) बाट शुरू गर्दछ वा निर्धारित संकल्प पछि कि इच्छित नयाँ कार्य पहिले नै उनीहरूको WG चार्टरले कभर गरेको छ। यदि एक WG नयाँ काम शुरू गर्न चाहान्छ भन्ने विश्वास गर्दछ जुन पहिले नै यसको WG चार्टरको दायरा भित्र छ, WG ले सेक्सन 3.1..१ मा परिभाषित प्रक्रिया अनुसरण गर्नुपर्नेछ प्रत्यक्ष FRD विकास गर्न अगाडि बढ्नको लागि। सबै अन्य कार्य वस्तुहरूको लागि, WG ले सेक्सन 3.2..२ मा परिभाषित प्रक्रिया अनुसरण गर्नुपर्नेछ। FRD ले विकास चरणमा विशिष्टताहरू निर्माण गर्न प्रयोग हुने कार्यात्मक आवश्यकताहरूको दायरा परिभाषित गर्दछ। आवश्यकता चरण चित्र 3.1.१ मा चित्रित छ।

3.1.१ नयाँ काम WG चार्टर द्वारा कभर गरिएको

जब एक WG नयाँ काम शुरू गर्न चाहान्छ र तर्कसंगत रूपमा विश्वास गर्दछ कि यो थप्न चाहेको कार्यक्षमता पहिले नै यसको WG चार्टरको दायरा भित्र छ, WG ले FRD मा काम सुरु गर्न सक्दछ, यदि उनीहरूले तुरून्त BARB लाई सूचित गरे भने। WG ले BARB लाई आफ्नो अधिसूचनामा प्रस्तावित नयाँ कार्यको विवरण र भाषाको साथ WG चार्टरको एक प्रतिलिपि समावेश गर्दछ जसले तिनीहरूलाई नयाँ काम सुरु गर्न अधिकृत गर्दछ।

यदि BARB ले WG विश्लेषण अस्वीकार गर्दछ, WG ले FRD मा काम रोक्नु पर्छ र NWP प्रक्रिया अगाडि धारा 3.2..२ मा बताईएको छ। यदि BARB ले WG को विश्लेषणलाई अनुमोदन गर्दछ, WG ले तुरून्त BSTS लाई सूचित गर्नेछ (specification.manager@bluetuth.com मा ईमेल मार्फत) र BSTS ले आइटम BoD एजेन्डामा वस्तु थप्नेछ।

WG ले यसको सूचनालाई BSTS मा समावेश गर्दछ उस्तै जानकारी जुन BARB लाई प्रदान गर्दछ। यदि BoD ले WG को विश्लेषण अस्वीकार गर्छ भने WG ले FRD मा काम रोक्नु पर्छ र NWP प्रक्रियालाई धारा 3.2..२ मा बताई अगाडि बढ्नु पर्छ। यदि बोडले डब्ल्यूजीको विश्लेषणलाई अनुमोदन गर्छ भने, डब्ल्यूजीले धारा 3.3..XNUMX मा उल्लिखित एफआरडीमा काम गर्न जारी राख्न सक्छ।

3.2.२ नयाँ कार्य प्रस्ताव (NWP)

कुनै सदस्य, WG, SG, वा EG बनाउन र एक NWP सबमिट गर्न सक्नुहुन्छ (ब्लुटुथ SIG को माध्यम बाट webसाइट [१०])। एक NWP मा कम से कम, निम्न मा जानकारी प्रदान गरीएको आधिकारिक टेम्प्लेट [10] मा प्रयोग गरीएको हुनुपर्छ:

• प्रयोगकर्ता परिदृश्य
• सदस्य प्रतिबद्धता को FRD को विकास र कुन क्षेत्र (हरू) मा (जस्तै, योगदानकर्ता, लेखक, पुनviewer, प्रोटोटाइप)
• FRD काम को प्रस्तावित नेतृत्व
• FRD काम को लागी प्रस्तावित समूह असाइनमेन्ट
• प्राथमिक लेखक (हरू) को ईमेल ठेगाना

नोट: NWP प्रक्रिया मा मार्गदर्शन ब्लुटुथ SIG मा उपलब्ध छ webसाइट [10]।

BSTS निम्न कार्यहरू NWP को विकासको बखत गर्नेछ:

• लेखक (हरू) लाई रसीदको पावती प्रदान गर्नुहोस् (सामान्यतया रसिदको सात पात्रो दिन भित्र) र अर्को चरणहरूको रूपरेखा बनाउनुहोस्।
• यदि आवश्यक भएमा, लेखक (हरू) सँग काम गर्नुहोस् ताकि NWP स्पष्ट र पूर्ण हो। यसको लागि NWP को धेरै पुनरावृत्तिहरू आवश्यक पर्दछ।
• यदि NWP अपनाईएको ब्लुटुथ विशिष्टताहरु मा त्रुटिहरु को बारे मा बयानहरु छन्, लेखक (हरु) संग काम गर्नुहोस् file इरेटा प्रणाली मा प्रविष्टि।
• यदि यो याद गरियो कि NWP सम्भावित नक्कल कार्य हो जुन पहिले नै प्रगतिमा छ वा पहिले नै पूर्ण भइसकेको छ भने, लेखकलाई उनीहरूको मूल्या for्कनका लागि अन्य कामका बारे सूचित गर्नुहोस्।
• NWP लाई NWP मा पोस्ट गर्नुहोस् webसाइट सबै सदस्यहरु को लागी सुलभ छ।
• सबै सदस्यहरुलाई सूचित गर्नुहोस् कि NWP पुनः को लागी उपलब्ध छview र FRD को विकास को लागी अतिरिक्त सदस्य प्रतिबद्धता को आवश्यकता छ।

सदस्यहरूले प्रश्नहरू सोध्न वा NWP को सम्बन्धमा प्रतिक्रिया प्रदान गर्न लेखक (हरू) लाई सम्पर्क गर्न सक्दछन्।

कम्तिमा तीन सदस्य कम्पनीहरूले BW स्वीकृतिका लागि उम्मेदवार बन्न NWP को नतिजा एफआरडी पूरा गर्नमा भाग लिन प्रतिबद्ध हुनुपर्दछ, र कम्तिमा एक सदस्य कम्पनी एक सहयोगी वा प्रमोटर सदस्य हुनुपर्दछ। NWP को BoD अनुमोदन पछि, BoD ले NWP लाई विद्यमान सबै-सदस्य WG उपसमूह वा SG लाई FRD मा काम गर्दछ (भाग will. Section मा वर्णन गरिएको छ)। यदि उपयुक्त WG उपसमूह वा SG अवस्थित छैन भने, एक सिर्जना गर्न सकिन्छ।

NWPs का लागि पर्याप्त सदस्य प्रतिबद्धता छ, BSTS ले निम्न थप कार्यहरू गर्दछ:

• कम्तिमा १ 13 दिन अगाडि एनडब्ल्यूपीले BoD द्वारा अनुमोदन प्रस्ताव गरिएको छ, BARB लाई सूचित गर्नुहोस्, र NWP लाई पेन्डिंग NWP अनुमोदनको लागि NWP सिफारिस गरिएको छ। यो प्रस्तावित समूह जस्ता क्षेत्रहरूमा प्रतिक्रियाको लागि अवसर प्रदान गर्न गरिन्छ, एनडब्ल्युपी पहिले नै अवस्थित कार्यले समेटिएको छ आदि।
• पूरा NWP BoD मा बुझाउनुहोस्।

1. यदि एनडब्ल्यूपी सदस्यहरु द्वारा पेश गरीएको छ जुन कुनै समूहसँग सम्बद्ध छैन, सदस्यहरु मध्ये एक जनालाई एनडब्ल्यूपीलाई BoD समक्ष प्रस्तुत गर्ने व्यवस्था गर्नुहोस्।
2. यदि एनडब्ल्यूपी एक समूह द्वारा पेश गरीएको छ भने, समूह अध्यक्षलाई बोर्डलाई एनओडब्लूपी पेश गर्न को लागी व्यवस्था गर्नुहोस्।
3. BARB अध्यक्ष र समूहका अध्यक्षहरुलाई निम्तो दिनुहोस्, जहाँ NWP लाई असाइनमेन्टको लागि सिफारिस गरिएको छ, BoD बैठकमा।
4. यदि NWP स्वीकृत र BoD द्वारा तोकिएको छ, यो कार्य तोकिएको समूहलाई सूचित गर्नुहोस्; लेखक (हरू); NWP मा सम्बन्धित एफआरडी विकास गर्न प्रतिबद्धको रूपमा पहिचान भएका सदस्यहरू; र यदि NWP एक समूह द्वारा प्रस्तावित छ, परिणाम को समूह र अर्को चरणहरू।

एक NWP BoD द्वारा अनुमोदित भए पछि, NWP मा स्थिति अपडेट गर्नुहोस् webसाइट।

कुनैपनि एनडब्ल्यूपी बीओडी द्वारा यसको विवेक मा अस्वीकार गर्न सकिन्छ, पूर्व को लागीample, संसाधन सीमाहरु को कारण, यदि काम पहिले नै पुरा गरीएको छ, काम ब्लुटुथ SIG (जस्तै, आवेदन प्रोग्रामिंग इन्टरफेस (API)) [2] को शासी कागजात को दायरा बाहिर छ, वा यदि प्रस्तावित काम हुनु पर्छ filed एक त्रुटि को रूप मा। यदि NWP लाई अस्वीकार गरियो भने, BSTS ले लेखक (हरू), NWP मा पहिचान गरिएका सदस्यहरुलाई सम्बन्धित FRD को विकास गर्ने प्रतिबद्धता को रूप मा सूचित गर्दछ, र, यदि NWP एक समूह, समूह द्वारा प्रस्तावित छ। अधिसूचना अस्वीकार को लागी कुनै पनि कारण समावेश हुनेछ। लेखक (हरू), प्रतिबद्ध सदस्यहरु, वा समूह अस्वीकृति अपील गर्न BoD एजेन्डा मा समय अनुरोध गर्न सक्छन्।

यदि कुनै सदस्य वा समूहले एउटा अपनाईएको विशिष्टताबाट कुनै सुविधा हटाउने प्रस्ताव गर्न चाहान्छ भने, समूह वा सदस्यले एनडब्ल्यूपी तयार गर्नुपर्दछ। एनडब्ल्यूपीले प्रभावको विश्लेषण समावेश गर्नुपर्दछ जुन हटाउनेले पिछडिएको अनुकूलता र ईन्टरोपेरेबिलिटीमा टेस्ट केसहरूमा पार्ने प्रभावको विश्लेषण सहित समावेश गर्दछ।

एनडब्ल्यूपीहरू सीएसएस, जीएसएस, वा एमडीपी विशिष्टताहरूमा सुधारको लागि आवश्यक छैन: सामान्यतया, सीएसएस, जीएसएस, वा एमडीपी विनिर्देशहरूको अद्यावधिकको परिणामस्वरूप उनीहरूको NWPs भएका अन्य विनिर्देशहरूको अपडेट हुन्छ।

3.3 कार्यात्मक आवश्यकता कागजात (FRD)

FRDs प्रयोगकर्ता परिदृश्य सक्षम गर्न कार्यात्मक आवश्यकताहरू परिभाषित गर्दछ। एक FRD ले कम्तिमा पनि, निम्नको बारेमा जानकारी समावेश गर्नुपर्दछ [8] मा प्रदान गरिएको आधिकारिक टेम्प्लेट प्रयोग गरेर।

• प्रयोगकर्ता परिदृश्य
• प्रयोगकर्ता परिदृश्यमा आधारित कार्यात्मक आवश्यकताहरू
• नतिजा विनिर्देश (हरू) को विकास गर्न सदस्य प्रतिबद्धता
• अपेक्षित भूमिकाहरूको लागि सदस्यहरूद्वारा वैकल्पिक प्रोटोटाइप समर्थन
• परिणामस्वरूप विशिष्टता (हरू) विकसित गर्न WG सिफारिश गरियो

FRD विकास

FRDs तोकिएको सबै-सदस्य WG उपसमूह वा BGS बाट संपादकीय समर्थनको साथ SG सदस्यहरू द्वारा सिर्जना गरिएको हो। एफआरडी विकासमा भाग लिन चाहने कुनै पनि सदस्य समूहमा सामेल हुन सक्छ।

एफआरडीले कम्तिमा दुई बाट प्रतिबद्धता जनाउनु पर्छ (तीन जनालाई प्रोत्साहित गरिए पनि) सहयोगी वा प्रमोटर-स्तर सदस्य कम्पनीहरूले परिणामस्वरूप विशिष्टताको विकासमा भाग लिनका लागि। WGs वा SGs जसले FRD बुझाउछ उसले FRD मा पहिचान गरीएको लक्षित उद्योग खण्ड प्रतिनिधित्व गर्ने समूह सदस्य कम्पनीहरुबाट व्यापक समर्थन प्राप्त गर्न कोशिस गर्नुपर्छ।

FRD मा प्रस्तावित नयाँ कार्यक्षमता धेरै यातायात र सम्भव भएसम्म विद्यमान यन्त्रहरुमा समर्थित हुनु पर्छ। यसमा समावेश छ, पूर्व को लागीample, समर्थन GATT- आधारित प्रोfiles र दुबै आधारभूत दर/विस्तारित डाटा दर (BR/EDR) यातायात र ब्लुटुथ कम ऊर्जा (LE) यातायात मा सेवाहरु। यदि नयाँ कार्यक्षमता को लागी एक यातायात को लागी पर्याप्त सदस्य समर्थन को कमी छ, पूर्व को लागीampयातायात को उपयोग को परिभाषित गर्न को लागी सदस्य प्रतिबद्धता को कमी वा एक वा धेरै भूमिकाहरु को लागी IOP परीक्षण प्लेटफर्म को एक संभावित अपर्याप्त संख्या को कारण, कि यातायात मा समर्थन FRD बाट बहिष्कृत गर्न सकिन्छ।

जब सम्म अन्यथा उचित, नयाँ कार्यक्षमता, प्रोfiles, र सेवाहरु अनुच्छेद ३.३.२ मा वर्णित पिछडिएको अनुकूलता आवश्यकताहरु संग अनुरूप हुनुपर्छ।

WG वा SG पुन: को लागी BARB लाई FRD बुझाउनु पर्छview र अनुमोदन। BARB लाई या त अनुमोदन वा FRD लाई इन्जीनियरिंग को निर्णय को आधार मा अस्वीकार गर्नु पर्छ। यदि BARB द्वारा अनुमोदित, FRD सबै सदस्यहरु को लागी उपलब्ध गराईनेछ र यसको उपलब्धता को अधिसूचना BSTS द्वारा जारी गरिनेछ।

सीआरएस, जीएसएस, वा एमडीपी विशिष्टताको लागि एफआरडीहरू आवश्यक पर्दैन: सामान्यतया, सीएसएस, जीएसएस, वा एमडीपी विनिर्देशहरूको अद्यावधिकको परिणामस्वरूप उनीहरूको आफ्नै एफआरडी भएका अन्य विनिर्देशहरूको अपडेट हुन्छ।

पछाडि अनुकूलता आवश्यकताहरु

BR / EDR का लागि पछाडि अनुकूलता

BR / EDR अपरेशनको लागि, पछाडि अनुकूलता आवश्यकता ब्लूटूथ कोर विशिष्टता v1.1 को बीआर / EDR भागको साथ इन्कोपरेसनको रूपमा परिभाषित छ।

ब्लूटूथ कम ऊर्जा को लागी पछाडि अनुकूलता

एल अपरेशनको लागि, पछाडि अनुकूलता आवश्यकता ब्लुटुथ कोर विशिष्टता v4.0 को पछिल्लो भागको अन्तर्क्रियरणको रूपमा परिभाषित गरिन्छ।

कोर विशिष्टता बाहेक विनिर्देशहरूको लागि पछाडि अनुकूलता

ब्लुटुथ कोर विशिष्टता बाहेक अन्य विनिर्देशों को लागी, एक दिईएको संस्करण को पिछडिएको अनुकूलता सबै पुराना संस्करणहरु संग एउटै प्रमुख संस्करण संख्या छ संग राखिएको हुनुपर्छ। पूर्व को लागीample, संस्करण १.३ संस्करण १.२, १.१, र १.० संग मिल्नु पर्छ, तर संस्करण २.० संस्करण १.०, १.१, १.२, र १.३ संग मिल्दैन। ध्यान दिनुहोस् कि कोर स्पेसिफिकेशन को प्रमुख संस्करण संख्या को एक वृद्धि अघिल्लो संस्करणहरु संग पिछडिएको अनुकूलता को कमी को संकेत गर्दैन।

पछाडि संगतता आवश्यकताहरुबाट छुट

WG वा एसजी औचित्य प्रदान गरीएको छ भने पिछडिएको अनुकूलता आवश्यकता बाट विशिष्ट कार्यक्षमता मुक्त गर्न को लागी प्रस्ताव गर्न सक्छ। पूर्व को लागीample, यदि कार्यक्षमता कम बजार को गोद लिने दरहरु को लागी देखाइएको छ वा, कारण अन्तरक्रियाशीलता मुद्दाहरु को, यो हटाउन वा कार्यक्षमता परिमार्जन गर्न को लागी कार्यक्षमता प्रतिस्थापन गर्न को लागी राम्रो छ। WG वा SG FRD मा कुनै पनी पिछडिएको अनुकूलता छूट, जो FARD को अनुमोदन मा BARB द्वारा अनुमोदित हुनु पर्छ। कुनै पनि BARB- अनुमोदित छूट 0.9/CR S मा अनुमोदन को लागी BoD लाई प्रस्तुत गरिनेछtage.

3.4 कार्य समूह चार्टर

जब BARB ले एक FRD लाई अनुमोदन गर्दछ जुन विद्यमान WG लाई तोकिएको प्रस्तावित हुन्छ, कि WG ले यसको कार्यपत्रमा नयाँ कार्यक्षमता थप्नको लागि यसको ड्राफ्ट अपडेट तयार गर्नुपर्नेछ (जब सम्म BoD ले WG को विश्लेषण स्वीकृत नगरेसम्म WG चार्टर अपडेट छ। आवश्यक छैन)। जबकि, जब BARB ले एक नयाँ WG लाई तोकिने प्रस्ताव गरिएको एक FRD स्वीकृत गर्छ, BARB र FRD मा उल्लिखित कार्यक्षमता विकास गर्न चाहने सदस्यहरूले चार्टर स्कोपमा समावेश भएको नयाँ कार्यक्षमताको साथ नयाँ WG का लागि ड्राफ्ट चार्टर तयार गर्नुपर्दछ। ।

एक पटक नयाँ वा अपडेट गरिएको WG चार्टर तयार भएपछि, यो पुन: को लागी BARB मा पेश गर्नु पर्छview र अनुमोदन। एकपटक BARB ले चार्टर अनुमोदन गरेपछि, नयाँ वा अपडेट गरिएको WG चार्टरको मस्यौदा अनुमोदनको लागि BoD लाई पेश गरिनेछ।

एकपटक बोडले बडापत्र स्वीकृत गरेपछि डब्ल्यूजीले विनिर्देशन विकास कार्य बोडले तोकेको समूहसँग मिलेर काम गर्ने छ जसले एफआरडीको लागि आवश्यक अपडेटहरू वा स्पष्टीकरण आवश्यक भएमा एफआरडी तयार गर्ने समूहसँग मिलेर काम गर्नुपर्नेछ। यदि FRD अपडेट विकास चरणको दौरान आवश्यक छ भने, धारा 3.3..XNUMX मा उल्लिखित प्रक्रियाहरू र यो सेक्सन अनुसरण गर्नुपर्छ; जहाँसम्म, विनिर्देशन विकास FRD र WG चार्टर अपडेटको समानान्तर हुन सक्छ।

Requ. Requ आवश्यकताहरू चरण निकास आवश्यकताहरू

आवश्यकता चरण पूरा भयो र विकास चरण सुरु हुन्छ जब FRD का लागि आवश्यक स्कोपको साथ डब्ल्यूजी चार्टर या त BoD द्वारा पुष्टि वा अनुमोदित हुन्छ र निम्न आवश्यकताहरू पूरा भएको छ:

• NWP या त BoD द्वारा अनुमोदन गरिएको छ, वा BoD सहमत छ कि NWP अनावश्यक छ।
• FRD र सम्बन्धित WG चार्टर BARB द्वारा अनुमोदन गरिएको छ।

 

4. विकास चरण

विकास चरणको बखत, तोकिएको WG (हरू) ले नयाँ विशिष्टता सिर्जना गर्दछ र / वा अवस्थित विशिष्टता बढाउछ। FRD नयाँ वा सुधारिएको ब्लुटुथ विनिर्देशको आवश्यकताहरु परिभाषित गर्दछ। विशिष्टतामा कुनै कार्यक्षमतालाई अनुमति दिईदैन जुन उचित रूपमा FRD मा आवश्यकताहरूसँग सम्बन्धित छैन। उद्देश्य भनेको ०.0.9 / सीआर विशिष्टता सिर्जना गर्नु हो जुन विकास चरणको समापनमा मान्यकरण चरण (सेक्सन in मा वर्णन गरिएको) को लागी तयार छ।
विकास चरण को दौरान, एक विनिर्देशन (वा विशिष्टता वृद्धि) तीन s को माध्यम बाट अग्रिमtages.

नयाँ स्पेसिफिकेशन को लागी, तीन एसtages हो:

• १० एसtage
• १० एसtage
• १० एसtage

एक विशिष्टता वृद्धि को लागी, तीन एसtages हो:

• ड्राफ्ट सुधार प्रस्ताव दस्तावेज (DIPD) एसtage
• अन्तिम सुधार प्रस्ताव दस्तावेज (FIPD) एसtage
• अनुरोध परिवर्तन (सीआर) एसtage

प्रत्येक stage लाई पछि उपधाराहरुमा वर्णन गरिएको छ। चित्र ४.१ तल विभिन्न दस्तावेजहरु छन् कि WG प्रत्येक s मा तयार हुनेछtage.

चित्र ४.१: सकियोview विनिर्देशन को एसtages कि विकास चरण को दौरान हुन्छ

विनिर्देशन विकास प्रक्रिया भरि BARB को भूमिका WGs लाई सल्लाह र प्राविधिक सहयोग प्रदान गर्नु हो। WGs ले कुनै पनि समयमा BARB लाई विनिर्देशन विकास र वास्तुकला अवधारणाको बारे निर्दिष्ट गर्नका लागि अनुरोध गर्न सक्दछ। WGs विशेष गरी अधिक जटिल वास्तुकलात्मक विचार रहेको सुविधाहरूको लागि BARB बाट प्रारम्भिक प्रतिक्रिया माग्न प्रोत्साहित गरिन्छ।

4.1 0.5/डीआईपीडी एसtage

0.5/DIPD एस को समयमाtagई, WG निम्न [8] मा प्रदान गरीएको सरकारी टेम्पलेट्स को उपयोग गरेर विकास हुनेछ:

1. नयाँ विशिष्टताको लागि, ०. 0.5 निर्दिष्टताको ड्राफ्ट, जसमा समावेश हुनुपर्दछ, कम्तिमा, निम्नमा जानकारी:

• वास्तुकला FRD मा उल्लेख गरिए अनुसार आवश्यकताहरू कभर गर्न
• प्रोटोकोलका लागि, सेवा पहुँच पोइन्टहरू परिभाषित
• सेवाहरूको लागि, खुला डाटा र व्यवहार
• प्रो को लागीfiles, प्रोटोकल पहिचान र कार्यक्षमता निर्दिष्ट

२. विशिष्टता बृद्धिका लागि, DIPD को मस्यौदा, जसमा समावेश हुनुपर्दछ, कम्तिमा, निम्न बारे जानकारी:

• पृष्ठभूमि: कार्यको दायरा, उद्देश्यहरू कार्यलाई निर्देशित गर्ने, र यो विशिष्ट प्रस्ताव कसरी दायरामा फिट हुन्छ
• माथिview प्रस्ताव को: DIPD द्वारा प्रदान गरिएको विस्तारित प्रकार्य (थप लचिलोपन, सुधार गरिएको प्रदर्शन, इत्यादि) को सारांश नयाँ कार्यक्षमता कसरी हालको विशिष्टता संस्करणमा फिट हुन्छ भन्ने सम्बन्धमा स्पष्ट वर्णन सहित। यदि डब्ल्यूजीले बहु प्रस्तावहरूको मूल्याated्कन गरेको छ भने, यी प्रस्तावहरू बीएआरबीलाई चाहिने प्रस्तावको छनौटमा पर्याप्त उचित परिश्रम गरिएको छ कि भनेर निर्धारण गर्ने अवसर प्रदान गर्न समावेश गरिनु पर्दछ।
• आवश्यकताहरूको कभरेज: प्रस्ताव द्वारा दिएका कार्यात्मक आवश्यकताहरूको कभरेजको सारांश, उपयुक्त प्रणाली आवश्यकताहरू र सम्बन्धित परिदृश्यहरू सम्बन्धित एफआरडीमा दिइएको सन्दर्भको साथ।
• समस्या परिभाषा: प्रस्ताव (हरू) द्वारा समाधान गरिएको समस्याहरूको बयान
• चयन मापदण्ड: सम्बन्धित प्रक्रिया मूल्या met्कन मेट्रिकबाट चयन / प्रदर्शन मापदण्डको बारेमा विवरण जुन चयन प्रक्रियालाई निर्देशित गरिएको छ
• छनौटको औचित्य: प्रस्ताव मेट्रिक्सको एक परीक्षण जसले प्रस्तावहरू बीचको छनौटलाई जायज ठहराउँछ र ट्रेड अफहरू प्रकट गर्दछ
• विवरण: कार्यक्षमता र विस्तारित प्रोटोकलहरूको विवरण। यो सेक्सन सम्बन्धित उप-सेक्सनहरू थपेर विभिन्न आवश्यकताहरूलाई अनुकूलन गर्न सक्दछ।

3. परीक्षण रणनीति: ब्लुटुथ योग्यता कार्यक्रम को भाग को रूप मा परीक्षण (वा परीक्षण गरीएको छैन) को प्रस्तावित कार्यक्षमता को वर्णन र कसरी कार्यक्षमता यो परीक्षण गर्न को लागी प्रस्तावित छ (जस्तै, तल्लो परीक्षक (हरू) वा माथिल्लो परीक्षक (हरू) मा अपेक्षाहरु, र यदि परीक्षण अनुरूपता वा अन्तरक्रियात्मक परीक्षण वा दुबै को संयोजन को रूप मा जिम्मेवार हुनेछ)। यो एक छुट्टै कागजात वा ०.५/DIPD विनिर्देश भित्र एक अलग खण्ड मा हुन सक्छ। परम्पराहरु एक परीक्षण रणनीति मा प्रयोग गर्न को लागी टेस्ट रणनीति र शब्दावली मा वर्णन गरीएको छview कागजात (TSTO) [5]।

यस एस मा कागजात को प्राथमिक दर्शकहरुtagई WG सदस्यहरु र BARB जो पुन हुनुहुन्छview वास्तु प्रस्तावहरु र आवश्यकता कवरेज, र BTI जो पुनःviewपरीक्षण रणनीति हो। धेरै जसो अवस्थामा, यस एस मा कागजातहरुtagई अन्तिम विनिर्देश मा समावेश को लागी योजना बनाईएको पाठ समावेश गर्न को लागी इरादा छैन।

BSTS पुन: हुनुपर्छview ब्लुटुथ मस्यौदा दिशानिर्देश [1] र WG लाई सम्बोधन गर्न को लागी मुद्दाहरुको पहिचान संग संगति को लागी सबै कागजातहरु। BARB पुन: हुनुपर्छview 0.5/DIPD विशिष्टता। एक विनिर्देश वृद्धि को लागी, BARB पनि पुन: हुनुपर्छview अनुच्छेद ३.३.२ मा वर्णित पिछडिएको अनुकूलता आवश्यकताहरु संग अनुपालन को लागी DIPD। BTI पुन: हुनुपर्छview परीक्षण रणनीति।

BARB या त अनुमोदन वा 0.5/DIPD यसको इन्जीनियरिंग निर्णय को आधार मा निर्दिष्टीकरण अस्वीकार गर्नुपर्छ। यदि BARB द्वारा अनुमोदित, 0.5/DIPD विनिर्देश ब्लुटुथ SIG मा उपलब्ध गराईनेछ webसबै एसोसिएट र प्रमोटर सदस्यहरु को लागी साइट र यसको उपलब्धता को अधिसूचना BSTS द्वारा जारी गरिनेछ। ०.५/डीआईपीडी एस माtagई, परीक्षण रणनीति को अनुमोदन आवश्यक छैन।
0.5/DIPD एसtagसीएसएस, जीएसएस, वा एमडीपी निर्दिष्टीकरण को बृद्धि को लागी आवश्यक छैन

०.५/डीआईपीडी एसtage निकास आवश्यकताहरु

0.5/DIPD एसtagई पूरा भयो र ०.0.7/FIPD एसtagई सुरु हुन्छ जब निम्न निकास आवश्यकताहरु पूरा हुन्छ:

• BSTS पुनः सम्पन्न भयोview0.5/DIPD विशिष्टता र परीक्षण रणनीति आईएनजी।
• BARB ०. / / DIPD विशिष्टता अनुमोदन गरेको छ।
• BTI ले यसको पुन: पूरा गरेको छview परीक्षण रणनीति को।
• BSTS ले अनुमोदित ०. / / DIPD विशिष्टता सबै एसोसिएट र प्रोमोटर सदस्यहरूको लागि उपलब्ध गराएको छ।

4.2 0.7/FIPD एसtage

०.0.7/FIPD एस को समयमाtagई, WG निम्न [8] मा प्रदान गरीएको सरकारी टेम्पलेट्स को उपयोग गरेर विकास हुनेछ:

1. नयाँ विशिष्टताको लागि, ०. 0.7 निर्दिष्टताको ड्राफ्ट, जसमा समावेश हुनुपर्दछ, कम्तिमा, निम्नमा जानकारी:

• नयाँ वा परिमार्जित प्रस्तावहरु, चयन मापदण्ड, र छनौट को औचित्य सहित BARB- अनुमोदित ०.५ पछि गरिएका सबै परिवर्तनहरुको विवरण। 0.5 एस मा आवश्यक को रूप मा परिवर्तन को एकै स्तर मा परिवर्तन को वर्णन गर्नु पर्छtage.
• FRD बाट सबै कार्यात्मक आवश्यकताहरू सम्बोधन गरियो।

२. विशिष्टता बृद्धिका लागि, एफआईपीडीको ड्राफ्ट, जसमा समावेश हुनुपर्दछ, कम्तिमा, निम्नका बारे जानकारी:

• नयाँ वा परिमार्जित प्रस्तावहरु, चयन मापदण्ड, र छनौट को औचित्य सहित BARB- अनुमोदित DIPD पछि गरिएका सबै परिवर्तनहरुको विवरण। परिवर्तन DIPD एस मा आवश्यक को रूप मा विस्तार को एकै स्तर मा वर्णन गरिनु पर्छtage.
• आवश्यक भएमा, थप विकसित क्षेत्रहरू जुन DIPD को बारेमा सेक्सन 4.1.१ मा वर्णन गरिएको थियो।
• सुधारको पूर्ण विवरण।
• एक अद्यावधिक वास्तु वर्णन।
• FRD बाट सबै कार्यात्मक आवश्यकताहरू सम्बोधन गरियो।

3. ०.0.7 / FIPD परीक्षण कागजातहरू, जसमा समावेश हुनुपर्दछ, कम्तिमा, निम्नका बारे जानकारी:

• एक परीक्षण सूट, TSTO []] मा वर्णन गरिए अनुसार परीक्षण उद्देश्यहरूको सूची समावेश गर्दछ।
• TSTO []] मा वर्णन गरिए अनुसार कार्यान्वयन सम्मेलन कथन (ICS)।

विशिष्टता बृद्धि लागि, परीक्षण सुइट र ICS अलग कागजातको रूपमा प्रदान गर्न सकिन्छ वा FIPD मा थप सेक्सनको रूपमा।

यस एस मा उत्पादन कागजात को प्राथमिक दर्शकहरुtagई WG सदस्यहरु र BARB जो पुन हुनुहुन्छview सुविधा वा सुधार को पूरा विवरण केहि पाठ सहित अन्तिम विनिर्देश मा समावेश को लागी योजना बनाईएको छ। BTI पुनः को लागी दर्शक होview परीक्षण कागजात को।

BSTS फेरि हुनेछview ०.0.7/FIPD विनिर्देशन र ब्लुटुथ मस्यौदा दिशानिर्देशहरु संग ब्लुटुथ SIG द्वारा स्थापित भाषा सम्मेलन सहित संगति को लागी परीक्षण कागजातहरु को नयाँ वा बदलिएको भागहरु। BARB फेरि हुनेछview 0.7/FIPD विशिष्टता।

BSTS WG लाई ०.0.7 / FIPD परीक्षण कागजातहरू TSTO [5] बमोजिम तयार गर्न मद्दत गर्दछ।

BTI पुन: हुनुपर्छview ०.0.7/FIPD परीक्षण कागजात। WG ०.0.7/FIPD विनिर्देशन BTI लाई एक सन्दर्भ को रूप मा प्रदान गर्नु पर्छ जब पुनview०.0.7/FIPD परीक्षण कागजात आईएनजी, जो BTI फेरि हुनेछview BTI विशिष्टता पुन अनुसारview प्रक्रिया चेकलिस्ट [6]।

BARB ले यसको पुन: पूरा गरे पछिview ०.0.7/FIPD विनिर्देश र BTI को यसको पुनः पूरा गरीएको छview ०.0.7/FIPD परीक्षण कागजात को, BSTS पुनः बनाउनेछviewएड ०.0.7/FIPD विशिष्टता सबै एसोसिएट र प्रमोटर सदस्यहरु को लागी उपलब्ध छ।

०.0.7/FIPD एसtagई सीएसएस, जीएसएस, वा एमडीपी विशिष्टताहरु को बृद्धि को लागी आवश्यक छैन।

०.0.7/एफआईपीडी एसtage निकास आवश्यकताहरु

०.0.7/FIPD एसtagई पूरा भयो र ०.0.9/सीआर एसtagई सुरु हुन्छ जब निम्न निकास आवश्यकताहरु पूरा हुन्छ:

• BSTS पुनः सम्पन्न भयोview0.7/FIPD विशिष्टता र परीक्षण कागजात आईएनजी।
• BARB पुनः सम्पन्न भयोview0.7/FIPD विशिष्टता आईएनजी।
• BTI पुनः सम्पन्न भयोview0.7/FIPD टेस्ट सुइट (परीक्षण उद्देश्य) र 0.7/FIPD ICS आईएनजी।
• BSTS ले पुनः बनाएको छviewएड ०.0.7/FIPD विशिष्टता सबै एसोसिएट र प्रमोटर सदस्यहरु को लागी उपलब्ध छ।

४.३ ०.4.3/सीआर एसtage

त्यहाँ दुई प्रकारका CR हरू छन्: एक एकीकृत सीआर, जुन परिवर्तन भएको ट्र्याक गरिएको कागजात हो जुन पूरै अपनाईएको स्पेसिफिकेसनको पछिल्लो संस्करण देखाउँदै सबै परिवर्तन देखाउँदछ, र एब्रेभिएटेड सीआर, जुन कागजात हो जुन केवल प्रभावित खण्डहरूलाई परिमार्जन गर्नका लागि निर्देशन प्रदान गर्दछ। विशिष्टता संस्करण जुन मा सीआर आधारित छ।

०.0.9/सीआर एस को समयमाtagई, WG निम्न [8] मा प्रदान गरीएको सरकारी टेम्पलेट्स को उपयोग गरेर विकास हुनेछ:

1. नयाँ स्पेसिफिकेसनको लागि, ०.0.9 स्पेसिफिकेसनको सामग्री पूर्ण मस्यौदा, जसमा न्यूनतम, निम्नमा जानकारी समावेश हुनुपर्दछ:

• BARB-re बाट गरिएका सबै परिवर्तनहरुको विवरणviewएड ०.0.7 स्पेसिफिकेशन (वा ०.0.5 स्पेसिफिकेशन पछि ०.0.7 स्पेसिफिकेशन माफी दिईएको थियो), नयाँ सहित
• संशोधित प्रस्तावहरु, चयन मापदण्ड, र छनौट को औचित्य। 0.5 एस मा आवश्यक को रूप मा परिवर्तन को एकै स्तर मा परिवर्तन को वर्णन गर्नु पर्छtagई र ४ एसtage.

२. विशिष्टता बृद्धिका लागि:

• कि त एक एकीकृत सीआर, जो समावेश गर्नुपर्छ, कम्तिमा, निम्न मा जानकारी:
• BARB-re बाट गरिएका सबै परिवर्तनहरुको विवरणviewएड FIPD (वा DIPD पछि यदि FIPD माफ गरिएको छ) नयाँ वा परिमार्जित प्रस्तावहरु, चयन मापदण्ड, र छनौट को औचित्य सहित। परिवर्तन DIPD एस मा आवश्यक को रूप मा विस्तार को एकै स्तर मा वर्णन गरिनु पर्छtagई र FIPD एसtage.
• सबै परिवर्तनहरू परिवर्तन-ट्र्याकिंग प्रयोग गरी पहिले-अपनाईएको विशिष्टताको लागि प्रस्ताव गरियो।
• सबै अनुमोदित टेक्निकल इर्राटा (एक इरातम संख्याको साथ प्रत्येक इरातम सन्दर्भ सहित), परिवर्तन ट्र्याकि using प्रयोग गरी देखाइयो, जुन अझै पूर्व-अपनाईएको विशिष्ट संस्करणमा समावेश गरीएको छैन, र त्यो प्रभाव पाठ जुन विनिर्देशन बृद्धिसँग सम्बन्धित छ; वा त्यो अन्यथा IOP परीक्षण प्रभाव।

Or. वा एक संक्षेप सीआर, जसमा समावेश हुनुपर्दछ, कम्तिमा, निम्न बारे जानकारी:

• BARB-re बाट गरिएका सबै परिवर्तनहरुको विवरणviewएड FIPD (वा DIPD पछि यदि FIPD माफ गरिएको छ) नयाँ वा परिमार्जित प्रस्तावहरु, चयन मापदण्ड, र छनौट को औचित्य सहित। परिवर्तन DIPD एस मा आवश्यक को रूप मा विस्तार को एकै स्तर मा वर्णन गरिनु पर्छtagई र FIPD एसtage.
• सबै परिवर्तन प्रस्तावित प्रत्येक प्रभावित खण्ड र विशिष्टताको अनुच्छेद जुन सीआरले परिवर्तन प्रस्ताव गर्दछ।
• सबै अनुमोदित टेक्निकल इर्राटा (एक इरातम संख्याको साथ सन्दर्भमा प्रत्येक इरातमको साथ) मार्कअप प्रयोग गरी देखाइएको छ, जुन अझै पूर्व-अपनाईएको विशिष्टता संस्करणमा समावेश गरिएको छैन, र त्यो प्रभाव पाठ जुन विनिर्देशन बृद्धिसँग सम्बन्धित छ; वा त्यो अन्यथा IOP परीक्षण प्रभाव।

A. एक सीएसएस सीआर (यदि नयाँ प्रविष्टिहरू निर्दिष्ट द्वारा आवश्यक छ), जुन विनिर्देशको एब्रेभिएटेड सीआरमा सम्मिलित हुन सक्छ।
A. एक GSS सीआर (यदि नयाँ प्रविष्टिहरू निर्दिष्ट द्वारा आवश्यक छ), जुन विनिर्देशको एब्रेभिएटेड सीआरमा सम्मिलित हुन सक्छ।
An. एक MDP सीआर (यदि नयाँ प्रविष्टिहरू निर्दिष्ट द्वारा आवश्यक छ), जुन विनिर्देशको एब्रेभिएटेड सीआरमा सम्मिलित हुन सक्छ।
7..० / CR सीआर कागजातहरू, जसमा कम्तिमा पनि समावेश गरिएको हुनुपर्दछ, []] उपलब्ध गराईएको आधिकारिक टेम्पलेटको प्रयोग गरेर निम्नमा जानकारी।

• ०.0.9 / सीआर टेस्ट सुइट, जसमा सामग्री-पूर्ण परीक्षण केसहरू र सम्बन्धित परीक्षण केस म्यापि Table तालिका (TCMT) समावेश हुन्छ, TSTO []] मा वर्णन गरिए अनुसार।
• ०.0.9 / सीआर आईसीएस, टीएसटीओ []] मा वर्णन गरिए अनुसार।
• यदि परीक्षण कन्फिगर गर्न को लागी कार्यान्वयन अन्तर्गत परीक्षण (IUT) को लागी विशिष्ट मानदण्डहरु आवश्यक छ, ०.0.9 / सीआर कार्यान्वयन eXtra सूचना परीक्षणको लागि (IXIT)।
• ०.0.9 / सीआर परीक्षण केस सन्दर्भ सूची (TCRL) (कोर विशिष्टता अपडेटहरूको लागि वैकल्पिक)।

A. एक परीक्षण कभरेज विश्लेषण कुन विनिर्देशन आवश्यकताहरू कि त जाँच गरीन्छ वा ०.8 / सीआर टेस्ट सुइट भित्र परीक्षण गरिएको छैन भनेर दर्साउँछ (विशिष्टीकरण बृद्धिका लागि, परीक्षण कभरेज विश्लेषण मात्र भर्खर नयाँ जोडिएको र प्रभावित कार्यक्षमता समावेश गर्न आवश्यक छ, र गैर-प्रभावित क्षेत्रहरूको क्षेत्र होईन। मूल विशिष्टता)।
An। IOP परीक्षण योजना।

विशिष्टता बृद्धि लागि, परीक्षण सुइट, ICS, र IXIT या त अलग कागजातको रूपमा वा एब्रेभिएटेड सीआरमा अतिरिक्त सेक्सनको रूपमा प्रदान गर्न सकिन्छ।

धेरै जसो अवस्थाहरूमा, एकीकृत वा एब्रेभिएटेड सीआर विनिर्देशको अघिल्लो-अपनाईएको संस्करणमा आधारित हुनुपर्दछ, तर यो पछिल्लो मध्यवर्ती ड्राफ्टमा पनि आधारित हुन सक्छ। पछिल्लो मध्यवर्ती ड्राफ्ट विशिष्टता संस्करण नम्बर कागजातको संस्करणसँग सम्बद्ध संस्करण नम्बर हुनुपर्दछ जुन स्थिर छ र त्यो समयको साथ परिवर्तन हुँदैन। अन्यथा, अतिरिक्त पहिचान जानकारी (जस्तै कागजात मिति र a URL स्थायी स्थानमा) निर्दिष्ट गर्न आवश्यक छ "बेसलाइन" संस्करण। यदि एक मध्यवर्ती ड्राफ्ट प्रयोग गरिएको छ भने, कुनै परिवर्तन परिवर्तन सीआर सम्बन्धित छैन सीआर परिमार्जन गरिएको छ प्रदान गरिएको सेक्सनमा समावेश हुनुपर्दछ, तर मार्कअप प्रयोग गरेर देखाउन आवश्यक छैन। यदि मध्यवर्ती ड्राफ्टको प्रासंगिक अंशहरू पछि अद्यावधिक भएमा, मध्यवर्ती ड्राफ्टमा अपडेटहरू प्रतिबिम्बित गर्न सीआर अपडेट हुन आवश्यक छ।

आदर्श रूपमा, एब्रेभिएटेड सीआर सामग्री प्रमाणीकरण चरणको अघि क्रमशः पूर्ण विशिष्टता र पूर्ण परीक्षण कागजातहरूको मस्यौदामा एकीकृत हुन्छ, तर तिनीहरू प्रमाणीकरण चरणको सुरूमा एकीकृत हुन सक्दछन्। यदि बहु सुविधाहरू एक विशिष्टताको लागि विकसित भइरहेको छ भने (उदाहरणका लागि, कोर विशिष्टता), यो IOP परीक्षण पूरा भएपछि एकल ड्राफ्टमा सुविधाहरू एकीकृत गर्न योग्य हुन सक्छ।

BSTS फेरि हुनेछview ०.0.9/सीआर विनिर्देशन र ब्लुटुथ मस्यौदा दिशानिर्देश संग संगति को लागी कागजात परीक्षण। त्यसपछि BARB फेरि हुनेछview ०.0.9/सीआर विनिर्देशन पछि आईओपी परीक्षण योजना (धारा ४.३.१ मा वर्णन गरिए अनुसार) पछि। एक पटक ०.4.3.1/सीआर विनिर्देश WG द्वारा पुन: को लागी BARB लाई पेश गरीन्छview, BSTS यो सबै सदस्यहरु को लागी पुन: पहुँचयोग्य बनाउनेछview र यसको उपलब्धता को सबै सदस्यहरुलाई सूचित गर्नुहोस्। यस बिन्दु बाट अगाडि विनिर्देशन विकास प्रक्रिया मा, BSTS BARB मा पेश स्पेसिफिकेशन को ड्राफ्ट सबै सदस्यहरु लाई पठाइएको आवधिक नोटिस संग सबै सदस्यहरुलाई उपलब्ध गराउनेछ।

एक विशिष्टता बृद्धिका लागि, WG BoD लाई सिफारिस गर्दछ कि विनिर्देशको अघिल्लो संस्करणहरू अस्वीकृत वा फिर्ता लिनुपर्दछ, सिफारिश (हरू) का टेक्निकल कारणहरू सहित।

BARB फेरि हुनेछview 0.9/सीआर विनिर्देशन को FRD मा दिइएको आवश्यकताहरु संग अनुपालन को WG को विश्लेषण, कुनै पनि सम्भावित सुरक्षा मुद्दाहरु, कुनै नियामक मुद्दाहरु, ब्लुटुथ वास्तुकला संग अनुरूप, र, एक विशिष्टता वृद्धि को लागी, अनुच्छेद ३.३ मा वर्णित पिछडिएको अनुकूलता आवश्यकताहरु संग अनुपालन। २। यदि BARB ले कुनै सम्भावित सुरक्षा मुद्दाहरुको पहिचान गर्दछ, BARB ले BSTS लाई पुनः को लागी सूचित गर्दछview र सुरक्षा विशेषज्ञ समूह संग समन्वय; र यदि BARB ले कुनै नियामक निहितार्थ को पहिचान गर्दछ, BARB ले BSTS लाई पुनः सूचित गर्दछview र नियामक समिति र ब्लुटुथ SIG को कानूनी सल्लाह संग समन्वय। BARB लाई या त अनुमोदन वा अस्वीकार गर्नु पर्छ 0.9/CR स्पेसिफिकेशन यसको इन्जीनियरिंग निर्णय र यस अनुच्छेद मा वर्णित कारकहरुको विचार को आधार मा।

BTI फेरि हुनेछview ०.0.9/सीआर परीक्षण कागजात खाता मा परीक्षण कवरेज विश्लेषण लिँदै। BTI या त अनुमोदन वा ०.0.9/सीआर परीक्षण कागजात अस्वीकार गर्नुपर्छ।

BARB ०.0.9/CR स्पेसिफिकेशन स्वीकृत गरे पछि, WG IOP परीक्षण योजना BARB लाई पुन: पेश गर्दछview.

BARB- अनुमोदित ०.0.9 / सीआर विशिष्टता बोप समक्ष प्रस्तुत हुन्छ IOP परीक्षणको सुरूवातलाई अनुमोदन गर्न र ०.0.9 / सीआर विशिष्ट विवरण सबै सदस्यहरुलाई प्रकाशित गर्न।

सम्भावित कानूनी मुद्दाहरु लाई हाइलाइट गर्न को लागी, WGs एक स्पेसिफिकेशन पुनः अनुरोध गर्न सक्छview ब्लुटुथ SIG को कानूनी सल्लाह द्वारा (कानूनी पुनview) अनिवार्य कानूनी पुन: पहिलेview दत्तक ग्रहण/अनुमोदन चरण को दौरान लिन्छ। जे होस्, विनिर्देश संवर्द्धन को लागी, कानूनी पुनview एक एकीकृत सीआर (एक संक्षिप्त सीआर को विपरीत) मा गरिनु पर्दछ र यो सम्भव भएसम्म अग्रिम precheduled गर्नुपर्छ ताकि संसाधनहरु उपलब्ध छन्।

IOP परीक्षण योजना

WG एक लिखित IOP परीक्षण योजना को विकास गर्दछ कि IOP परीक्षण घटनाहरु मा मान्यता चरण को दौरान उपयोग को लागी तल परिभाषित सबै आवश्यकताहरु लाई पूरा गर्नु पर्छ। WGs को लागी IOP परीक्षण योजना BARB लाई पुन: पेश गर्नु पर्छview IOP परीक्षण घटना (हरू) सुरु हुनु भन्दा पहिले। साधारण स्पेसिफिकेशन संवर्द्धन को लागी (विशेष गरी ती जसलाई टेस्ट सुइट मा कुनै पनी परीक्षण मामलाहरु परिमार्जन वा थप्न को आवश्यकता छैन), IOP परीक्षण को आवश्यकता नहुन सक्छ, र WG ले BOPB लाई IOP परीक्षण बाट माफी को लागी अनुरोध पेस गर्न को लागी परिभाषित प्रक्रिया को उपयोग गरी पेश गर्न सक्छ। खण्ड ४.४ मा।

IOP परीक्षण योजनामा ​​समावेश हुनुपर्दछ:

1. केसहरू सबै नयाँ अनिवार्य, वैकल्पिक, र सर्त सुविधाहरू प्रमाणित गर्न
2. कम्तिमा प्रत्येक ओप कोडका लागि एक परीक्षण केस
3. प्रत्येक प्यारामिटरको लागि कम्तिमा एउटा परीक्षण केस
4. प्रत्येक प्याकेट प्रकारका लागि कम्तिमा एउटा परीक्षण केस
5. विशिष्टता अभिवृद्धिहरूका लागि पछाडि अनुकूलता परीक्षण केसहरू जसले गर्दा धारा 3.3.2.२ मा सूचीबद्ध आवश्यकताहरू सबै विस्तारित कार्यक्षमताका लागि पूरा गरिन्छ (सेक्सन 4.3.1.1..XNUMX.१.१ पनि हेर्नुहोस्)।
6. परीक्षण केसहरू जहाँ IUT परिभाषित दायरा बाहिर मान वा व्यवहारिक पक्षलाई अवैध वा अप्रत्याशित मानिन्छ (अवैध व्यवहार परीक्षण केस)। नोट गर्नुहोस् कि यस्तो आशा छ कि परीक्षक जस्तै PTS वा अन्य परीक्षण उपकरण कुनै अवैध व्यवहारको प्रारम्भिक हुनेछ।
7. कुनै अस्थायी तोकिने नम्बरहरू (BSTS सँग समन्वयमा चयन गरिएको आगामी IOP परीक्षण घटनाहरूमा ओभरल्याप हुन नदिन) IOP परीक्षण घटनामा प्रयोग गर्न, सेक्सन 4.3.1.2.१.२ मा वर्णन गरिए अनुसार।
8. धारा 4.3.1.3.१. in मा वर्णन गरिएको कभरेज आवश्यकताहरूलाई ध्यानमा राख्दै, प्रत्येक परीक्षण केस पार गर्न आवश्यक स्वतन्त्र कार्यान्वयनको आवश्यक संख्याको पहिचान।
9. WUG विश्वास गर्दछ कि परीक्षण सुइटमा कुनै पनि परीक्षण केसहरूको पहिचान बाहेक र तिनीहरूको बहिष्करणको औचित्य हो। यसले सामान्य रूपमा समावेश गर्दछ: भविष्य प्रमाणिकरण परीक्षण केसहरू (उदाहरणका लागि साधारण परीक्षणहरू ताकि सम्भव भविष्यका थपाहरू समायोजन गर्न सकिन्छ, जस्तै अतिरिक्त विशेषताहरू, विस्तार गर्ने विशेषताहरू, वा भविष्य प्रयोगको लागि आरक्षित प्रयोग (आरएफयू) बिट्स वा फिल्डहरू)
   • परीक्षण केसहरू जुन अन्य समावेश परीक्षणहरूको सबसेट हुन्
   • जेनेरिक टेस्ट केसहरू वास्तवमै टेस्टमा मिल्दोजुल्दो हुन्छ जुन थुप्रै अन्य विशिष्टताको लागि दौडिन्छ (उदाहरणका लागि, सामान्य त्रुटि कोड ट्रिगर गर्दै)
   • टेस्ट केसहरू समान परीक्षण उद्देश्यका साथ परीक्षण केसहरू जुन अर्को यातायातमा चल्दछन् (उदाहरणका लागि, BR / EDR परीक्षण केस जुन एलईई परीक्षण केससँग मिल्दोजुल्दो छ)।
   • मजबुतपन वा कार्यान्वयनको तनाव परीक्षण

आईओपी परीक्षण योजनामा ​​आईओपी परीक्षणको लागि अद्वितीय हुन्छ जस्तै अन्त-देखि-अन्त परीक्षण केसहरू जुन अधिक जटिल दृश्यहरू सँगसँगै खडा हुन्छ जुन विशिष्ट प्रयोगकर्ता परिदृश्यसँग मिल्दोजुल्दो हुन सक्छ।

यद्यपि आईओपी परीक्षण योजनाको BARB स्वीकृति आवश्यक पर्दैन (IOP परीक्षण योजना प्रत्येक IOP परीक्षण घटनासँग परिमार्जन र सुधार हुन जारी रहनेछ भन्ने बुझाइमा), IOP परीक्षण रिपोर्टको BARB स्वीकृति आवश्यक छ (सेक्सन 5.1.1.१.१ हेर्नुहोस्) । यदि एक IOP परीक्षण योजनाले सेक्शन 4.3.1.१ मा परिभाषित सबै आवश्यकताहरुलाई पूरा गर्दैन भने, WG ले कुनै पनि ज्ञात भेरिएन्सन्सको सारांश र IAR परीक्षण घटना (हरू) सुरु हुनु अघि BARB लाई प्रत्येक भिन्नताका लागि तर्क प्रस्तुत गर्नुपर्नेछ।

IOP परीक्षण योजना र परीक्षण केसहरू मुख्य रूपमा सम्बन्धित विशिष्टता परीक्षण कागजातहरूको सामग्रीमा आधारित हुनुपर्दछ।

आईओपी परीक्षण घटनाहरू सक्षम बनाउनका लागि, डब्ल्यूजीसँग आईओपी परीक्षण योजना हुनुपर्दछ र सबै सम्बन्धित परीक्षण केसहरू पूर्ण आइपोजीभर्ताको लागि उपलब्ध हुनुपर्दछ र कम्तिमा पहिलो आईओपी टेस्ट घटना अघि कम्तीमा एक महिना अघि लागूकर्ताहरूलाई उपलब्ध हुन्छ।

पछाडि अनुकूलता परीक्षणको लागि योजना गर्दै
विनिर्देश संवर्द्धन को लागी, पिछडिएको अनुकूलता को IOP परीक्षण स्पेसिफिकेशन को सबै सक्रिय र बहिष्कृत संस्करणहरु को बिरूद्ध प्रमाणिकरण लाई विचार गर्नु पर्छ किनकि ती विशिष्टताहरु र कार्यक्षमता सामान्यतया ब्लुटुथ उत्पादनहरु मा पाईन्छ एक धेरै लामो आयु (जस्तै, वाहन) हुन सक्छ। WG पिछडिएको अनुकूलता परीक्षण को उचित स्तर को विश्लेषण जरूरी छ (यदि कुनै हो) सहित कुन संस्करण को परीक्षण र परीक्षण गर्न को लागी, र BARB लाई यो विश्लेषण प्रदान गर्नुहोस्। BARB पुन: हुनुपर्छview विश्लेषण र WG को लागी IOP परीक्षण योजना मा समावेश गर्न को लागी परिवर्तन (यदि कुनै छ) को सिफारिश।

पछाडि अनुकूलता परीक्षणमा भाग लिने सदस्यहरूलाई विगत उपकरणहरू ल्याउन प्रोत्साहित गरिन्छ जुन अघिल्लो विनिर्देशन संस्करण (हरू) को बिरूद्ध योग्य छन्। WG ले आईओपी परीक्षण रिपोर्टमा कुनै पछाडि अनुकूलता विफलता रिपोर्ट गर्नु पर्छ। सदस्य कम्पनीहरूलाई IOP टेस्ट घटनाको स्थान भन्दा बाहिर आफ्नै प्रयोगशालाहरूमा पछाडि संगतता परीक्षण गर्न र WG लाई कुनै विशिष्टता-सम्बन्धित मुद्दाहरूको रिपोर्ट गर्न पनि प्रोत्साहन गरिन्छ।

IOP परीक्षणमा प्रयोग गरिएको अस्थायी असाइन नम्बरहरू
BSTS र BARB लाई तोकिएको संख्याहरूको अस्थायी असाइनमेन्ट समन्वय गर्न परामर्श लिनु पर्छ जुन IOP परीक्षण कार्यक्रममा प्रयोग गरिने छ त्यसैले अन्य कुनै विनिर्देशहरूसँग कुनै अधिव्यापन वा झगडा हुँदैन। यी अस्थायी मानहरू IOP परीक्षण योजनामा ​​समावेश हुनुपर्दछ र कुनै दत्तक विनिर्देशहरू द्वारा प्रयोगको लागि तोकिनु हुँदैन।

आईओपी परीक्षणको लागि जहाँ एक वा बढी नयाँ १ 16-बिट यूआईयूडी मानहरू प्रस्ताव गरिएको छ, ०x0F7 देखि ०x00FFF को दायरा भित्रका मानहरू IOP परीक्षणको लागि आरक्षित छन्।

आईओपी परीक्षणको लागि जहाँ एक वा बढी नयाँ फिक्स्ड प्रोटोकल सेवा मल्टिप्लेक्सर (पीएसएम) मानहरू प्रस्ताव गरिएको छ, कोर स्पेसिफिकेसनमा निर्दिष्ट गरे अनुसार ०x0 देखि ०x0000F को वैध दायराको अन्त्यबाट सुरू हुने मानहरू प्रयोग हुनेछ।

कभरेज आवश्यकताहरू
WG ले BARB लाई प्रमाण दिनुपर्दछ कि स्वतन्त्र कार्यान्वयनको आवश्यक संख्या (जसलाई अनुसरण गर्ने खण्डहरूमा वर्णन गरिएको छ) प्रत्येक परीक्षण केसमा पारित भयो। स्वतन्त्र कार्यान्वयनको आवश्यक संख्यामा अपवादको लागि कुनै WG अनुरोध आईओपी परीक्षण योजनामा ​​स be्केत गरिनु पर्छ जुन BARB लाई पेश गरिएको छ।

कार्यान्वयनहरू एक अर्कामा स्वतन्त्र मानिन्छ जबसम्म प्रमाणीकरणसँग सम्बन्धित सबै भागहरू स्वतन्त्र रूपमा विकसित भएका हुन्छन्, अर्थात्, विभिन्न टोलीहरू (जुन आवश्यक छैन विभिन्न कम्पनीबाट आउँदैन)। BSTS ले प्रोटोटाइपलाई एक अर्काबाट स्वतन्त्र मान्न सकिन्छ कि भनेर जाँच्न सहयोग गर्न सक्छ र कार्यान्वयन विवरणको गोपनीयताको संरक्षण गर्न।

नोट गर्नुहोस् कि PTS सहित परीक्षण उपकरणहरू स्वतन्त्र कार्यान्वयनको रूपमा मानिदैन।

कोर विशिष्टता IOP कभरेज आवश्यकताहरू
एक कोर विशिष्टता सुविधा सामान्यतया एक वा बढी भूमिका परिभाषित गर्दछ जहाँ प्रत्येक भूमिका एक वा बढी अन्य भूमिकाहरू वा सम्भवतः आफैंमा हस्तक्षेप गर्न डिजाइन गरिएको हो।

प्रत्येक जोडी भूमिकाको लागि जुन एक अर्कासँग अन्तर्क्रियाको लागि डिजाइन गरिएको हो, पूरक भूमिकाको तीन स्वतन्त्र कार्यान्वयनको साथ अन्तर्क्रिया गर्न प्रत्येक भूमिकाको कम्तिमा तीन स्वतन्त्र कार्यान्वयन प्रदर्शन गरिनु पर्दछ।

प्रत्येक भूमिकाको लागि जुन उही भूमिकामा अर्को उपकरणसँग हस्तक्षेप गर्न सक्दछ, त्यस भूमिकाको कम्तिमा तीन स्वतन्त्र कार्यान्वयनले उनीहरूले त्यो भूमिकामा एक अर्कासँग कुराकानी गर्न सक्ने कुरा देखाउनुपर्दछ।

सेवा विशिष्टता IOP कभरेज आवश्यकताहरू
कम्तिमा तीन स्वतन्त्र सेवा कार्यान्वयनले उनीहरूले कम्तिमा एउटा ग्राहक कार्यान्वयनमा हस्तक्षेप गर्दछ भनेर प्रदर्शन गर्नुपर्दछ, जुन PTS हुन सक्छ।

प्रोfile र प्रोटोकल विनिर्देश IOP कवरेज आवश्यकताहरु
प्रोfile र प्रोटोकल विशिष्टताहरु सामान्यतया एक वा धेरै भूमिकाहरु लाई परिभाषित गर्दछ जहाँ प्रत्येक भूमिका एक वा धेरै अन्य भूमिकाहरु, वा सम्भवतः आफै संग अन्तरक्रिया को लागी डिजाइन गरीएको हो।

प्रत्येक जोडी भूमिकाको लागि जुन एक अर्कासँग अन्तर्क्रियाको लागि डिजाइन गरिएको हो, प्रत्येक भूमिकाको कम्तिमा दुई स्वतन्त्र कार्यान्वयनले उनीहरूले पूरक भूमिकाको दुई स्वतन्त्र कार्यान्वयनमा हस्तक्षेप गर्दछन् भन्ने कुरा प्रदर्शन गर्नुपर्दछ।

उस्तै भूमिकामा अर्को उपकरणसँग हस्तक्षेप गर्न सक्ने प्रत्येक भूमिकाको लागि, त्यस भूमिकाको कम्तिमा तीन स्वतन्त्र कार्यान्वयनले उनीहरूले त्यो भूमिकामा एक अर्कासँग कुराकानी गरेको देखाउनुपर्दछ।

मोडेल विशिष्टता IOP कभरेज आवश्यकताहरू
कम्तिमा तीन स्वतन्त्र सर्भर मोडेल वा नियन्त्रण मोडेल कार्यान्वयनले उनीहरूले कम्तिमा एक ग्राहक कार्यान्वयन (जुन PTS हुन सक्छ) मा हस्तक्षेप गर्छन् भनेर प्रदर्शन गर्नुपर्दछ, र कम्तिमा एउटा क्लाइन्ट मोडल कार्यान्वयनले प्रदर्शन गर्नुपर्दछ कि यसले कम्तिमा एक सर्भर मोडेल कार्यान्वयन र PTS सँग अतिक्रमण गर्दछ।

विशिष्ट संस्करण संख्या

०.0.9/सीआर एस को समयमाtagई, WG एक अनुमोदन तयार गर्न को लागी संस्करण संख्या को बारे मा BoD लाई पेश गर्न को लागी स्पेसिफिकेशन को लागी लागू हुन्छ जब अपनाईन्छ।

विनिर्देशको संस्करण दुई प्रकारमा पर्दछ: पूर्ण रिलिज संस्करणहरू, जसमा नयाँ वा अद्यावधिक सुविधाहरू समावेश छन्, र मर्मत रिलीज संस्करणहरू ("डट-जेड संस्करण" पनि भनिन्छ), जसले प्राविधिक र सम्पादकीय इर्राटा एकीकृत गर्दछ, तर नयाँ वा अद्यावधिक समावेश गर्दैन। विशेषताहरु। पूर्ण रिलिज संस्करणहरु का XY को रूप मा दुई भाग संख्याहरु छ, जस्तै २.१ वा .2.1.०, जबकि रखरखाव रिलिज संस्करण को XYZ को रूप मा तीन-भाग नम्बरहरु, जस्तै २.१.२ छ। Z को मान ० हुन सक्दैन।

कुनै पनि दुई संस्करणका लागि, एउटालाई "उच्च संस्करण" को रूपमा संदर्भ गरिएको छ र अर्को "कम संस्करण" हो। यो निम्न नियम अनुसार निर्धारित गरिन्छ:

• यदि एक्स कम्पोनेन्टहरू फरक छन् भने, उच्च एक्स मूल्यको साथ एक "उच्च संस्करण" हो।
• यदि एक्स कम्पोनेन्टहरू समान छन्, तर वाई कम्पोनेन्टहरू भिन्न छन्, उच्च वाई मानको साथ एक "उच्च संस्करण" हो।
• यदि XY कम्पोनेन्टहरू उस्तै छन्, तर Z कम्पोनेन्टहरू फरक छन्, उच्च Z मानको साथ एक "उच्च संस्करण" हो। एक दुई-भाग नम्बर XY, यस उद्देश्यको लागि, तीन-भाग नम्बर XY0 को रूपमा व्यवहार गरिन्छ।

पूर्वका लागिample, निम्न संस्करण संख्या निम्नतम संस्करण बाट उच्चतम संस्करण को क्रम मा हुनेछ: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2। सीएसएस को लागी, प्रत्येक अपडेट बृद्धि मात्र संस्करण संख्या को X घटक।

BoD अनुमोदन शर्तहरू
विशिष्टता विकास चरणको अन्त्यमा निम्न आवश्यकताहरू पूरा गरिनुपर्दछ ०.0.9 / सीआर निर्दिष्ट गर्न BoD लाई अनुमोदनको लागि पेश गर्नु अघि:

• WG ले परीक्षण कभरेज विश्लेषण पूरा गरेको छ।
• BSTS पुनः सम्पन्न भयोview०.0.9/सीआर विशिष्टता र परीक्षण कागजात आईएनजी।
• BARB ०.0.9 / CR विशिष्टतालाई अनुमोदन गरेको छ।
• BARB सीएसएस सीआर अनुमोदन गरेको छ (यदि नयाँ प्रविष्टिहरू निर्दिष्ट द्वारा आवश्यक छ) जुन विनिर्देशको एक एब्रेभिएटेड सीआरमा सम्मिलित हुन सक्छ।
• BARB ले GSS CR र MDP CR लाई अनुमोदन गरेको छ (यदि नयाँ प्रविष्टिहरू निर्दिष्ट द्वारा आवश्यक भएमा)।
• BTI ले 0.9/CR टेस्ट सुइट, ICS, र TCRL लाई एक IXIT सँगै अनुमोदन गरेको छ (बशर्ते कि IXIT टेस्ट सुइट मा परीक्षण गर्न को लागी आवश्यक छ)। TCRL यो s मा वैकल्पिक छtagकोर विशिष्टता को लागी अपडेट को लागी।
• WG ले IOP परीक्षण योजना BARB लाई पुन: पेश गरेको छview (यदि परीक्षण BARB द्वारा माफ गरिएको छैन)।

BoD लाई प्रस्तुत कागजातहरु BARB- अनुमोदित ०. CR / CR विशिष्टता, र BoD लाई एक प्रस्तुतीकरण समावेश गर्नु पर्छ:

• कुनै ज्ञात अनुरोधहरू IOP परीक्षण वा कुनै पनि आवश्यकताहरू सेक्सन 4.3.1.१ मा परिभाषित गर्न माफ गर्न
• ट्रान्सपोर्टहरूको सूची जुन विनिर्देशनले समर्थन गर्दछ (जस्तै, BR / EDR, LE। आदि)
• एक विशिष्टता बृद्धिका लागि, WG द्वारा अनुरोध गरिएको पछाडि संगतता आवश्यकताहरू (सेक्सन 3.3.2.२ मा वर्णन गरिएको) बाट कुनै छुटहरू।
• एक विशिष्टता बृद्धि लागि, WG बाट एक सिफारिश संस्करण संख्या को लागी अपनाईएको विनिर्देश को लागी लागू गर्न
• एक विशिष्टीकरण बृद्धिका लागि, डब्ल्यूजीको अन्तिम जीवन (हरू) को लागी अपनाईएको विनिर्देशको अघिल्लो संस्करण (हरू) को लागि कुनै प्राविधिक कारणहरू सहित विनिर्देशको कुनै पनि अघिल्लो संस्करणको ह्रास वा फिर्ता लिने सिफारिश गरिएको छैन, र औचित्य हो। सिफारिस को लागी
• BARB वा BTI सदस्यहरु बाट कुनै अनसुलझे गम्भीर चिन्ताहरु (उदाहरण को लागी, अनुमोदन को समयमा कुनै मत नहुने कारणहरु, पुन: उत्पन्न हुने चिन्ताहरुview परीक्षण कागजात, वा चिन्ता कि ०.0.9/सीआर विनिर्देश FRD वा चार्टर को दायरा बाहिर छ)
• प्रो को तयारी स्थितिfile ट्यूनिंग सुइट (PTS) वा अन्य आवश्यक उपकरणहरु BSTS द्वारा तयार गरीएको छ कि गोद संग सम्बन्धित

बीओडीले ०.0.9 / सीआर परीक्षण कागजातहरूलाई अनुमोदन गर्नु अघि र डब्ल्यूजीले IOP परीक्षण योजनाको धारा 2..0.9 मा परिभाषित आवश्यकताहरू पूरा गर्दछ भनेर पुष्टि गर्नु अघि BOLW [२] द्वारा आवश्यक अनुसार IOP परीक्षणको लागि ०.4.3.1 / सीआर विशिष्टता अनुमोदन गर्न छनौट गर्न सक्दछ। १ बीओडीले ०. / / सीआर परीक्षण कागजातहरूको BTI स्वीकृतिमा IOP परीक्षणको लागि ०.0.9 / सीआर विनिर्देशको स्वीकृति सर्त गर्न सक्दछ।

०.0.9/सीआर एसtage निकास आवश्यकताहरु
०.0.9/सीआर एसtagई पूरा भयो र प्रमाणीकरण चरण शुरू हुन्छ जब BoD IOP परीक्षण को शुरू अनुमोदन गर्दछ।

4.4 विशिष्ट विकास प्रक्रिया छूट

एक WG ले निम्न प्रक्रिया चरणहरू मध्ये एक वा बढी रद्द गर्न अनुरोध गर्न सक्दछ:

• 0.5/DIPD एसtage
• ०.0.7/FIPD एसtage
• IOP प्रमाणीकरण चरण भित्र परीक्षण

माफी अनुरोध गर्न को लागी, WG ब्लुटुथ SIG [8] द्वारा प्रदान गरिएको प्रक्रिया माफी टेम्प्लेट को उपयोग गर्नु पर्छ र प्रत्येक समिति (जस्तै, BARB वा BTI) लाई माफी अनुरोध पेस गर्नु पर्छ जुन पुन: आवश्यक छ।view वा एस मा मस्यौदा विनिर्देशन वा सम्बन्धित परीक्षण कागजात अनुमोदनtagडब्ल्यूजी माफी को प्रस्ताव छ कि, र ती समितिहरु मध्ये प्रत्येक माफी अनुरोध लाई अनुमोदन गर्नु पर्छ।

एक छूट अनुरोध मा निम्न समावेश गर्नु पर्छ:

• एस को पहिचानtagई (हरू) कि WG माफ गर्न चाहन्छ
• एक औचित्य किन एसtagई (हरू) माफी दिनु पर्छ
• प्रत्येक समिति को एक पहिचान (यानी, BTI र/वा BARB) कि पुन: आवश्यक छview र माफी अनुरोध स्वीकृत

माफी मा विचार समितिले WG को एक प्रतिनिधि माफी अनुरोध मा निर्णय गर्नु अघि SMPD प्रक्रिया माफी औचित्यको लागि एक प्रस्तुतीकरण आवश्यकता हुन सक्छ।

यदि एक माफी को लागी बहुविध चरणहरु माफी गर्न को लागी अनुरोध छ र छूट को एक हिस्सा अस्वीकृत गरीएको छ र समिति अनुमोदन छ भने समिति को प्रतिक्रिया माफी माग्नु पर्छ कुन चरणहरु माफी अनुरोध मा अनुमोदन गरीएको थियो र कुन अस्वीकार गरियो। यदि एक माफी अनुरोध अस्वीकृत गरियो भने, अस्वीकृति सूचनामा अस्वीकृतिका कारणहरू समावेश गर्न आवश्यक छ।

Val. मान्यकरण चरण

प्रमाणीकरण चरण को बखत, WG 0.9/CR विनिर्देश मा IOP परीक्षण प्रदर्शन BARB को लागी IOP परीक्षण रिपोर्ट वितरण गर्ने उद्देश्य संगview र अनुमोदन। जहिले सम्भव हुन्छ, विशिष्टता बृद्धि को IOP परीक्षण एकीकृत मस्यौदा विनिर्देश को विरुद्ध आयोजित गरिनु पर्छ। यसको अतिरिक्त, सदस्य पुनview, Bylaws [2] द्वारा आवश्यक अनुसार, यस चरण को दौरान शुरू हुन्छ।

यदि विनिर्देशन (वा विस्तार) लाई IOP परीक्षणको आवश्यकता पर्दैन भने, I4.4 प्रमाणीकरण चरण भित्र परीक्षण Section.XNUMX मा वर्णन गरिएको प्रक्रिया प्रयोग गरेर माफ गर्न सकिन्छ।

IOP परीक्षण को पाठ्यक्रम को दौरान (जो एक वा धेरै घटनाहरु हुन सक्छ), WG ब्लुटुथ SIG मुद्दा ट्र्याकि system प्रणाली को उपयोग गरी मुद्दाहरु लाई ट्र्याक गर्नुपर्छ र मस्यौदा विनिर्देशन, परीक्षण कागजातहरु, र IOP परीक्षण योजना को अपडेट शामिल गर्न को लागी पुनरावृत्ति। एकपटक IOP परीक्षण समाप्त भएपछि, WG ले ड्राफ्ट स्पेसिफिकेशन को अपडेट पूरा गर्नु पर्छ र सबै मुद्दाहरु लाई सम्बोधन गर्न को लागी कागजातहरु को परीक्षण गर्नु पर्छ, र BARB लाई IOP परीक्षण रिपोर्ट तयार गरी पेश गर्नु पर्छ।view र अनुमोदन। यो चित्र ५.१ मा चित्रण गरिएको छ।

प्रमाणीकरण चरणको दौरान त्यहाँ धेरै गतिविधिहरू छन् जुन सुरू हुन सक्दछ। यी गतिविधिहरू समानान्तरमा देखा पर्न सक्छन् र निम्न समावेश गर्दछ:

• BoD- अनुमोदित ०.0.9/सीआर विनिर्देशन BSTS द्वारा सबै सदस्यहरु को लागी सदस्य पुनः को अधिसूचना संगै उपलब्ध गराईन्छ।view अवधि bylaws द्वारा आवश्यक छ।
• कुनै आवश्यक अद्यावधिकहरू CSS मा समाहित गरियो (जुन विनिर्देशको एब्रेभिएटेड सीआरमा सम्मिलित हुन सक्छ)।
• विशेषता वा वर्णनकर्ता परिभाषाहरू GSS विनिर्देशको साथसाथै IOP परीक्षणको लागि PTS सम्मिलित छन्।
• मेश सम्पत्ति परिभाषाहरू एमडीपी विशिष्टताका साथै आईओपी परीक्षणको लागि पीटीएसमा समाहित छन्।
• BSTS ले IOP प्लेटफर्म पंजीकरण र IOP परीक्षणको तयारीको लागि परिणाम प्रविष्टि उपकरण सक्षम गर्दछ।
• IOP परीक्षण, यदि आवश्यक छ भने (सेक्सन .5.1.१ हेर्नुहोस्)।
• Review टिप्पणी र मुद्दाहरु, IOP परीक्षण को परिणाम को रूप मा पेश गरीएको सहित, प्रशोधन गरीन्छ र परिवर्तन मस्यौदा विनिर्देश मा शामिल गरीन्छ।

.5.1.१ IOP परीक्षण

IOP परीक्षण को प्राथमिक उद्देश्य पूर्व द्वारा, द्वारा विनिर्देश प्रमाणित गर्न को लागी होample, पाठ भित्र सटीकता र अस्पष्टता को लागी जाँच, पुनviewकुनै पनि आधारभूत डिजाइन त्रुटिहरु र चूक को लागी आईएनजी, र विनिर्देशन विकास प्रक्रिया मा पहिले विकसित पहिले स्थापित आवश्यकताहरु को बिरूद्ध प्रमाणीकरण प्रदान। IOP परीक्षण मस्यौदा विनिर्देश मा परिवर्तन र धेरै IOP परीक्षण घटनाहरु सबै आवश्यक परीक्षण पूरा गर्न को लागी आवश्यक हुन सक्छ।

यो WG बाहिर सदस्यहरु लाई IOP परीक्षण मा भाग लिने अवसर प्रदान गर्न को लागी महत्वपूर्ण छ किनकि उनीहरु एक स्वतन्त्र प्रदान गर्दछन् view स्पेसिफिकेशन को छ र स्पेसिफिकेशन मा अस्पष्टता को क्षेत्रहरु लाई उजागर गर्न सक्छ जुन WG का सदस्यहरु लाई स्पष्ट नहुन सक्छ जसले ड्राफ्ट को विकास गरे। प्रत्येक IOP परीक्षण घटना भन्दा पहिले, BSTS घटना को विवरण, नवीनतम मस्यौदा विनिर्देशन, टेस्ट सुइट, र IOP परीक्षण योजना उपलब्ध गराउनेछ र प्रत्येक सदस्यहरु लाई आदर्श रूप मा एक महिना भन्दा पहिले एक महिना को सूचित गरिनेछ। अपडेट गरिएको मस्यौदा स्पेसिफिकेशन, टेस्ट सुइट, र IOP परीक्षण योजना एक IOP परीक्षण घटना मा प्रयोग गरीएको छ कम्तीमा एक हप्ता पहिले प्रत्येक कार्यक्रम को लागी उपलब्ध हुनुपर्दछ।

IOP परीक्षणको बखत, प्लेटफर्मको पेयरवाइज संयोजनले परीक्षणहरू कार्यान्वयन गर्ने प्रयास गर्नेछ र IOP परीक्षण सहभागीहरूले प्रत्येक परीक्षण र टिप्पणीहरूको पास / असफल परिणामहरू रेकर्ड गर्नेछन्। यी परिणामहरूको अज्ञात सारांश (उदाहरणका लागि, "प्लेटफार्म ए", "प्लेटफर्म बी", इत्यादि) र कुनै पनि टिप्पणीहरू IOP परीक्षण घटनाहरूको बखत जम्मा गरिनेछ र IG को अवधिमा र पछि WG का सदस्यहरूलाई उपलब्ध गराइनेछ। परीक्षण घटना यदि आईओपी परीक्षणको क्रममा भएको कुनै पनि टिप्पणी वा असफलताको बारेमा अझ राम्रो समझ लिनको लागि अतिरिक्त जानकारी आवश्यक भएमा, BSTS ले सबमिट गर्ने सदस्यबाट थप जानकारी भेला गर्न बिचौलिएको रूपमा काम गर्न सक्छ।

यदि सम्भव छ भने, PTS होस्ट कन्ट्रोलर ईन्टरफेस (HCI) माथिको सबै तहहरूमा प्लेटफर्महरूसँग IOP परीक्षण समर्थन गर्न अद्यावधिक गर्नुपर्दछ, र ती तहहरूको लागि IOP परीक्षण घटनाहरूमा उपस्थित हुनुहोस्। अन्य परीक्षण उपकरणहरू IOP परीक्षण घटनाहरूमा पनि हुन सक्छ। PTS वा अन्य परीक्षण उपकरणहरू (यदि कुनै छ भने) को साथ परीक्षणको नतीजाको सारांश IOP परीक्षण रिपोर्टमा समावेश गर्नुपर्नेछ।

आईओपी परीक्षण सबै सदस्यहरूको लागि खुला हुनेछ जसले प्रोटोटाइप कार्यान्वयन प्रदान गर्न चाहान्छन्, यद्यपि ब्लुटुथ SIG ले ब्लुटुथ हस्ताक्षर (सहभागिता र गोपनीयता सम्झौता सहित) सँग सम्झौताको स्वीकृतिमा सहभागिताको सर्त गर्न सक्दछ। डब्ल्यूजी आईओपी परीक्षणको क्रममा पत्ता लागेका मुद्दाहरूको प्रसंस्करण र समाधानको लागि जिम्मेवार छ, र प्रभावित कागजातहरू अपडेट गर्ने; WG- अनुमोदित परिवर्तनहरू प्रत्येक IOP परीक्षण घटनामा प्रयोगको लागि ड्राफ्ट विशिष्टता र परीक्षण कागजातहरूका लागि अपडेटको रूपमा समावेश गरिएको हुनुपर्दछ।

प्रमाणीकरण चरण भन्दा पहिले, WGs ले WI का सदस्यहरूका लागि मात्र खुला हुने घटनाहरूमा प्रारम्भिक IOP परीक्षण गर्न सक्दछ, जबकि अनौपचारिक परीक्षणको नतीजा IOP परीक्षण परिणामहरूमा सामेल हुन सक्दैन।

यो हुन सक्छ कि पहिलो IOP परीक्षण घटना सम्म पुग्ने सबै चरणहरू अनुसरण गरिन्छ, IOP परीक्षण सुरु गर्ने इरादाको साथ घोषणा गरिएको IOP मिति र स्थान सहित, तर BoD अनुमोदन परीक्षण घटना सुरु हुनु अघि सुरक्षित गरिएको थिएन। यस अवस्थामा, बोडले IO परीक्षण सुरु गर्न BoD को स्वीकृति अघि संकलन गरिएको परीक्षण परिणामहरू समावेशीकरण गर्न अधिकार प्रदान गर्न सक्दछ, बसाईएको परिणामहरू उही विशिष्टता र BoD द्वारा अनुमोदन गरिएको टेस्ट सुइटमा आधारित थियो।

IOP परिक्षण CSS, GSS, वा MDP विशिष्टताहरूमा सुधारको लागि आवश्यक छैन।

IOP परीक्षण रिपोर्ट
IOP परीक्षण पूरा भएपछि, WG ले IOP परीक्षण रिपोर्ट BARB मा पेश गर्नु पर्छ कि स्वतन्त्र प्लेटफर्म को आवश्यक संख्या आवश्यक परीक्षण उत्तीर्ण गरीएको छ। BARB पुन: हुनुपर्छview र IOP परीक्षण रिपोर्ट अनुमोदन वा अस्वीकार गर्नुहोस् र WG लाई सूचित गर्नुहोस् यदि BOD मा मतदान ड्राफ्ट स्पेसिफिकेशन प्याकेज पेश गर्नु भन्दा पहिले अतिरिक्त IOP परीक्षण आवश्यक छ। BSTS र WG ले यो सुनिश्चित गर्नु पर्छ कि BARB लाई रिपोर्ट पेश गर्नु अघि IOP परीक्षण रिपोर्ट मा कुनै सदस्य पहिचान गर्ने जानकारी देखा पर्दैन।

IOP परीक्षण रिपोर्टमा समावेश हुनुपर्दछ:

• सबै IOP परीक्षण घटनाहरूको सूची जुन उनीहरूको मितिहरू र स्थानहरू सहित मान्यीकरण चरणको दौडान भयो।
• सदस्य कम्पनीहरूको संख्या र स्वतन्त्र प्लेटफर्महरू जुन प्रत्येक IOP कार्यक्रममा PTS प्रयोग गरिएको थियो सहित समावेश थियो।
• विशिष्टताको सूची, टेस्ट सुइट, र IOP परीक्षण योजना संस्करणहरू प्रत्येक घटनामा प्रयोग गरियो।
• सबै परीक्षण केसहरूले न्यूनतम पास मापदण्ड पूरा गरे कि गर्दैन भनेर एक कार्यकारी सारांश।
• IOP परीक्षण योजना आवश्यकताहरुबाट कुनै पनि भिन्नताको सारांश 4.3.1..XNUMX.१ मा परिभाषित गरिएको छ र प्रत्येक भिन्नताका लागि तर्क।
• परीक्षण सूटमा परीक्षण केसहरूको लागि PTS कभरेजको सारांश।
• सबै परीक्षण केसहरूको सूची (पिछडिएको अनुकूलता परीक्षण सहित) आईओपी परीक्षण योजनाबाट, परीक्षण पासहरूको संख्या, परीक्षण असफलताको संख्या, र न्यूनतम मापदण्ड पूरा भए पनि परीक्षणको केसमा पूरा भयो कि किन कुनै आवश्यकताहरू थिएनन्। भेटियो
• मुद्दाहरु, टिप्पणीहरु, र प्रत्येक घटना मा प्रश्नहरुको सारांश (ती सहित fileडी IOP परीक्षण को समयमा विनिर्देश को बिरुद्ध) र विनिर्देशन र परीक्षण कागजातहरु लाई प्रभाव।

.5.2.२ मान्यकरण चरण निकास आवश्यकताहरू

प्रमाणीकरण चरण पूर्ण भयो र अनुमोदन / अंगिकार चरण सुरु हुन्छ जब BARB ले IOP परीक्षण रिपोर्टलाई अनुमोदन गर्‍यो (जबसम्म परीक्षण BARB द्वारा माफ गरिएको थिएन) र निम्न सबै आवश्यकताहरू पूरा गरिए:

• BSTS अनुमोदित ०.0.9/सीआर विनिर्देशन सदस्य पुनः को लागी सबै सदस्यहरुलाई उपलब्ध गराईएको छview उपनियमहरु द्वारा आवश्यक छ र यसको उपलब्धता को सबै सदस्यहरुलाई सूचित।
• सबै मुद्दाहरू जुन आईओपी परीक्षणको क्रममा पहिचान गरिएको थियो, र जसको परीक्षणमा प्रभाव छ, समाहित गरियो र परीक्षण गरियो।
• WG ले IOP परीक्षण पूरा गरिसक्यो (जबसम्म BARB द्वारा परीक्षण माफ गरिएको थिएन)।

 

Ad. दत्तक / अनुमोदन चरण

दत्तक ग्रहण/अनुमोदन चरण को दौरान, स्पेसिफिकेशन र सम्बन्धित परीक्षण कागजातहरु लाई अन्तिम रूप दिईन्छ, BARB, BQRB, र BTI अनुमोदन प्राप्त हुन्छ, प्रस्तावित गोद लिने मिति को नोटिस जारी गरीएको छ ड्राफ्ट स्पेसिफिकेशन को अन्तिम संस्करण को लागी गोद लिएको को लागी पेश गरीएको छ ( भोटिंग ड्राफ्ट), र अन्तिम विनिर्देश प्याकेज BoD मा पेश गरीएको छ। सदस्य पुनः को न्यूनतम अवधि पछिview Bylaws द्वारा आवश्यक [2]) संतुष्ट हो गया है, BoD दत्तक मिति मा अपनाउने को लागी विनिर्देश लाई विचार गर्नेछ। गोद लिए पछि, विशिष्टता प्रकाशित छ र योग्यता प्रणाली सक्षम छ। दत्तक ग्रहण/अनुमोदन चरण चित्र .6.1.१ मा सचित्र छ।

.6.1.१ मतदान मस्यौदा

मतदान ड्राफ्ट आवश्यक विनिर्देशन कागजातहरूमा अद्यावधिक (मान्यकरण चरणमा प्रदान गरिएको) समावेश गरेर, र नयाँ विशिष्टताको अन्तिम मस्यौदा तयार गरेर सिर्जना गरिएको हो। विशिष्टता बृद्धिका लागि, बीएसटीएसले एक वा बढी सीआर (हरू) लाई विगतको पूर्वनिर्धारित उच्च संस्करणमा एकीकृत गरेर एकीकृत विशिष्टता सिर्जना गर्दछ (सेक्सन 4.3.2..XNUMX.२ हेर्नुहोस्) यदि प्रमाणीकरण चरण भन्दा पहिले पूरा भएको छैन।

यदि यस चरणको बखत विशिष्टता परिवर्तन गरियो र WG, BARB, वा BTI ले निर्धारण गर्दछ कि कुनै पनि परिवर्तनलाई थप IOP परीक्षणको आवश्यकता पर्दछ, विनिर्देशन WG का लागि अतिरिक्त परीक्षणहरू गर्न वैधता चरणको IOP परीक्षण भागमा फर्किनेछ। दत्तक / अनुमोदन चरणको बखत, निम्न कागजातहरू पूरा हुनेछन् र बीओडीलाई दत्तक दिनको अघि उपलब्ध गराइनेछ:

• मतदान मस्यौदा
• सबै समर्थन विशिष्टताहरू (उदाहरणका लागि, CSS, GSS, MDP) प्रासंगिक विशिष्टता (वा विस्तार) प्रकारको लागि आवश्यक छ, यदि पहिले अपनाएको छैन भने।
• विशिष्टता वृद्धिहरूका लागि, मतदान ड्राफ्टमा प्रस्तावित परिवर्तनहरू देखाउँदै अपनाईएको विशिष्ट संस्करणको परिवर्तन ट्र्याक गरिएको संस्करण
• कुनै पछाडि संगतता आवश्यकताहरूको WG बाट वर्णन (सेक्शन 3.3.2.२ मा वर्णन गरिएको छ) जुन पूरा गरिएको छैन र कुनै पनि छुटका लागि औचित्य।
• कुनै पनी IOP परीक्षण योजना आवश्यकताहरु (खण्ड ४.३.१ मा वर्णन गरीएको) को WG बाट एक विवरण जुन पूरा भएको छैन र IOP परीक्षण रिपोर्ट संग कुनै विचलन को लागी औचित्य (जुन प्रतिलिपि को लागी एक लिंक प्रदान गरी प्रदान गरीन्छ। ब्लुटुथ SIG webसाइट)
• 0.9/सीआर एस पछि परिवर्तन हाइलाइट गर्दै एक औचित्य संगै अपनाईएको स्पेसिफिकेशन को कुनै पनी अघिल्लो संस्करण (हरू) को मूल्यह्रास वा फिर्ता को लागी WG बाट एक सिफारिशtagई-जीवन को सिफारिश
• एक सारांश, WG द्वारा तैयार, ०.० / CR विशिष्टता (यदि कुनै) बाट सुविधाहरू वा कार्यक्षमतामा परिवर्तनको परिवर्तन।
• एक सारांश, BARB द्वारा तैयार, BARB सदस्यहरू द्वारा उठाएको चिन्ताको कि WG द्वारा उत्पादित विशिष्टता BoD द्वारा अनुमोदित चार्टरको दायरा बाहिर छ (यदि कुनै छ भने)
• कानूनी पुनः बाट बाँकी अनसुलझा कानूनी मुद्दाहरु को एक सूचीview (यदि कुनै)
• BTI- अनुमोदित टेस्ट सुइट, WG- अनुमोदित सारांशको साथ मतदान मस्यौदा विवरणको परीक्षण कभरेजको सारांश। परीक्षण कभरेस बिना नयाँ थपिएको वा संशोधित कार्यक्षमताको मामलामा, छुटको लागि लिखित औचित्य आवश्यक छ
• BTI- अनुमोदित ICS र IXIT (यदि निर्दिष्ट द्वारा आवश्यक छ)
• TCRL दुबै BTI र BQRB द्वारा अनुमोदित छ
• BSTS द्वारा एक प्रतिवेदन सँगै BTI सँग उपकरण तयारीको स्थिति (उदाहरणका लागि, PTS र अन्य परीक्षण उपकरणहरू, ब्लुटुथ सुरूवात स्टुडियो) को सम्बन्धमा तैयार छ यदि TCRL मा कुनै परीक्षण केसहरू परीक्षण उपकरणहरू द्वारा समर्थित छैनन् भने
• एक सारांश, WG द्वारा तैयार, सबै आवश्यक तोकिएको संख्याहरूको
• BSTS र WG द्वारा तैयार गरिएको एउटा गोद लिईएको सूचीले देखाउँदछ कि यस खण्डमा सबै वितरणहरू पूरा भइसकेका छन्
• सबै अन्य जानकारी BoD द्वारा अनुरोध गरियो

दत्तक / अनुमोदन चरणको अवधिमा, WG ले मस्यौदा विशिष्टता र परीक्षण कागजातहरूका बिरूद्ध मुद्दाहरू र टिप्पणीहरू कब्जा गर्न ब्लुटुथ SIG को मुद्दा ट्र्याकिंग प्रणाली प्रयोग गर्नुपर्दछ ताकि उनीहरूलाई मतदान मस्यौदा विशिष्टताको अन्तिमकरणमा हिसाब गरिनेछ। एक विशिष्टता बृद्धिका लागि, सबै प्रासंगिक स्वीकृत इर्राटा (अर्थात ती अनुमोदित इरटा अझै सम्म एकीकृत छैनन्) समाहित हुनुपर्दछ, र ट्र्याक परिवर्तन प्रयोग गरेर पहिचान गर्नुपर्दछ।

WG कानूनी पुन: को लागी BSTS लाई अन्तिम मस्यौदा विनिर्देश पेश गर्नु पर्छview। नयाँ विनिर्देशों को लागी, कानूनी पुनःview सम्पूर्ण विनिर्देश समावेश हुनेछ। विनिर्देश संवर्द्धन को लागी, पुनःview विशेष गरी विनिर्देश को परिवर्तन भागहरु मा ध्यान केन्द्रित हुनेछ। कानूनी पुनः को उद्देश्यview मुख्यतः कानूनी जोखिम को पहिचान गर्न को लागी हो कि WG ले विचार गर्नु पर्छ र समाधान गर्न को लागी खोज्नु पर्छ। कानूनी प्रतिक्रिया गम्भीरता को आधार मा वर्गीकृत गरिनेछ। यदि एक वैकल्पिक कानूनी पुनःview ०.0.9/सीआर एस मा प्रदर्शन गरिएको थियोtagई, कानूनी पुनः को लागी पेश गरीएको संस्करणview ट्र्याक गरिएका परिवर्तनहरु को रूप मा देखाउनै पर्छ, सबै परिवर्तनहरु कि संस्करण बाट बनाइयो (या त WG वा BSTS द्वारा उत्पन्न)। कानूनी पुन: पूरा भएपछिview, WG र BSTS प्रतिक्रिया मा मस्यौदा विनिर्देश मा शामिल गर्न सहमत हुनेछन्। यदि त्यहाँ कानूनी पुनः बाट कुनै अनसुलझे कानूनी टिप्पणीहरु छन्view मस्यौदा विनिर्देश मा, WG अध्यक्ष BoD एजेन्डा मा समय मा अनुरोध मा संकल्प मा सहमत हुन सक्छ।

कानूनी पुनः संग समानांतर माview, WG मस्यौदा विनिर्देशन BARB लाई पुन: पेश गर्नु पर्छview। BARB मा प्रारम्भिक सबमिशन पछि, BSTS ले सबै सदस्यहरुलाई सूचित गर्दछ कि ड्राफ्ट स्पेसिफिकेशन BARB लाई पुन: पेश गरीएको छ।view र यो पनि सदस्य रे को लागी उपलब्ध छview। यदि WG BARB re-re को लागी ड्राफ्ट स्पेसिफिकेशन को लागी अपडेट सबमिट गर्दछview, BSTS एक आवधिक आधारमा सबै सदस्यहरुलाई अतिरिक्त नोटिस पठाउनेछन्।

BARB re को पूरा भएपछिview, WG र BARB मस्यौदा स्पेसिफिकेशन मा समावेश गर्न को लागी प्रतिक्रिया मा सहमत हुनेछन्।

यदि कानूनी पुनःview कुनै पनि ठोस परिवर्तन, अतिरिक्त पुनः मा परिणामview BARB द्वारा आवश्यक हुन सक्छ। त्यस्तै गरी, यदि BARB पुनःview कुनै पनी आधारभूत परिवर्तन मा परिणाम, BSTS एक अतिरिक्त कानूनी पुन यदि निर्धारित हुनेछview ती परिवर्तनहरु को आवश्यकता छ। कानूनी पुन: पूरा भएपछिview र BARB पुनःview, BARB या त अनुमोदन वा मतदान ड्राफ्ट अस्वीकार गर्नुपर्छ।

यदि कुनै परिक्षण कागजात अपडेट गर्न आवश्यक छ, BSTS WG लाई परीक्षण कागजात अपडेट गर्न मद्दत गर्दछ। BTI या त परीक्षण कागजातहरुलाई अनुमोदन वा अस्वीकार गर्नु पर्छ। यदि BTI द्वारा अनुमोदित भए, BTI ले TCRL लाई अन्तिम रूप दिई सहयोग पुर्‍याउँछ ICR, IXIT, र परीक्षण सुइटसँग यो कागजात BQRB लाई पुर्‍याउँछ। BSTS ले BoD बैठकको मिति अनुमान गर्नेछ जब BoD ले मतदान मस्यौदा (ग्रहण मिति) लाई अपनाईएकोमा मतदान गर्न चाहन्छ र TCRL मा प्रयोगको लागि BTI प्रदान गर्दछ। विनिर्देशको BARB अनुमोदन, सबै परीक्षण कागजातहरूको BTI अनुमोदन (टेस्ट सुइट, TCRL, ICS, र IXIT सहित), र TCRL को BQRB स्वीकृति गोद लिन वा मिति हुनुपर्दछ।

BSTS ले मतदाता मस्यौदा को अन्तिम रूप र उपलब्धता र अपनाउने मिति को उपलब्धता को सबै सदस्यहरुलाई सूचित गर्नेछ। दत्तक ग्रहण मिति earlier० दिन भन्दा पहिले सेट गरीनेछ जब सदस्यहरु लाई BoD द्वारा अनुमोदित ०.60/CR स्पेसिफिकेशन को अधिसूचित गरियो, जब सम्म सदस्य पुन:view अवधि बीओडी द्वारा उपनियम अनुसार छोटो छ, र कम से कम १४ दिन को गोद लिने मिति को सूचना पछि उपनियम अनुसार सदस्यहरुलाई प्रदान गरीएको छ। धेरै सीआर एक भोटि D ड्राफ्ट मा एकीकृत गरीएको छ जहाँ मामलाहरु को लागी, सदस्य पुनः को शुरुआतview मिति हो जसमा सदस्यहरुलाई सबैभन्दा भर्खरको BoD- अनुमोदित CR को अधिसूचित गरियो।

दत्तक मिति को सूचना सदस्यहरु लाई प्रदान पछि, BoD- अनुमोदित सुधार मतदान मस्यौदा मा typographic त्रुटिहरु को लागी अनुमति छ। विशिष्टता ग्रहण समय रेखा चित्र .6.2.२ मा चित्रित छ।

.6.2.२ तोकिएको संख्या

ब्लुटुथ SIG ब्लुटुथ SIG असाइन गरिएको नम्बर मा तोकिएको संख्या को एक सार्वजनिक उपलब्ध सेट राख्छ webसाइट [7]। यी तोकिएको संख्या बिभिन्न संख्या रिक्त स्थान (कुनै नक्कल संग संख्या को एक सम्बन्धित सेट) मा समूहीकृत छन्। तोकिएको संख्या फरक संख्या रिक्त स्थान मा अन्य तोकिएको संख्या संग ओभरलैप हुन सक्छ, तर एक संख्या अन्तरिक्ष भित्र कुनै संख्या पुन: प्रयोग गर्न अनुमति छ। विभिन्न संख्या रिक्त स्थान निर्दिष्टीकरण मा निर्दिष्ट संख्या को उपयोग परिभाषित गर्दछ।

BARB IOP परीक्षण रिपोर्ट अनुमोदन पछि, WG अन्तिम स्पेसिफिकेशन द्वारा आवश्यक संख्या अन्तरिक्ष (हरू) भित्र नयाँ संख्या को असाइनमेन्ट को लागी BARB लाई अनुरोध पेस गर्नेछ। BARB फेरि हुनेछview अनुरोध र BSTS संग काम तोकिएको संख्या निर्धारण गर्न। BARB अनुमोदन मा, BSTS तोकिएको संख्या को प्रकाशन अनुसूची सार्वजनिक ब्लुटुथ SIG असाइन नम्बर मा सार्वजनिक रूपमा उपलब्ध गराईनेछ। webसाइट [7] विनिर्देशन को गोद लिएको एक हप्ता भित्र।

एक पटक ब्लुटुथ SIG असाइन गरिएको नम्बर मा तोकिएको संख्या को प्रकाशन webसाइट वा एक अपनाईएको स्पेसिफिकेशन भित्र हुन्छ, तोकिएको संख्या अपरिवर्तनीय (या त मूल्य वा अर्थ मा परिवर्तन गर्न को लागी) को उद्देश्य हो। यदि उनीहरु कुनै कारण को लागी अनुपयोगी बन्छन्, ती आरक्षित मूल्यहरु बन्छन् र पुन: प्रयोग गर्न को लागी अनुमति छैन।

.6.3..XNUMX ग्रहण / अनुमोदन चरण निकास आवश्यकताहरू

स्वीकृति / अंगिकार चरण पूर्ण हुन्छ जब BoD ले विनिर्देशनलाई ग्रहण गर्‍यो र निम्न पोस्ट-अपोप्शन गतिविधिहरू पूरा भए।

• BSTS ले ब्लुटुथ SIG मा सार्वजनिक रूपमा उपलब्ध अन्तिम तोकिएको संख्या बनाएको छ webसाइट।
• BSTS ले अपनाईएको स्पेसिफिकेशन ब्लुटुथ SIG मा सार्वजनिक रुपमा उपलब्ध गराएको छ webसाइट
• BSTS सबै समर्थन कागजात (जस्तै, CSS, GSS, MDP) ब्लुटुथ SIG मा सार्वजनिक रूपमा उपलब्ध प्रासंगिक विनिर्देशन को लागी आवश्यक बनाएको छ। webसाइट।
• BSTS सम्बन्धित परीक्षण कागजात ब्लुटुथ SIG मा सबै सदस्यहरु को लागी उपलब्ध गराएको छ webसाइट।
• विनिर्देशन संवर्द्धन को लागी, BSTS ले भर्खरै अपनाएको संस्करण द्वारा बनाईएको सबै परिवर्तनहरु संग पहिले अपनाईएको विनिर्देशन संस्करण को एक सूचनात्मक परिवर्तन ट्र्याक संस्करण बनाएको छ र यो ब्लुटुथ SIG मा सबै सदस्यहरुलाई उपलब्ध गराईयो। webसाइट।
• BSTS योग्यता प्रणाली सक्षम छ।
• BSTS ले सबै सदस्यहरूलाई अपनाईएको विशिष्टता र सबै समर्थन कागजातहरूको उपलब्धताबारे सूचित गरेको छ।

ब्लुटुथ SIG ले स्पेसिफिकेसनको स्वीकृति पछाडि एक हप्ता भित्र यी पोस्ट-ग्रहण गतिविधिहरू पूरा गर्ने योजना बनायो।

 

Spec. विशिष्ट रखरखाव चरण

विशिष्ट रखरखाव चरण दत्तक / स्वीकृति चरण पूरा भएपछि सुरु हुन्छ। यदि समस्या फेला पर्‍यो (उदाहरणका लागि, शब्द अस्पष्टता वा प्राविधिक त्रुटिहरू) विशिष्टता वा सम्बन्धित परीक्षण कागजातहरूको साथ, तिनीहरू ब्लुटुथ SIG एर्राटा उपकरण प्रयोग गरेर इराटा प्रस्तावहरू सिर्जना गरेर कागजात गर्नुपर्दछ। विशिष्ट ईर्याटम प्रस्तावहरू प्रक्रिया, वर्गीकृत, र EPD अनुसार अनुमोदन हुनेछ []]। टेस्ट सुइट एर्याटम टीएसटीओ []] अनुसार प्रकृया र वर्गीकृत छन्। यदि त्यहाँ SMPD र कि त EPD वा TSTO बीच कुनै विवाद छ, SMPD प्राथमिकता लिन्छ।

विशिष्ट ईर्याटम केवल अन्तिम अपनाइएको ब्लुटुथ विनिर्देशहरूमा प्राविधिक वा सम्पादकीय त्रुटिहरू सच्याउनको लागि प्रयोग गरिनु पर्छ। यसका अतिरिक्त, परिवर्तन र कार्यक्षमता हटाउने यो कागजातमा पहिले परिभाषित विशिष्टता बृद्धि प्रक्रिया मार्फत मात्र गर्न सकिन्छ।

.7.1.१ ईरिटम प्रक्रिया द्रुत

जब EPD [3] मा परिभाषित प्रक्रिया पछी एक इरेटम अनुमोदित हुन्छ, WG, BARB, वा BSTS ले सिफारिश गर्न सक्छ कि यो जरुरी मानिन्छ र छिटो हुनु पर्छ। जब यो हुन्छ, WG वा BARB संग BSTS BoD लाई सिफारिश पेश गर्दछ। बीओडीले निर्णय स्वीकार गर्ने वा अस्वीकार गर्ने निर्णय गर्नेछ। यदि सिफारिश स्वीकार गरियो भने, BSTS तुरुन्तै अनुमोदित इरेटम इरेटम टेम्प्लेट [8] मा सम्मिलित हुनेछ र जिम्मेवार WG सँग काम गरी एक छिटो इरेटा सुधार को लागी WG लाई पुन: पेश गर्न को लागी अन्तिम रूप दिनेछ।view र अनुमोदन।

एक ओभरview छिटो erratum प्रक्रिया को चित्र 7.1 मा सचित्र छ।

निम्नलिखित कागजातहरू पूरा गर्नुपर्नेछ र BoD मा उपलब्ध गराउनु पर्नेछ गोद लिने मिति भन्दा पहिले:

• BARB- अनुमोदित ड्राफ्ट शीघ्र इरटा सुधार।
• कुनै पछाडि संगतता आवश्यकताहरूको WG बाट वर्णन (सेक्शन 3.3.2.२ मा वर्णन गरिएको छ) जुन पूरा गरिएको छैन र कुनै पनि छुटका लागि औचित्य।
• कानूनी पुनः बाट बाँकी अनसुलझा कानूनी मुद्दाहरु को एक सूचीview (यदि कुनै हो)।
• BTI- अनुमोदित टेस्ट सुइट, ICS, र IXIT (यदि इरातम द्वारा आवश्यक छ)।
• BTI- र BQRB- अनुमोदित TCRL (यदि इराटम द्वारा आवश्यक छ)।
• BSTS द्वारा पूरा गरिएको रिपोर्ट BTI सँग उपकरण तयारीको स्थिति (उदाहरणका लागि, PTS र अन्य परीक्षण उपकरणहरू, ब्लुटुथ सुरूवात स्टुडियो) को बारेमा सम्बन्धित छ यदि TCRL मा कुनै परीक्षण केसहरू परीक्षण उपकरणहरू र एक स्पष्टीकरण द्वारा समर्थित छैनन् (यदि इरातमद्वारा आवश्यक भएमा )।
• BSTS र WG द्वारा पूरा गरिएको एउटा धर्मपुत्राधिकार चेकलिस्टले देखाउँदछ कि यस खण्डमा डेलिभरेवलहरू सबै पूरा भइसकेका छन्।
• सबै अन्य जानकारी BoD द्वारा अनुरोध गरियो।

BSTS जिम्मेवार WG सँग काम गरी छिटो इरेटा सुधार को मस्यौदा लाई अन्तिम रूप दिन को लागी जिम्मेवार WG लाई पेस गर्न को लागी एक संस्करण सिर्जना गर्दछ।view र अनुमोदन।

WG कानूनी पुनः को लागी BSTS लाई छिटो इरेटा सुधार पेस गर्नु पर्छview। कानूनी पुन: पूरा भएपछिview, WG र BSTS शीघ्र इरेटा सुधार मा सम्मिलित हुने प्रतिक्रिया मा सहमत हुनेछन्। यदि त्यहाँ कानूनी पुनः बाट कुनै अनसुलझे कानूनी टिप्पणीहरु छन्view शीघ्र इरेटा सुधार मा, WG अध्यक्ष BoD एजेन्डा मा समय अनुरोध गर्न सक्नुहुन्छ संकल्प मा BoD इनपुट खोज्न।

कानूनी पुनः संग समानांतर माview, WG ले छिटो इरेटा सुधार पुन: को लागी BARB लाई बुझाउनु पर्छview। एक पटक छिटो इरेटा सुधार BARB मा पेस भएपछि, BSTS ले यसलाई सबै सदस्यहरुको लागी पुन: पहुँचयोग्य बनाउनेछ।view र यसको उपलब्धता को सबै सदस्यहरुलाई सूचित गर्नुहोस्। BARB re को पूरा भएपछिview, WG र BARB शीघ्र इरेटा सुधार मा सम्मिलित हुने प्रतिक्रिया मा सहमत हुनेछन्।

यदि कानूनी पुनःview कुनै पनि ठोस परिवर्तन, अतिरिक्त पुनः मा परिणामview BARB द्वारा आवश्यक हुन सक्छ। त्यस्तै गरी, यदि BARB पुनःview कुनै पनी आधारभूत परिवर्तन मा परिणाम, BSTS एक अतिरिक्त कानूनी पुन यदि निर्धारित हुनेछview ती परिवर्तनहरु को आवश्यकता छ। कानूनी पुन: पूरा भएपछिview र BARB पुनःview, BARB ले अनुमोदन वा छिटो इरेटा सुधार अस्वीकार गर्नुपर्छ।

यदि कुनै परिक्षण कागजात अपडेट गर्न आवश्यक छ, BSTS WG लाई परीक्षण कागजात अपडेट गर्न मद्दत गर्दछ। परीक्षण कागजातहरूको BTI स्वीकृति पछि, BTI TCRL लाई अन्तिम रूप दिई सहयोग पुर्‍याउँछ ICR, IXIT, र टेस्ट सुइट लागू सहित कागजात BQRB लाई प्रदान गर्दछ। BSTS ले एडप्टेसन मिति अनुमान गरी TCRL मा प्रयोगको लागि BTI लाई प्रदान गर्दछ। द्रुत इर्राटा सुधारको BARB स्वीकृति, सबै परीक्षण कागजातहरूको BTI अनुमोदन (टेस्ट सुइट, TCRL, ICS, र IXIT लागूको रूपमा), र TCRL को BQRB स्वीकृति गोद लिने मितिमा वा अघि आउनुपर्दछ।

BSTS ले सबै सदस्यहरुलाई जानकारी दिईनेछ र तीब्रता सुधारको प्रस्ताव र प्रस्तावित एडप्टेसन मितिको अन्तिमता र उपलब्धताका बारे जानकारी दिनेछ। दत्तक मिति तोकिनेछ र उप सदस्य [२] बमोजिम सबै सदस्यहरुलाई सूचित गरिनेछ र दत्तक दिनांक कम्तिमा १ 2 दिन सम्म सभालाई सूचना दिए पछि हुनु पर्नेछ। प्रस्तावित दत्तक मिति को सूचना सदस्यहरु लाई प्रदान पछि, BoD प्रस्तावित दत्तक मिति को एक अतिरिक्त सूचना प्रदान नगरी र आवश्यक १ 14 दिन पर्खेर, शीघ्र इर्राटा सुधारमा टाइपोग्राफिक त्रुटिहरूको सुधार गर्न अनुमोदन गर्न सक्छ।

ब्लुटुथ SIG ले अपनाईएको तीव्र ईरटा सुधारलाई सार्वजनिक रूपमा उपलब्ध गराउँदछ र गोद दिए पछि एक हप्ता भित्र त्यसो गर्ने योजना बनाउँदछ। यसको उपलब्धताको सूचना सबै सदस्यहरूलाई BSTS द्वारा जारी गरिनेछ।

शीघ्र एर्याटम प्रक्रिया पूरा हुन्छ जब BoD ले तीव्र ईरटा सुधार लाई ग्रहण गर्‍यो र निम्न पछाडि अपनाउने गतिविधिहरू पूर्ण भए।

• BSTS ले अपनाएको छिटो इरेटा सुधार र सम्बद्ध परीक्षण कागजातहरु (यदि इरेटम द्वारा आवश्यक छ) ब्लूटूथ SIG मा सार्वजनिक रूपमा उपलब्ध गराईएको छ। webसाइट।
• BSTS योग्यता प्रणाली सक्षम गरिएको छ (यदि इराटम द्वारा आवश्यक छ भने)।
• BSTS ले सबै सदस्यहरुलाई अपनाईएको एक्स्पेटेड इर्राटा सुधारको उपलब्धताका बारे सूचित गरेको छ।

यी गतिविधिहरूको पूर्णतामा, एर्राटा सुधार प्रभावित विनिर्देशहरूमा एकीकृतको लागि तोकिनेछ योजनाबद्ध विनिर्देशन वृद्धिको भागको रूपमा वा धारा .7.2.२ मा वर्णन गरिए अनुसार आगामी मर्मत विज्ञप्तिमा।

.7.2.२ रखरखाव रिलिज प्रक्रिया (.Z निर्दिष्टताहरू)

लगभग वार्षिक आधारमा, बीएसटीएसले निर्धारण गर्दछ कि त्यहाँ कुनै अनुमोदित इर्राटा हो (एर्राटा सुधारको रूपमा परिचित छ) जुन टेक्निकल / उच्च वा टेक्निकल / क्रिटिकलको रूपमा वर्गीकृत गरिएको छ र जुन अझै कुनै पनि सक्रिय विशिष्टताको पाठमा समावेश गरिएको छैन (अर्थात्, एक अपनाईएको विशिष्टता जुन अस्वीकृत वा फिर्ता लिइएको छैन)। एराटा वर्गीकरण परिभाषाहरूको लागि परिशिष्ट A हेर्नुहोस्। एक निर्दिष्ट मालिक (या त WG विशिष्टता कायम गर्न चार्टर्ड, वा BARB छैन यदि WG विनिर्देशन कायम गर्न चार्टर्ड छैन) पनि कुनै सक्रिय विनिर्देशको पहिलेको मर्मत रिलीज अनुरोध गर्न सक्दछ जुनमा कुनै अनुमोदित इरटा समावेश गर्न। या त BSTS दृढ संकल्प, वा विशिष्ट मालिकको अनुरोधमा, मर्मत रिलीज प्रक्रिया सुरू हुनेछ।

एक ओभरview मर्मत रिलीज प्रक्रिया को त्रुटि मा सचित्र छ! सन्दर्भ स्रोत भेटिएन।

मर्मत रिलीज प्रक्रियाको सुरूमा, बीएसटीएसले निर्दिष्ट मालिक, बीएआरबी, र बीटीआईसँग मिलेर प्रकाशित स्पेसिफिकेशन संस्करणमा एराटा सुधारलाई समाहित गर्न बीओडीलाई योजना तयार गर्नेछ। प्रस्तावित योजनाले संकेत गर्नु पर्छ कि एराटा सुधारहरू विनिर्देशको मर्मत रिलीजमा समाहित हुनेछ (जस्तै, एक .Z संस्करण) वा विनिर्देश वृद्धि जुन पहिले नै प्रगतिमा छ (अर्थात्, एक XY संस्करण)। प्रस्तावित योजनालाई ध्यानमा राख्नुपर्नेछ कि कुनै नयाँ अनिवार्य सुविधाहरू अपनाईएको विशिष्टताहरूको संस्करणहरू, अनुमानित समय जब अर्को विनिर्देशन वृद्धि दत्तकको लागि योजना बनाईएको छ, र अन्य कारकहरू बीच जोडियो।

BoD द्वारा एक योजनाको अनुमोदन भएपछि, BSTS ले निर्दिष्ट मालिकसँगै सबै प्राविधिक / मध्यम, प्राविधिक / उच्च, र प्राविधिक / आलोचनात्मक इरेटा सुधारलाई "मर्मत सम्बन्धी प्रकाशन ड्राफ्ट" भनेर चिनिने ड्राफ्ट स्पेसिफिकेसनमा समाहित गर्नेछ। सम्पादकीय वा टेक्निकल / कम इर्राटा सुधारको लागि, यदि एर्राटा सुधार विनिर्देशको एक भन्दा बढी संस्करणमा लागू हुन्छ भने, BSTS ले, BoD ले अन्यथा दर्ता नगरेसम्म ती एर्राटालाई भर्खरको भर्खरको भर्खरको भर्खरको संस्करणमा एकीकृत गर्दछ अर्को संस्करणको अपडेटमा। । कुनै परिवर्तन ईर्राटा सुधारहरू बाहेक मर्मतसम्भार रिलिज ड्राफ्टमा समावेश गर्न सकिदैन। प्रत्येक रखरखाव रिलीज ड्राफ्टले प्रकाशित स्पेसिफिकेशनको पूर्व-अपनाईएको संस्करणमा प्रस्तावित परिवर्तनहरू देखाउन परिवर्तन ट्र्याकिंग प्रयोग गरी सबै समावेशी इरटा सुधारको पहिचान गर्नै पर्दछ।

एक रखरखाव रिलीज ड्राफ्टमा प्रत्येक इरटा सुधारको लागि प्रस्तावित समावेशीकरणको समय परीक्षण सुइट प्रभावमा निर्भर गर्दछ: टेस्ट सुइट प्रभाव नहुने सबै इर्राटा सुधारहरू तुरुन्त समाहित हुन सक्छन, तर टेराइट सुइटमा प्रभाव पार्ने इर्राटा सुधारहरू हुनेछन्। प्रशोधन गरियो ताकि समय TCRL सँग अपडेटको साथ मेल खान्छ।

बीटीआई र बीएसटीएसले एक अनुरक्षण रिलीज ड्राफ्टमा टेरा सुइट प्रभावको साथ इरटा सुधारको समावेशको लागि म्याद तय गर्दछ। यो डेडलाइन सामान्यतया अर्को प्रमुख TCRL रिलीजको योजनाबद्ध स्वीकृति मिति अघि to देखि months महिना सम्म हुन्छ। टेक्स्ट सुइट प्रभावको साथ एर्राटा सुधारहरू समावेशीकरणको लागि अन्तिम म्याद छुटेको अर्को वार्षिक TCRL विमोचनको अंशको रूपमा प्रक्रिया गरिनेछ। तसर्थ, अघिल्लो रिलीज अनुरोध नभएसम्म, टेक्निकल / उच्च वा टेक्निकल / क्रिटिकल इर्राटा सुधारको लागि अधिकतम समय एक निर्दिष्ट अपडेटमा समावेश गर्न १ approximately देखि १ to महिनासम्म हुन्छ।

विशिष्टता मालिक रखरखाव रिलीज ड्राफ्ट पेश गर्नु पर्छ कि यो कानूनी पुनः को लागी अन्तिम को रूप मा अनुमोदित छview। कानूनी पुनःview विशेष गरी विनिर्देश को परिवर्तन भागहरु मा ध्यान केन्द्रित हुनेछ। कानूनी पुन: पूरा भएपछिview, विशिष्टता मालिक र BSTS रखरखाव रिलीज ड्राफ्ट मा शामिल गर्न को लागी प्रतिक्रिया मा सहमत हुनेछन्। यदि त्यहाँ कानूनी पुनः बाट कुनै अनसुलझे कानूनी टिप्पणीहरु छन्view रखरखाव रिलीज ड्राफ्ट मा, विशिष्टता मालिक BoD एजेन्डा मा समय अनुरोध गर्न सक्नुहुन्छ संकल्प मा BoD इनपुट खोज्न।

कानूनी पुनः संग समानांतर माview, विशिष्टता मालिक पुन: को लागी BARB लाई रखरखाव रिलीज ड्राफ्ट पेश गर्नु पर्छview। एक पटक रखरखाव रिलीज ड्राफ्ट BARB मा पेश गरीएको छ, BSTS ले यसलाई सबै सदस्यहरु को लागी पुन: पहुँचयोग्य बनाउनेछ।view र यसको उपलब्धता को सबै सदस्यहरुलाई सूचित गर्नुहोस्। BARB re को पूरा भएपछिview, विशिष्टता मालिक र BARB मस्यौदा विनिर्देश मा समावेश गर्न को लागी प्रतिक्रिया मा सहमत हुनेछन्।

यदि कानूनी पुनःview कुनै पनि ठोस परिवर्तन, अतिरिक्त पुनः मा परिणामview BARB द्वारा आवश्यक हुन सक्छ। त्यस्तै गरी, यदि BARB पुनःview कुनै पनी आधारभूत परिवर्तन मा परिणाम, BSTS एक अतिरिक्त कानूनी पुन यदि निर्धारित हुनेछview ती परिवर्तनहरु को आवश्यकता छ। कानूनी पुन: पूरा भएपछिview र BARB पुनःview, BARB लाई या त अनुमोदन वा रखरखाव रिलीज ड्राफ्ट अस्वीकार गर्नु पर्छ। यदि BARB द्वारा अनुमोदित, यो भोटिंग ड्राफ्ट बन्छ।

इर्राटा सुधारको लागि जसले परीक्षण कागजातहरूलाई प्रभाव पार्छ, र जहाँ सम्बन्धित टेट इर्राटा आगामी TCRL रिलीजको लागि समयमै प्रशोधन गरिनेछ, BSTS ले निर्दिष्ट कागजातहरू अपडेट गर्न विशिष्टता मालिक र BTI सँग काम गर्नेछ। परीक्षण कागजातहरूको BTI अनुमोदन पछि, BSTS ले Adoption तिथि अनुमान गर्नेछ र TCRL मा प्रयोगको लागि BTI लाई प्रस्तावित Adoption Date प्रदान गर्दछ। BTI TCRL लाई BQRB सँग वितरित गर्दछ सम्बन्धित ICS, IXIT, र परीक्षण सुइट लागूको रूपमा। विनिर्देशको BARB अनुमोदन, सबै परीक्षण कागजातहरूको BTI स्वीकृति (टेस्ट सुइट, TCRL, ICS, र IXIT लागूको रूपमा), र TCRL को BQRB स्वीकृति गोद लिने मितिमा वा अघि आउनुपर्दछ।

बीएसटीएसले मतदान गर्ने मस्यौदा र प्रस्तावित दत्तक मितिको अन्तिमता र उपलब्धताका बारेमा सबै सदस्यहरूलाई जानकारी दिनेछ। दत्तक मिति तोकिने छ र उप सदस्यहरु बमोजिम सबै सदस्यहरुलाई सूचित गरिनेछ र दत्तक दिनांक कम्तिमा १ 14 दिन सम्म सूचना को सुचना दिए पछि हुनेछ। प्रस्तावित दत्तक मिति को सूचना सदस्यहरु लाई प्रदान पछि, BoD प्रस्तावित दत्तक मिति को एक अतिरिक्त सूचना प्रदान नगरी र आवश्यक १ 14 दिन पर्खेर मतदान को मस्यौदामा typographic त्रुटिहरु को सुधार गर्न को लागी मान्यता दिनेछ।

निम्नलिखित कागजातहरू पूरा गर्नुपर्नेछ र BoD मा उपलब्ध गराउनु पर्नेछ गोद लिने मिति भन्दा पहिले:

• मतदान मस्यौदा
• भोटिंग ड्राफ्टको परिवर्तन ट्र्याक गरिएको संस्करणले XX मानको समान स्पेसिफिकेसनको दत्तक संस्करणमा सबै परिवर्तन देखाउँदै (उदाहरणका लागि, यदि मतदान ड्राफ्ट संस्करण १.1.4.2.२ को रूपमा प्रस्ताव गरिएको छ भने, परिवर्तनहरू १.1.4.1.१ को बिरूद्ध ट्र्याक हुनेछन्। विशिष्टताको संस्करण)
• औचित्यको साथ निर्दिष्ट दत्तकको कुनै पनि अघिल्लो संस्करण (हरू) लाई अपनाईएको औचित्यको अवमूल्यन वा फिर्ता लिनको लागि निर्दिष्ट मालिकबाट सिफारिस।
• कानूनी पुनः बाट बाँकी अनसुलझा कानूनी मुद्दाहरु को एक सूचीview (यदि कुनै)
• BTI- अनुमोदित टेस्ट सुइट, ICS, र IXIT (मर्मत रिलीज द्वारा आवश्यक छ भने)
• BTI- र BQRB- अनुमोदित TCRL (मर्मत रिलीज द्वारा आवश्यक छ भने)
• BSTS द्वारा पूरा गरिएको रिपोर्ट BTI सँग उपकरण तयारीको स्थिति (उदाहरणका लागि, PTS र अन्य परीक्षण उपकरणहरू, ब्लुटुथ सुरूवात स्टुडियो) को बारेमा TCRL मा कुनै पनि परीक्षण केसहरू जुन परीक्षण उपकरणहरू द्वारा समर्थित छैन, र विवरण समावेश गर्दछ (यदि मर्मतद्वारा आवश्यक छ भने छोड्नुहोस्)
• BSTS र विशिष्ट मालिक द्वारा पूरा गरीएको एउटा गोद लिइएको चेकलिस्टले देखाउँदै कि यस सेक्सनमा वितरणहरू सबै पूरा भइसकेका छन्।
• सबै अन्य जानकारी BoD द्वारा अनुरोध गरियो

मर्मतसम्भार रिलिज प्रक्रिया पूर्ण हुन्छ जब BoD ले मतदान मस्यौदा स्वीकार गर्दछ र निम्न पछिको गोद लिएका गतिविधिहरू पूर्ण भइसकेका छन्:

• BSTS ले अपनाएको विशिष्टता र सम्बन्धित परीक्षण कागजात (यदि मर्मत सम्भार रिलीज द्वारा आवश्यक छ) ब्लूटूथ SIG मा सार्वजनिक रूपमा उपलब्ध गराईएको छ। webसाइट।
• BSTS ब्लुटुथ SIG मा सबै सदस्यहरु को लागी उपलब्ध नयाँ अपनाईएको संस्करण मा सम्मिलित सबै परिवर्तनहरु संग पहिले अपनाईएको विनिर्देशन संस्करण को एक सूचनात्मक परिवर्तन ट्रैक संस्करण बनाएको छ। webसाइट।
• BSTS योग्यता प्रणाली सक्षम छ।
• BSTS ले सबै सदस्यहरुलाई अपनाईएको विशिष्टता र समर्थन कागजातहरूको उपलब्धताका बारे सूचित गरेको छ।

ब्लुटुथ SIG ले स्पेसिफिकेसनको स्वीकृति पछाडि एक हप्ता भित्र यी पोस्ट-ग्रहण गतिविधिहरू पूरा गर्ने योजना बनायो।

यी गतिविधिहरूको पूर्णतामा, विशिष्टता रखरखाव चरणमा विनिर्देशन रहन्छ जबसम्म विनिर्देशन अस्वीकृत वा फिर्ता लिइदैन, सेक्शन 8 मा परिभाषित गरिए अनुसार।

 

Spec. जीवनको चरणको निर्दिष्टता

विशिष्टताहरू अस्वीकृत हुन वा फिर्ता लिन सकिन्छ जब ती नयाँ संस्करणहरू द्वारा सुपरिडेसन गरिन्छ, प्राविधिक रूपमा अपर्याप्त हुनको लागि निर्धारित, वा अन्य कारणहरूको लागि। निषेध गरिएको र फिर्ता हटाइएको विनिर्देशहरू अभिलेख राखिएका छन् र अब देखि अद्यावधिक छैनन्। निषेध र फिर्ता हटाईएको विनिर्देशहरू ब्लुटुथ योग्यता कार्यक्रममा बिभिन्न तरीकाले व्यवहार गरिन्छ।

कुनै पनि सदस्य, समूह, वा समितिले BSTS लाई सम्बन्धित समयरेखाको साथ एक विशिष्टतालाई अस्वीकृत गर्न वा फिर्ता लिन सिफारिसहरू पेश गर्न सक्दछ (ईमेल मार्फत ईमेल

specification.manager@bluetooth.com) कुनै पनि समयमा। BSTS पनि अवमूल्यन वा एक विशिष्टता र सम्बन्धित समयरेखा को फिर्ता सिफारिस गर्न सक्छ। BSTS सिफारिश BARB र समूह वा समिति को लागी पुनः निर्दिष्ट गर्न को लागी जिम्मेवार समिति लाई बुझाउनेछview र प्रतिक्रिया।

BARB र समूह वा जिम्मेवार समितिले सिफारिसलाई मूल्यह्रास गर्न वा विनिर्देश फिर्ताको फिर्ता मूल्या will्कन गर्दछ र निम्न (गैर-विस्तृत) मापदण्डमा विचार गर्दछ:

• त्यहाँ विनिर्देशको अघिल्लो संस्करणमा कार्यक्षमता छ जुन अप्रचलित हो वा प्रयोग गरिनु हुँदैन?
• के पछि नयाँ संस्करणमा नयाँ अनिवार्य कार्यक्षमता थपिएको छ?
• के त्यहाँ पहिलेका संस्करणहरूमा कमिहरू छन् जुन अपरेसन वा ईन्टरोपेरेबिलिटीलाई बिगार्दछ जुन पछिका संस्करणहरूमा सुधार गरिएको छ र अवस्थित प्रयोगकर्ता परिदृश्यहरूलाई अगाडि बढाउन आवश्यक छ?
• के त्यहाँ नयाँ कार्य परिदृश्यहरू अगाडि बढाउन आवश्यक संस्करणहरूमा अतिरिक्त कार्यक्षमता छ?
• के त्यहाँ पछि संस्करणहरुमा उपयोगिता र अन्तर्क्रियात्मकता सुधारिएको छ?
• त्यहाँ पछिका संस्करणहरूमा सुरक्षा सुधारहरू छन्?

BARB र समूह वा जिम्मेवार समितिले वैकल्पिक सिफारिश प्रस्ताव गर्न सक्छ।

BARB वा समूह वा विनिर्देशन को रखरखाव को लागी जिम्मेवार समिति बाट प्रतिक्रिया प्राप्त गरे पछि, BSTS सिफारिश (हरू) र विचार को लागी BoD लाई प्रतिक्रिया पेश गर्नेछ। BoD ले समूह वा समितिलाई आमन्त्रित गर्न सक्दछ जुन प्रभावित विनिर्देशहरु को रखरखाव को लागी जिम्मेवार छ को लागी सिफारिशहरु लाई भेट्न र छलफल गर्न को लागी। BoD ले सिफारिशहरु र प्रतिक्रिया मा विचार गर्नेछ र प्रस्ताव संग सहमत वा परिमार्जन गर्न सक्छ। बीओडीले अनुरोध गर्दछ कि बीएसटीएसले प्रस्तावका सबै सदस्यहरुलाई ३० दिन को पुनः को लागी स्पेसिफिकेशन (हरू) र सम्बन्धित समयरेखा ह्रास वा फिर्ता लिन को लागी सूचित गर्दछ।view अवधि सबै सदस्यहरु लाई आफ्नो अन्तिम निर्णय गर्नु भन्दा पहिले अतिरिक्त प्रतिक्रिया प्रदान गर्न को लागी अनुमति दिन को लागी।

BoD ले सदस्यहरूबाट प्राप्त प्रतिक्रियालाई विचार गर्नेछ। एक पटक BoD ह्रास वा एक विनिर्देशको फिर्ता फिर्ता स्वीकार गरेपछि, BSTS निर्णय र सम्बन्धित समयरेखा को सबै सदस्यहरु लाई सूचित गर्नेछ।

.8.1.१ गिरावट

एक पटक एक विनिर्देश अवमूल्यन भयो, निम्न देखा पर्नेछ:

• विशिष्टता अब अपडेट हुनेछैन।
• जिम्मेवार WG फेरि हुनेछview बहिष्कृत विनिर्देशन को बिरूद्ध लिखित सबै बकाया इरेटा निर्धारण गर्न को लागी यदि उनीहरु अन्य विनिर्देशहरुमा लागू हुन्छन्। इरेटा इरेटा प्रणालीमा अस्वीकृत हुन सक्छ र लागू स्पेसिफिकेशन (हरू) को बिरूद्ध पुनःलेखन गर्न सकिन्छ।
• WG वा BSTS ले अन्य विशिष्टतामा अस्वीकृत विनिर्देशहरुमा कुनै आवश्यक सन्दर्भ अपडेट गर्न इर्राटा सिर्जना गर्दछ।
• BTI ले विशिष्ट परीक्षणको कागजात अपडेट गर्नेछ विशिष्टताको अवमूल्यन स indicate्केत गर्न।
• BSTS ब्लुटुथ SIG अपडेट हुनेछ webवैकल्पिक विशिष्टता (हरू) को उपयोग गर्न को लागी मार्गदर्शन संग साइट।
• नयाँ एर्राटा अब अस्वीकृत विशिष्टताको बिरूद्ध पेश गर्न सकिदैन।
• भविष्यको कुनै पनि स्पेसिफिकेशन्समा सन्दर्भ निर्दिष्ट गरिदैन।
• BSTS ले विशिष्ट उद्देश्यको संस्करण संग्रहीत गर्दछ ऐतिहासिकका उद्देश्यहरूको लागि पहुँचको लागि सदस्यहरूको लागि अस्वीकृतको रूपमा चिन्हित।

8.2 फिर्ता

एक पटक एक विनिर्देशन फिर्ता लिएपछि, अवमूल्यनको लागि लागू हुने चरणहरूको थपमा, निम्न घट्नेछ:

• BTI ले विशिष्टता कागजात अपडेट गर्नेछ विशिष्टीकरण को फिर्ताको स indicate्केत गर्न।
• BSTS ब्लुटुथ SIG अपडेट हुनेछ webवैकल्पिक विशिष्टता (हरू) को उपयोग गर्न को लागी मार्गदर्शन संग साइट।
• BSTS ले ऐतिहासिक प्रयोजनका लागि पहुँच गर्न सदस्यहरूको लागि फिर्ता लिइएको मार्क गरिएको विनिर्देशको संस्करण संग्रह गर्दछ।

BoD ले विनिर्देशनलाई तुरुन्त फिर्ता लिन छनौट गर्न सक्दछ पहिले विनिर्देशनलाई अवमूल्यन नगरी।

 

White। श्वेत कागज प्रक्रिया

श्वेत पत्रहरु मात्र जानकारी को उद्देश्य को लागी बनाईएको हो। निम्न सेतो कागज प्रक्रिया सबै ब्लुटुथ WGs, EGs, SGs, र समितिहरूमा लागू हुन्छ। यो सेक्सन केवल ब्लुटुथ SIG भित्र प्रयोगको लागि जानकारी कागजातहरूमा लागू हुँदैन।

यो प्रक्रिया तल चित्र 9.1 मा चित्रित छ।

कुनै समूह वा समितिले सेतो कागजमा काम सुरु गर्नु अघि उनीहरू ब्लुटुथ सिग द्वारा प्रकाशित गर्ने मनसायले समूह वा समितिले दुबै प्रस्तावित चार्टर अपडेटलाई स्पष्ट रूपमा सेतो कागजको प्रस्तावित सामग्री र सेतो कागज प्रस्ताव प्रस्तुत गर्ने तयारी गर्नेछ।

सेतो कागज प्रस्ताव प्रस्तुतीकरण कम्तिमा कम्तिमा हुनु पर्छ:

• सेतो कागज को लागी आवश्यकता
• सेतो कागजको प्रस्तावित सामग्रीहरूको सारांश
• सामग्रीलाई विनिर्देशको भागको रूपमा समावेश गर्न सिफारिश नगरिनुको कारणको लागि व्याख्या
• अभिप्रेत दर्शकहरू
• कुनै मर्मतसम्भार योजनाहरू (जस्तै, यस सेतो कागजको अर्को रिलीज हुनु अघि अनुमानित समय आवश्यक हुन सक्छ)
• सेतो कागजको अघिल्लो संस्करणहरू कसरी ह्यान्डल गर्ने सिफारिसहरू, यदि कुनै भए (जस्तै, अभिलेख राख्नुहोस्)

चार्टर अपडेट र श्वेत पत्र प्रस्ताव प्रस्तुति BARB पुनः को लागी पेश गर्नु पर्छview। फेरीview र BARB द्वारा चार्टर अपडेट को अनुमोदन, BSTS समर्थन श्वेत पत्र प्रस्ताव प्रस्तुति संगै अनुमोदन को लागी BoD लाई चार्टर अपडेट पेश गर्नेछ।

यदि BoD ले चार्टर अपडेटलाई अनुमोदन गर्‍यो भने, समूह वा समितिले सेतो कागजको विकासको साथ अघि बढ्न सक्छ।

जब समूह वा समिति श्वेत पत्र को विकास पूरा भयो, BSTS एक सम्पादकीय पुनः प्रदर्शन गर्नेछview ब्लुटुथ मस्यौदा दिशानिर्देश संग संगति को लागी।

BSTS टिप्पणी को संकल्प पछि, समूह कानूनी पुन: को लागी BSTS लाई श्वेत पत्र बुझाउनु पर्छview। कानूनी पुन: पूरा भएपछिview, समूह र BSTS श्वेत पत्र मा समावेश गर्न को लागी प्रतिक्रिया मा सहमत हुनेछन्। यदि त्यहाँ कानूनी पुनः बाट कुनै अनसुलझे कानूनी टिप्पणीहरु छन्view श्वेत पत्र मा, समूह अध्यक्ष BoD एजेन्डा मा समय अनुरोध गर्न सक्नुहुन्छ संकल्प मा BoD इनपुट खोज्न।

कानूनी पुनः संग समानांतर माview, समूह पुन: को लागी BARB लाई श्वेत पत्र बुझाउनु पर्छview। उनीहरुको भाग को रूप माview, BARB ले श्वेत पत्र को कुनै भाग श्वेत पत्र बाट हटाइन्छ र धारा ३ मा प्रक्रिया पछी एक स्पेसिफिकेसन मा समावेश गरीन्छ भनेर सिफारिश गर्न सक्छ।view। BARB re को पूरा भएपछिview, समूह र BARB श्वेत पत्र मा समावेश गर्न को लागी प्रतिक्रिया मा सहमत हुनेछन्।

यदि कानूनी पुनःview कुनै पनि ठोस परिवर्तन, अतिरिक्त पुनः मा परिणामview BARB द्वारा आवश्यक हुन सक्छ। त्यस्तै गरी, यदि BARB पुनःview कुनै पनी आधारभूत परिवर्तन मा परिणाम, BSTS एक अतिरिक्त कानूनी पुन यदि निर्धारित हुनेछview ती परिवर्तनहरु को आवश्यकता छ। कानूनी पुन: पूरा भएपछिview र BARB पुनःview, BARB ले या त अनुमोदन वा श्वेत पत्र अस्वीकार गर्नुपर्छ।

BARB सेतो कागज स्वीकृत गरेपछि BARB- अनुमोदित सेतो कागज अधिकृत समूह वा समिति द्वारा BoD लाई स्वीकृतिका लागि प्रस्तुत गरिनेछ।

सेतो कागज प्रक्रिया पूरा हुन्छ जब BoD ले श्वेत पत्रलाई अनुमोदन गर्‍यो र निम्न पोस्ट-अनुमोदन गतिविधिहरू पूरा भए

• BSTS ले अनुमोदित श्वेतपत्र ब्लुटुथ SIG मा सार्वजनिक रूपमा उपलब्ध गराएको छ webसाइट।
• BSTS स्वीकृत सेतो कागज को सबै सदस्यहरु लाई सूचित गर्दछ।
• यदि सेतो कागज अवस्थित श्वेत कागजको बृद्धि हो भने, BSTS सेता कागजको संस्करण संग्रह गर्दछ सदस्यहरूका लागि ऐतिहासिक उद्देश्यहरूको लागि पहुँच गर्न।

ब्लुटुथ SIG ले सेतो कागजको स्वीकृति पछि एक हप्ता भित्र पोष्ट-स्वीकृति गतिविधिहरू पूरा गर्ने योजना बनायो।

 

10. सन्दर्भहरू

सन्दर्भित ब्लुटुथ कागजात ब्लुटुथ बाट उपलब्ध छन् webसाइट http://www.bluetooth.com.

1. ब्लुटुथ ड्राफ्टिंग दिशानिर्देश (कार्य समूह टेम्पलेट र कागजात पृष्ठमा उपलब्ध, मा https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
2. ब्लुटुथ SIG, Inc का उपविभाजन। (शासित कागजात पृष्ठमा उपलब्ध, मा https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
3. ब्लुटुथ विशिष्टता इराटा प्रक्रिया कागजात (कार्य समूह टेम्पलेट्स र कागजात पृष्ठमा उपलब्ध, मा https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
4. कार्य समूह कार्य कागजात (मा कार्य समूह टेम्पलेट्स र कागजात पृष्ठ मा उपलब्ध, मा https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
5. परीक्षण रणनीति र शब्दावली समाप्तview कागजात (योग्यता परीक्षण आवश्यकताहरु पृष्ठ मा उपलब्ध छ, मा https://www.bluetooth.com/specifications/qualification-test-requirements)
6. BTI विशिष्टता पुनview प्रक्रिया चेकलिस्ट (कार्य समूह टेम्प्लेट र कागजात पृष्ठ मा उपलब्ध छ, मा https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
7. ब्लुटुथ हस्ताक्षर तोकिएको संख्या (https://www.bluetooth.com/specifications/assigned-numbers)
8. वर्किंग ग्रुप टेम्प्लेट र कागजातहरू (वर्किंग समूह टेम्प्लेट र कागजात पृष्ठमा उपलब्ध, मा https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
9. GATT निर्दिष्ट पूरक (GSS) (GATT निर्दिष्ट पृष्ठमा उपलब्ध, मा https://www.bluetooth.com/specifications/gatt)
10. नयाँ विशिष्टताको लागि आईडिया बुझाउनुहोस् https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

 

११ परिवर्णी शब्द र संक्षिप्त नाम

तालिका A: एक्रोनिम र संक्षिप्त नाम

 

परिशिष्ट A - Erratum गंभीरता वर्गीकरण

यो परिशिष्टले विशिष्टता इरेटमको लागि गहन वर्गीकरण दिशानिर्देशहरूको सारांश गर्दछ। यो तालिका EPD को भविष्य संशोधनमा थपिनेछ, र त्यसपछि यो सेक्सन मेटिनेछ।

 

यस म्यानुअल बारे थप पढ्नुहोस् र PDF डाउनलोड गर्नुहोस्:

विशिष्टता व्यवस्थापन प्रक्रिया कागजात (SMPD) - अनुकूलित PDF
विशिष्टता व्यवस्थापन प्रक्रिया कागजात (SMPD) - मूल पीडीएफ

तपाईंको म्यानुअल बारे प्रश्नहरू? कमेन्टमा पोष्ट गर्नुहोस्!

सन्दर्भहरू

• प्रयोगकर्ता पुस्तिका