Documentu di u Processu di Gestione di e Specificazioni (SMPD)

Stu documentu, indipendentemente da u so tittulu o cuntenutu, ùn hè micca una Specificazione Bluetooth sottumessa à e licenze cuncesse da Bluetooth SIG Inc. ("Bluetooth SIG") è i so membri in virtù di l'Accordu di Licenza di Brevettu / Copyright Copyright è Accordu di Licenza di Marca Bluetooth.

QUESTU DOCUMENTU hè FORNITU "CUM'È" E BLUETOOTH SIG, I SUI MEMBRI, È I SUI AFFILIATI FÀ NESSUNA RAPPRESENTAZIONE O GARANZIA E DISCLAIMENU TUTTE E GARANZIE, ESPRESSE O IMPLICITE, INCLUSI QUALSIASI GARANZIA DI MERCANTEBILITÀ, NECESSITÀ, TITLE CH THE U CUNTENU DI STU DOCUMENTU hè LINGUU DI ERRORI.

IN MESURA NON PROHIBITA DA LEGGE, BLUETOOTH SIG, I SUI MEMBRI, E LORI AFFILIATI DISCLAIM TUTTA A RESPONSABILITÀ SURGENTE DI O RELATIVA ALL'USO DI QUESTU DOCUMENTU E QUALSIASI INFORMAZIONE CONTENUTE IN QUESTU DOCUMENTU, INCLUSIVAMENTE I DATI INFRUTTI INTERRUZZIONE, O PER DANNI SPECIALI, INDIRETTI, CONSECUENTI, INCIDENTALI O PUNITIVI, MA CAUSATI E INDIPENDENTI DI A TEORIA DI A RESPONSABILITÀ, E ANCHE SI BLUETOOTH SIG, I SUI MEMBRI, O I SUI AFFILIATI HANNU ESSU CONSIGLIATI DI I POSSIBILITÀ.

Stu documentu hè pruprietariu di Bluetooth SIG. Stu documentu pò cuntene o copre sughjetti chì sò pruprietà intellettuale di Bluetooth SIG è di i so membri. U furnimentu di stu documentu ùn dà alcuna licenza à alcuna pruprietà intellettuale di Bluetooth SIG o di i so membri.

Stu documentu hè sottumessu à cambià senza avvisu.

1. Introduzione

U Documentu di Processu di Gestione di Specificazioni (SMPD) descrive i prucessi chì l'autori di specificazione è riviewI prufessiunali anu da seguità per sviluppà novi specificazioni è per rinfurzà e specificazioni esistenti (vale à dì, per aghjunghje o caccià funziunalità o per cambià a funziunalità specifica in una specificazione aduttata), per mantene e specificazioni aduttate, è per gestisce a fine di a vita di e specificazioni aduttate. Inoltre, stu documentu descrive u prucessu di creazione, reviewing, è appruvà i libri bianchi.

Ci sò differenze in u prucessu di sviluppu di e specificazioni trà u sviluppu di nuove specifiche è u miglioramentu di e specifiche esistenti per via di e differenze inerenti in a portata di questi compiti; quelle differenze sò messe in evidenza in stu documentu.

U prucessu di sviluppu di e specificazioni include:

Una Fase di Requisiti (descritta in a Sezione 3) per definisce e esigenze funzionali
Una Fase di Sviluppu (descritta in a Sezione 4) per sviluppà è riview specificazioni

Una Fase di Validazione (descritta in a Sezione 5) per validà e specifiche per mezu di test di Prototipu Interoperabile (IOP)
Una Fase di Adozione / Approvazione (descritta in a Sezione 6) per presentà e specifiche à u Cunsigliu di Amministrazione di Bluetooth SIG (BoD) per adozione / approvazione

U ducumentu di u Processu di Errata Specificazione (EPD) [3] descrive u prucessu di pruposta è riviewl'errata di specificazione, è l'appruvà cum'è Correzioni di Errata (cum'è definitu in i Statuti [2]) à e specificazioni aduttate. À moins qu'il ne soit précisé autrement, toutes les références à errata dans cette SMPD signifient errata de spécification.

1.1 Precedenza

I Statuti di Bluetooth SIG, Inc. (Statuti) è l'accordi d'appartenenza [2] piglianu a suprana annantu à qualsiasi cuntenutu cuntrastanti in quelli ducumenti è u SMPD. Malgradu qualcosa in questu documentu, u Cd mantiene a discrezione è l'autorità ultime per agisce è piglià decisioni ancu se quelle azzioni è decisioni ùn seguitanu micca, o sò in conflittu cù qualcosa in stu documentu, è nunda in questu documentu limita o limita l'autorità indipendente di u Cd è discrezione.

Se ci sò cunflitti trà u testu in u SMPD è e figure, u testu hà a precedenza.

1.2 Gruppi è cumitati riferiti

I seguenti tipi di gruppi sò riferiti in stu documentu: Gruppi di Studiu (SG), Gruppi d'Esperti (EG) è Gruppi di Travagliu (WG). Un WG pò ancu avè un sottogruppu chì rende rapportu à u WG. In listessu modu, i seguenti tipi di cumitati sò riferiti in stu documentu: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI), è Bluetooth Qualification Review Cunsigliu (BQRB). Stu documentu si riferisce ancu à u Staff Tecnicu Bluetooth SIG (BSTS), è u BoD.

1.3 Cumitatu riviews è appruvazioni

Un cumitatu riview hè un review chì hè realizatu da i membri di un cumitatu (tipicamenti 3 membri) per furnisce feedback in un tempu specificu (tipicamenti 2-3 settimane), in ogni modu u review U tempu pò varià secondu a durata è a cumplessità di u materiale è altre priorità in u cumitatu. U gruppu chì dumanda u review è u cumitatu chì conduce u review ognunu accunsentì nantu à a durata di u review. U gruppu è i membri di u cumitatu utilizanu l'arnesi Bluetooth SIG per notificà è arregistrà l'iniziu è a fine di u review. U gruppu in generale processerà i feedback di u cumitatu quandu hè ricevutu. Quandu u cumitatu riview u tempu scade, u gruppu finisci di affruntà i feedback di u cumitatu, è deve ancu cunsiderà ogni ritardatu chì arriva.view feedback tenendu in mente chì u materiale pò esse sottumessu à l'appruvazioni sussegwenti da u cumitatu.

Un’approvazione di u cumitatu hè ottenuta da un votu di i membri di u cumitatu in cunfurmità cù u Documentu di Prucessu di u Gruppu di travagliu [4].

1.4 Avvisi à i membri è accessibilità di i materiali

Tutti l'avvisi furniti à i membri secondu stu documentu ponu esse furniti per e-mail, cume un aggiornamentu tecnicu periodicu. Notificazioni chì devenu esse furnite à tutti i membri seranu inviate à tutti i membri attivi (vale à dì, induve l'abbonamentu ùn hè micca statu suspesu, terminatu o ritiratu). Quandu e notificazioni sò inviate per email, seranu inviate à l'ultimu indirizzu email cunnisciutu (cum'è si riflette in i registri allora attuali di Bluetooth SIG) di ogni individuu chì si hè registratu sottu à u cuntu di appartenenza di a cumpagnia membru è chì ùn hà micca sceltu di riceve notifiche per email. Nunda in questu documentu ùn altera l'obbligazioni o i requisiti di Bluetooth SIG in quantu à a prestazione di avvisu in virtù di i Statuti o qualsiasi altru accordu trà Bluetooth SIG è qualsiasi membru.

In ogni casu chì stu documentu si riferisce à a websitu chì hè accessibile per tutti i membri, questu si riferisce à l'accessibilità à e persone chì anu un contu Bluetooth SIG attivu. I membri chì ùn anu micca un contu attivu ponu creà un contu via u Bluetooth SIG websitu.

1.5 Modelli

Per ogni tipu di documentu (per esempiu, specificazioni, libri bianchi, documenti di prova) riferiti in questu SMPD, Bluetooth SIG furnisce un mudellu. U mudellu deve esse usatu cum'è una basa per ogni documentu pruduttu in cunfurmità cù stu SMPD. A mancata aduprata di u mudellu currettu pò esse u risultatu chì u documentu ùn hè micca appruvatu. I mudelli sò dispunibili nantu à u Bluetooth SIG websitu [8].

1.6 Tipi di specificazione

Ci sò parechji tippi di specificazioni Bluetooth SIG. Gerarchicamente, tutte e specificazioni dipendenu da a Specifica Core Bluetooth. Specificazioni cum'è tradiziunale profiles; protocols tradiziunali; è GATT-based profiles, servizii basati in GATT, è protokolli basati in GATT dipendenu tutti da e caratteristiche in a Specificazione Core. Altre specificazioni, cum'è e specificazioni di Mesh Model, dependenu di Mesh Profile specificazione chì à u turnu dipende da a Specificazione Core.

A specificazione Core Specification Supplement (CSS) definisce tippi di dati, formati di dati è pro cumunifile è i codici d'errore di serviziu chì sò utilizati da a Specificazione Core è altre specificazioni è ùn definisce micca ellu stessu cumpurtamenti.

A specificazione GATT Specification Supplement (GSS) definisce i formati di caratteristiche è descrittori chì sò utilizati da Pro.files è Servizi è ùn definisce micca ellu stessu cumpurtamenti.
A specificazione Mesh Device Properties (MDP) definisce e proprietà di mesh aduprate da Mesh Profile è specificazioni Mesh Model è ùn definisce micca ellu stessu cumpurtamenti.

2. Sopraview

Questa sezione furnisce un sopraview di i prucessi è ùn hè micca destinatu à include tutti i dettagli.

A Figura 2.1 mostra e sei fasi principali chì custituiscenu u Processu di Gestione di e Specifiche.

E prime quattru fasi si verificanu durante u prucessu di sviluppu di e specificazioni è consistenu in a Fase di Requisiti (Sezione 3), a Fase di Sviluppu (Sezione 4), a Fase di Validazione (Sezione 5), è a Fase di Adozione / Approvazione (Sezione 6). Questu hè seguitu da duie fasi post-adozione: a Fase di Manutenzione di e Specifiche (Sezione 7) è a Fase di Specificazione Finale di Vita (Sezione 8).

A Figura 2.2 illustra i dettagli di e quattru fasi in u prucessu di sviluppu di e specificazioni. I scatuli grisgi indicanu i risultati principali per ogni fase. I scatuli aranci riassumenu e tappe di u prucessu.

In a Fase di Requisiti (descritta in a Sezione 3), una pruposta per inizià un novu travagliu (una Nova Proposta di travagliu (NWP)) inizia u prucessu di sviluppu di specificazioni definendu i scenarii di l'utente da abilità se u novu travagliu procede. Se u NWP hè appruvatu, un gruppu assignatu crea un Documentu di Requisiti Funziunali (FRD). Una volta chì u FRD hè appruvatu è assignatu à un gruppu, inizia a Fase di Sviluppu.

Duranti a Fase di Sviluppu (discrittu in a Sezione 4), u sviluppu di specificazioni avanza per una sequenza di s.tages (0.5/DIPD à 0.9/CR) culminendu in un abbozzu cumpletu di a specificazione. A specificazione 0.9/CR hè dispunibule per tutti i membri, dopu sottumessa à u BoD chì cunsidereghja a specificazione per appruvazioni. Una volta appruvata, a Fase di Validazione principia.

Durante a Fase di Validazione di u sviluppu di specificazione (descritta in a Sezione 5), a specificazione 0.9/CR appruvata da u BoD hè dispunibule per tutti i membri per riview è cunvalidà, è Member Review hè principiatu. A validazione hè realizata per mezu di teste di interoperabilità (IOP) trà i prototipi chì sò custruiti da i membri. Una volta chì a prova IOP hè finita (se necessariu per a specificazione) è BARB appruva u rapportu di prova IOP, allora a Fase di Adopzione / Approvazione principia.

Durante a Fase di Adozione / Approvazione (descritta in a Sezione 6), a specificazione è i documenti di prova cunnessi sò finalizzati; Appruvazioni BARB, BQRB è BTI sò ricevute; è u pacchettu di specificazione finale hè sottumessu à u BoD chì considera a specificazione per adozione (vale à dì, appruvazione finale).

Una specificazione pò avè bisognu di vultà à una fase precedente o stage se sò fatti cambiamenti significativi. In certi casi, pò ancu esse pussibule rinunzià una parte di una fase cum'è descritta in a Sezione 4.4.

A Fase di Manutenzione di e Specifiche (descritta in a Sezione 7) inizia dopu chì una specifica sia aduttata da u BoD. Durante sta fasa i putenziali errori truvati in una specificazione aduttata sò segnalati è valutati, è (se necessariu) Errata Correzioni sò fatte à a specificazione. A Fase di Manutenzione di e Specificazioni cuntinua finu à chì l'ispecificazione sia obsoleta o ritirata (vede Fase di Specificazione Finale di Vita in u paràgrafu chì seguita).

A Fase di Speculazione Finale di Vita (descritta in a Sezione 8) descrive u prucessu per deprecà è ritirà e specifiche adottate.

3. Fase di Requisiti

A Fase di Requisiti principia sia cù un NWP (chì dice u desideriu di iniziare u travagliu nantu à unu o più scenarii di l'utente) o dopu una determinazione chì u novu travagliu desideratu sia dighjà coperto da a so carta WG. Se un GT vole principià un novu travagliu chì crede hè digià in u scopu di a so carta WG, u GT deve seguità u prucessu definitu in a Sezione 3.1 per procedere direttamente à sviluppà un FRD. Per tutti l'altri elementi di travagliu, u WG deve seguità u prucessu definitu in a Sezione 3.2. U FRD definisce a portata di i requisiti funzionali chì sò aduprati per custruisce specifiche in a Fase di Sviluppu. A fase di Requisiti hè illustrata in Figura 3.1.

3.1 Novu travagliu cupartu da una cartula WG

Quandu un WG vole inizià un novu travagliu è crede ragionevolmente chì a funzionalità ch'ellu vole aghjunghje hè dighjà in u scopu di a so cartula WG, u WG pò cumincià à travaglià nantu à u FRD, a condizione chì avvisanu immediatamente BARB. U WG includerà in a so notificazione à BARB una descrizzione di u novu travagliu prupostu è una copia di a carta WG cù a lingua evidenziata chì li autorizza à inizià u novu travagliu.

Se BARB rifiuta l'analisi di u WG, u WG deve piantà u travagliu nantu à u FRD è procedere cù u prucessu NWP spiegatu in a Sezione 3.2. Se BARB approva l'analisi di u WG, u WG avverà immediatamente à BSTS (per email à specification.manager@bluetooth.com) è BSTS aghjunghjerà l'articulu à a prossima agenda di BoD.

U WG includerà in a so notificazione à BSTS a stessa infurmazione chì hà furnitu à BARB. Se u BoD rifiuta l'analisi di u WG, u WG deve piantà u travagliu nantu à u FRD è procedere cù u prucessu NWP spiegatu in a Sezione 3.2. Se u BoD approva l'analisi di u WG, u WG pò continuà à travaglià nantu à u FRD cum'è spiegatu in a Sezione 3.3.

3.2 Nova Proposta di travagliu (NWP)

Ogni membru, WG, SG, o EG pò creà è mandà un NWP (via u SIG Bluetooth websitu [10]). Un NWP deve include, à u minimu, infurmazioni nantu à i seguenti utilizendu u mudellu ufficiale furnitu in [8]:

Scenarii d'utilizatori
Impegnu di i membri per sviluppà u FRD è in quale area (s) (per esempiu, Contributore, Autore, Reviewer, prototipu)

Cunsigliu prupostu di u travagliu FRD
Assignazione di gruppu pruposta per u travagliu FRD
Indirizzu email di l'autori principali

Nota: A guida nantu à u prucessu NWP hè dispunibule nantu à u Bluetooth SIG websitu [10].

BSTS eseguirà e seguenti attività durante u sviluppu di u NWP:

Fornite à l'autori (s) una ricunniscenza di ricezione (tipicamente entro sette ghjorni di calendariu da a ricezione) è descrive i prossimi passi.

Se necessariu, travaglià cù l'autori (s) per chì u NWP sia chjaru è cumpletu. Questu pò richiede parechje iterazioni di u NWP.
Se u NWP cuntene dichjarazioni nantu à l'errori in e specificazioni Bluetooth aduttatu, travaglià cù l'autore (s). file entrate in u sistema errata.
S'ellu hè rimarcatu chì u NWP duplica potenzialmente travagli chì sò dighjà in corsu o chì sò dighjà compii, avvisate l'autori (i) di l'altru travagliu per a so valutazione.

Postu u NWP à u NWP websitu accessibile à tutti i membri.
Avvisate à tutti i membri chì u NWP hè dispunibule per review è se l'impegnu supplementu di i membri per sviluppà u FRD hè necessariu.

I membri ponu cuntattà l'autore (i) per dumandà dumande o per furnisce feedback in quantu à u NWP.

Almenu trè cumpagnie membri devenu impegnassi à participà à a cumpletazione di u FRD resultante per u NWP per diventà un candidatu per l'approvazione di u BoD, è almenu una sucietà membru deve esse un membru Assuciatu o Promotore. Dopu l'approvazione di u BoD di u NWP, u BoD assignerà u NWP à un sottogruppu WG esistente di tutti i membri o SG per travaglià nantu à u FRD (descrittu in a Sezione 3.3). Se un sottugruppu WG o SG adattu ùn esiste micca, unu pò esse creatu.

Per i PWN chì anu un impegnu sufficiente per i membri, BSTS eseguirà e seguenti attività addiziunali:

Almenu 13 ghjorni prima chì u NWP sia prupostu per esse appruvatu da u BoD, avvisate BARB, è u gruppu à u quale u NWP hè raccomandatu per l'assegnazione, di l'approvazione NWP in attesa. Questu hè fattu per furnisce una occasione di feedback in settori cum'è u gruppu prupostu, sì u NWP sia dighjà cupertu da travagli esistenti, ecc.

Invia u NWP cumpletatu à u BoD.

Se u NWP hè sottumessu da membri chì ùn sò micca associati à un gruppu, organizate per unu di i membri di presentà u NWP à u BoD.
Se u NWP hè sottumessu da un gruppu, organizate per a presidenza di u gruppu per presentà u NWP à u BoD.

Invite u presidente BARB è i presidenti di u gruppu, à quale u NWP hè cunsigliatu per assignazione, à a riunione di u BoD.
Se u NWP hè appruvatu è assignatu da u BoD, avvisate u gruppu chì era assignatu; l'autore (i); i membri identificati in u NWP cum'è impegnati à sviluppà FRD currispondenti; è se u NWP hè prupostu da un gruppu, u gruppu di u risultatu è i prossimi passi.

Dopu chì un NWP hè appruvatu da u BoD, aghjurnà u statutu nantu à u NWP websitu.

Ogni NWP pò esse rifiutatu da u BoD à a so discrezione, per esempiuample, a causa di limitazioni di risorsa, s'è u travagliu hè digià cumpleta cumplettamente, u travagliu hè fora di u scopu di i ducumenti rigulari di Bluetooth SIG (per esempiu, u Applicazioni Programming Interface (API)) [2], o s'è u travagliu pruposta deve esse filed cum'è un erratum. Se u NWP hè rifiutatu, BSTS hà da avvisà l'autori, i membri identificati in u NWP cum'è impegnati à sviluppà u FRD currispundente, è, se u NWP hè prupostu da un gruppu, u gruppu. A notificazione includerà qualsiasi motivi per u rifiutu. L'autori, i membri impegnati, o u gruppu ponu dumandà u tempu nantu à l'agenda di u BoD per appellu u rifiutu.

Se un membru o gruppu vole prupone di rimuovere una caratteristica da una specificazione adottata, u gruppu o membru deve preparà un NWP. U NWP deve cuntene una analisi di l'impattu chì a rimozione averà nantu à a compatibilità retroattiva è l'interoperabilità, cumprendu una analisi di l'impattu nantu à i casi di prova.

I NWP ùn sò micca richiesti per i miglioramenti à e specifiche CSS, GSS, o MDP: tipicamente, l'aggiornamenti à e specifiche CSS, GSS o MDP risultanu da l'aggiornamenti di altre specificazioni chì anu i so propri NWP.

3.3 Documentu di Requisiti Funzionali (FRD)

I FRD definiscenu i requisiti funzionali per abilità i scenarii di l'utente. Un FRD deve cuntene, à u minimu, infurmazione nantu à e seguenti aduprendu u mudellu ufficiale furnitu in [8]:

Scenarii d'utilizatori
Requisiti funzionali basati nantu à i scenarii di l'utente

Impegnu di i membri per sviluppà e specificazioni resultanti
Supportu prototipu opzionale da i membri per i roli previsti
WG raccomandatu per sviluppà e specificazioni resultanti

Sviluppu FRD

I FRD sò creati da u sottugruppu WG assignatu à tutti i membri o da i membri SG cun supportu editoriale da BSTS. Ogni membru interessatu à participà à u sviluppu FRD pò aderisce à u gruppu.

I FRD devenu indicà un impegnu da almenu dui (ancu se trè sò incuraghjiti) Cumpagnie membre di livellu Associate o Promotore per participà à u sviluppu di a specificazione resultante. I GT o SG chì presentanu un FRD duveranu pruvà à ottene un ampiu sustegnu da e cumpagnie membre di u gruppu chì rapprisentanu u segmentu di l'industria target destinatu identificatu in u FRD.

A nova funziunalità chì hè pruposta in un FRD deve esse supportable in quant'è tanti trasporti è dispusitivi esistenti pussibule. Questu include, per esample, sustegnu GATT-based profiles è servizii sia nantu à u trasportu di a tarifa di basa / tariffa di dati estesa (BR / EDR) è u trasportu di u Bluetooth Low Energy (LE). Se a nova funziunalità ùn manca un supportu di membru suffirenziu per un trasportu, per esempiuampA causa di una mancanza di impegnu di i membri per definisce l'usu di u trasportu o un numeru potenzalmentu insufficiente di piattaforme di teste IOP per unu o più roli, u supportu in quellu trasportu pò esse esclusu da u FRD.

A menu chì altrimenti ghjustificatu, nova funziunalità, profiles, è servizii deve esse cumpatibili cù i requisiti di cumpatibilità backward discrittu in Section 3.3.2.

U WG o SG deve mandà u FRD à BARB per review è appruvazioni. BARB deve appruvà o rifiutà u FRD basatu annantu à u so ghjudiziu ingegneria. Se appruvatu da BARB, u FRD serà dispunibule per tutti i membri è a notificazione di a so dispunibilità serà emessa da BSTS.

I FRD ùn sò micca richiesti per i miglioramenti à e specifiche CSS, GSS, o MDP: tipicamente, l'aggiornamenti à e specifiche CSS, GSS, o MDP risultanu da l'aggiornamenti di altre specificazioni chì anu i so propri FRD.

Requisiti di cumpatibilità retroattiva

Compatibilità retroattiva per BR / EDR

Per l'operazione BR / EDR, u requisitu di compatibilità retroattiva hè definitu cum'è interoperazione cù a parte BR / EDR di a Specificazione Core Bluetooth v1.1 è più tardi.

Compatibilità retroattiva per Bluetooth Low Energy

Per l'operazione LE, u requisitu di compatibilità retroattiva hè definitu cum'è interoperazione cù a parte LE di a Specificazione Core Bluetooth v4.0 è più tardi.

Compatibilità retroattiva per specifiche diverse da a Specificazione Core

Per specificazioni diverse da a Specifica Core Bluetooth, a cumpatibilità retrocede di una versione data deve esse mantinuta cù tutte e versioni precedenti chì anu u listessu numeru di versione maiò. Per example, a versione 1.3 deve esse cumpatibile cù e versioni 1.2, 1.1 è 1.0, ma a versione 2.0 puderia micca esse cumpatibile cù e versioni 1.0, 1.1, 1.2 è 1.3. Nota chì un incrementu à u numeru di versione maiò di a Specifica Core ùn implica micca una mancanza di cumpatibilità retrocede cù e versioni precedenti.

Esenzione da i requisiti di compatibilità retroattiva

U WG o SG pò prupone l'esenzione di funziunalità specifica da u requisitu di cumpatibilità retrocede se a ghjustificazione hè furnita. Per example, s'è a funziunalità hè dimustratu à avè tassi d'adopzione di u mercatu o, per via di prublemi di interoperabilità, hè megliu per sguassà o rimpiazzà e funziunalità chì per mudificà e funziunalità. U WG o SG deve include qualsiasi esenzioni di cumpatibilità retroattiva in u FRD, chì sò appruvati da BARB dopu l'appruvazioni di u FRD. Ogni esenzione approvata da BARB serà presentata à u BoD per appruvazioni à u 0.9/CR Stage.

3.4 Cartula di u Gruppu di travagliu

Quandu BARB approva un FRD chì si propone di esse assignatu à un WG esistente, quellu WG deve preparà un abbozzu d'aghjurnamentu à a so cartula per aghjunghje a nova funzionalità à l'ambitu (a menu chì u BoD abbia appruvatu prima l'analisi di u WG chì un aggiornamentu di a carta di WG hè micca necessariu). Tuttavia, quandu BARB approva un FRD chì si propone di esse attribuitu à un novu WG, BARB è i membri chì sò interessati à sviluppà a funzionalità descritta in u FRD devenu preparà una bozza di carta per un novu WG cù a nova funzionalità inclusa in u scopu di a carta .

Una volta chì a carta WG nova o aghjurnata hè preparata, deve esse presentata à BARB per riview è appruvazioni. Una volta chì BARB appruva a carta, u prugettu di a carta di WG nova o aghjurnata serà sottumessu à u BoD per appruvazioni.

Una volta chì u BoD approva a cartula, u WG à u quale u travagliu di sviluppu di e specificazioni hè statu assignatu da u BoD deve travaglià strettamente cù u gruppu chì hà preparatu u FRD in casu d'aghjurnamenti o chiarimenti necessarii à quellu FRD sò richiesti. Se un aghjurnamentu FRD hè necessariu durante a Fase di Sviluppu, i prucessi descritti in a Sezione 3.3 è sta sezzione devenu esse seguitati; in ogni modu, u sviluppu di specificazioni pò esse in parallelu cù l'aghjurnamenti di a carta FRD è WG.

3.5 Requisiti Esigenze di uscita di fase

A Fase di Requisiti hè cumpleta è a Fase di Sviluppu principia quandu una cartula WG cun scopu necessariu per u FRD hè cunfirmata o appruvata da u BoD è i seguenti requisiti sò stati soddisfatti:

U NWP hè statu o appruvatu da u BoD, o u BoD hà accettatu chì un NWP ùn hè micca necessariu.

U FRD è a cartula WG currispundente sò state appruvate da BARB.

4. Fase di sviluppu

Durante a Fase di Sviluppu, i WG (s) assignati creanu a nova specificazione è / o miglioranu una specificazione esistente. U FRD definisce i requisiti di a nova o migliorata specificazione Bluetooth. Nisuna funzionalità hè permessa in a specificazione chì ùn hè micca ragionevolmente ligata à i requisiti in u FRD. L'ughjettivu hè di creà una specificazione 0.9 / CR chì sia pronta per a Fase di Validazione (descritta in a Sezione 5) à a conclusione di a Fase di Sviluppu.
Durante a Fase di Sviluppu, una specificazione (o rinforzamentu di specificazione) avanza per trè stages.

Per una nova specificazione, i trè stagsò sò:

0.5 Stage
0.7 Stage

0.9 Stage

Per un miglioramentu di specificazione, i trè stagsò sò:

Draft Improvement Proposal Document (DIPD) Stage

Documentu di Pruposta Finale di Migliura (FIPD) Stage
Richiesta di cambiamentu (CR) Stage

Ogni stage hè descritta in più in i subsezzioni chì seguitanu. La figure 4.1 ci-dessous illustre les divers documents que le GT préparera à chaque stage.

Figura 4.1: Overview di a specificazione stages chì accade durante a Fase di Sviluppu

U rolu di BARB in tuttu u prucessu di sviluppu di e specifiche hè di furnisce à i GT cunsiglii è assistenza tecnica. I GT ponu, in ogni mumentu, fà richieste à BARB per cunsiglii tecnichi in quantu à u sviluppu di e specifiche è cuncetti architettonici da aduprà in una specifica. I WG sò particularmente incuraghjiti à dumandà i primi feedback da BARB per caratteristiche chì anu cunsiderazioni architettoniche più cumplesse.

4.1 0.5/DIPD Stage

Durante u 0.5/DIPD Stage, u WG svilupperà i seguenti utilizendu i mudelli ufficiali furniti in [8]:

Per una nova specificazione, un prugettu di a specifica 0.5, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:

Architettura per copre i requisiti cum'è dichjaratu in u FRD

Per i protocolli, i punti di accessu di serviziu definiti
Per i servizii, dati esposti è cumpurtamentu
Per profiles, protokolli identificati è funziunalità specificatu

2. Per un rinfurzamentu di e specificazioni, un prugettu di u DIPD, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:

Sfondate: U scopu di u travagliu, l'ubbiettivi chì guidanu u travagliu, è cume sta proposta specifica si adatta à u scopu
Overview di pruposta: Un riassuntu di a funzionalità estesa (flessibilità aghjunta, prestazioni migliorate, ecc.) Furnita da u DIPD cumprese una descrizzione chjara in quantu à chì a nova funzionalità si adatta à a versione specifica attuale. Se u WG hà valutatu parechje proposte, queste proposte devenu esse incluse per permettere à BARB l'occasione di determinà se una diligenza dovuta sufficiente hè stata fatta in a selezzione di a proposta preferita.

Copertura di i requisiti: Un riassuntu di a copertura di i requisiti funzionali data da a proposta, in riferimentu à i requisiti di sistema adatti è i scenarii d'usu dati in u FRD assuciatu
Definizione di u prublema: Una dichjarazione di prublemi risolti da a pruposta (e)
Critères de sélection : Una dichjarazione riguardu à i criteri di selezzione / prestazione da metriche di valutazione associate chì anu guidatu u prucessu di selezzione

Ghjustificazione di scelta: Un esame di e metriche di valutazione chì ghjustificheghjanu a scelta trà e pruposte è palesanu i cumerci
Descrizzione: Una descrizzione di a funzionalità è protokolli estesi. Questa sezzione pò adattà à e diverse necessità aghjunghjendu sottusezioni pertinenti.

3. Strategia di prova: Una descrizzione di e funziunalità pruposta per esse pruvata (o micca pruvata) cum'è parte di u Prugramma di Qualificazione Bluetooth è cumu a funziunalità hè pruposta per esse pruvata (per esempiu, aspettative nantu à u Tester Inferiore o Tester Superiore), è se i testi seranu attribuiti cum'è testi di cunformità o di interoperabilità o una cumminazione di i dui). Questu pò esse in un documentu separatu o una sezione separata in a specificazione 0.5/DIPD. E cunvenzioni per esse aduprate in una Strategia di Testa sò descritte in a Strategia di Test è Terminologia Overview document (TSTO) [5].

U publicu primariu di i documenti in questu stage hè i membri di u GT è BARB chì review i pruposti architecturale è a cobertura di esigenze, è BTI chì riviews a strategia di prova. In a maiò parte di i casi, i ducumenti à questu stage ùn sò micca destinati à cuntene un testu chì hè previstu per l'inclusione in a specificazione finale.

BSTS deve ritruvàview tutti i ducumenti per a coerenza cù e Linee di Redazione Bluetooth [1] è identificanu i prublemi per u WG per trattà. BARB deve riview a specificazione 0.5/DIPD. Per un migliuramentu di specificazione, BARB deve ancu review u DIPD per u rispettu di i requisiti di cumpatibilità retrocede descritti in a Sezione 3.3.2. BTI deve riview a strategia di prova.

BARB deve appruvà o rifiutà a specificazione 0.5/DIPD basatu annantu à u so ghjudiziu ingegneria. Sè appruvata da BARB, a specificazione 0.5/DIPD serà dispunibule nantu à u Bluetooth SIG webu situ à tutti i membri Associati è Promotori è a notificazione di a so dispunibilità serà emessa da BSTS. À u 0.5/DIPD Stage, l'appruvazioni di a Strategia di Test ùn hè micca necessariu.
U 0.5/DIPD Stage ùn hè micca necessariu per migliurà à e specificazioni CSS, GSS o MDP

0.5/DIPD Stage esigenze di uscita

U 0.5/DIPD Stage hè cumpletu è u 0.7/FIPD Stage principia quandu i seguenti requisiti di uscita sò soddisfatti:

BSTS hà cumpletu riviewin a specificazione 0.5/DIPD è a Strategia di Test.

BARB hà appruvatu a specificazione 0.5 / DIPD.
BTI hà finitu u so review di a strategia di prova.
BSTS hà messu a specifica 0.5 / DIPD appruvata à dispusizione di tutti i membri Associati è Promotori.

4.2 0.7/FIPD Stage

Durante u 0.7/FIPD Stage, u WG svilupperà i seguenti utilizendu i mudelli ufficiali furniti in [8]:

Per una nova specificazione, un prugettu di a specifica 0.7, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:

Una descrizzione di tutti i cambiamenti chì sò stati fatti da u BARB-appruvatu 0.5, cumprese pruposte novi o mudificate, criteri di selezzione è ghjustificazione di scelta. I cambiamenti devenu esse descritti à u listessu livellu di dettagliu cum'è necessariu in u 0.5 Stage.

Tutti i requisiti funzionali da u FRD indirizzati.

2. Per un rinfurzamentu di e specificazioni, un prugettu di u FIPD, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:

Una descrizzione di tutti i cambiamenti chì sò stati fatti da u DIPD appruvatu da BARB, cumprese pruposte novi o modificate, criteri di selezzione è ghjustificazione di scelta. I cambiamenti devenu esse descritti à u listessu livellu di dettagliu cum'è necessariu in u DIPD Stage.

Cumu necessariu, spazii sviluppati in più chì sò stati descritti in a Sezione 4.1 in quantu à u DIPD.
Una descrizzione cumpleta di u miglioramentu.
Una descrizione architettonica aggiornata.
Tutti i requisiti funzionali da u FRD indirizzati.

3. Documenti di prova 0.7 / FIPD, chì devenu cuntene, à u minimu, informazioni nantu à i seguenti:

Un Test Suite, custituitu da un elencu di Prughjetti Pruvisti cumu descrittu in u TSTO [5].
Una dichjarazione di conformità à l'implementazione (ICS), cum'è descritta in u TSTO [5].

Per i miglioramenti di specificazioni, u Test Suite è ICS ponu esse furniti sia cum'è documenti separati sia cum'è sezioni addiziunali in u FIPD.

U publicu primariu di i ducumenti pruduciuti à questu stage hè i membri di u GT è BARB chì review a descrizzione cumpleta di a funzione o a migliione cumpresu qualchì testu previstu per l'inclusione in a specificazione finale. BTI hè u publicu per review di i documenti di prova.

BSTS tornaview e parti novi o cambiate di a specificazione 0.7 / FIPD è i ducumenti di teste per a coerenza cù e Linee di Redazione di Bluetooth, cumprese e cunvenzioni di lingua stabilite da Bluetooth SIG. BARB tornaview a specificazione 0.7/FIPD.

BSTS aiutarà u WG à preparà i documenti di prova 0.7 / FIPD in cunfurmità cù u TSTO [5].

BTI deve riview i documenti di prova 0.7/FIPD. U WG deve furnisce a specificazione 0.7/FIPD à BTI cum'è riferimentu quandu reviewin i ducumenti di prova 0.7/FIPD, chì BTI ritruveràview in cunfurmità cù a Specifica BTI Review Lista di cuntrollu di u prucessu [6].

Dopu chì BARB hà finitu u so review di a specificazione 0.7/FIPD è BTI hà cumpletu u so review di i documenti di prova 0.7/FIPD, BSTS farà u reviewed 0.7/FIPD specificazione dispunibule per tutti i membri Associati è Promotori.

U 0.7/FIPD Stage ùn hè micca necessariu per migliurà a specificazioni CSS, GSS o MDP.

0.7/FIPD Stage esigenze di uscita

U 0.7/FIPD Stage hè cumpletu è u 0.9/CR Stage principia quandu i seguenti requisiti di uscita sò soddisfatti:

BSTS hà cumpletu riviewin a specificazione 0.7/FIPD è i documenti di prova.
BARB hà finitu riviewcù a specificazione 0.7/FIPD.
BTI hà cumpletu review0.7/FIPD Test Suite (Test Purposes) è 0.7/FIPD ICS.
BSTS hà fattu u reviewed 0.7/FIPD specificazione dispunibule per tutti i membri Associati è Promotori.

4.3 0.9/CR Stage

Ci hè dui tippi di CR: Un CR Integratu, chì hè un documentu traccia di cambiamentu di una specifica adopta intera chì mostra tutti i cambiamenti dapoi a versione precedente, è un CR Abreviazione, chì hè un documentu chì furnisce istruzzioni per mudificà solu e sezioni affettate di a versione di specificazione chì basa u CR.

Durante u 0.9/CR Stage, u WG svilupperà i seguenti utilizendu i mudelli ufficiali furniti in [8]:

Per una nova specificazione, una bozza cumpleta di cuntenutu di a specifica 0.9, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:

Una descrizzione di tutti i cambiamenti chì sò stati fatti da u BARB-reviewed 0.7 specificazione (o postu chì a specificazione 0.5 se a produzzione di a specificazione 0.7 era stata rinunciata), cumprese novi o
pruposte mudificate, criteri di selezzione, è ghjustificazione di a scelta. I cambiamenti devenu esse descritti à u listessu livellu di dettagliu cum'è necessariu in u 0.5 Stage è 0.7 Stage.

2. Per una valurizazione di specificazione:

Sia un CR integratu, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:
Una descrizzione di tutti i cambiamenti chì sò stati fatti da u BARB-reviewed FIPD (o da u DIPD se u FIPD hè statu rinunciatu) cumprese pruposte novi o mudificate, criteri di selezzione è ghjustificazione di scelta. I cambiamenti devenu esse descritti à u listessu livellu di dettagliu cum'è necessariu in u DIPD Stage è FIPD Stage.
Tutti i cambiamenti pruposti à a specificazione adottata in precedenza aduprendu u seguimentu di cambiamenti.
Tutte e errate tecniche appruvate (cù ogni erratum riferitu cù un numeru di erratum), mostrati aduprendu u seguimentu di cambiamenti, chì anu ancu esse incorporati in a versione di specificazione adottata in precedenza, è chì u testu di impattu chì hè assuciatu à u miglioramentu di a specificazione; o chì altrimenti impactanu i test IOP.

3. O un CR abbreviato, chì deve cuntene, à u minimu, informazioni nantu à i seguenti:

Una descrizzione di tutti i cambiamenti chì sò stati fatti da u BARB-reviewed FIPD (o da u DIPD se u FIPD hè statu rinunciatu) cumprese pruposte novi o mudificate, criteri di selezzione è ghjustificazione di scelta. I cambiamenti devenu esse descritti à u listessu livellu di dettagliu cum'è necessariu in u DIPD Stage è FIPD Stage.
Tutti i cambiamenti pruposti à ogni sezione affettata è paragrafo di a specificazione chì u CR prupone di cambià.
Tutte e errate tecniche appruvate (cù ogni erratum riferitu cù un numeru di erratum), mostrati cù u marcatu, chì anu ancu esse incorporati in a versione di specificazione adottata in precedenza, è quellu testu di impattu chì hè assuciatu à u miglioramentu di a specificazione; o chì altrimenti impactanu i test IOP.

4. Un CSS CR (se e nuove entrate sò richieste da a specificazione), chì pò esse incorporatu in un CR abbreviato di a specificazione.
5. Un GSS CR (se e nuove entrate sò richieste da a specificazione), chì pò esse incorporatu in un CR abbreviato di a specificazione.
6. Un MDP CR (se e nuove entrate sò richieste da a specificazione), chì pò esse incrustate in un CR abbreviato di a specificazione.
7. Documenti di prova 0.9 / CR, chì devenu cuntene, à u minimu, infurmazioni nantu à i seguenti cù u mudellu ufficiale furnitu in [8]:

A Suite di Test 0.9 / CR, chì include casi di test cumpletu di cuntenutu è a Tabella di Cartografia di Casi di Test (TCMT) associata, cum'è descritta in u TSTO [5].
U 0.9 / CR ICS, cum'è descrittu in u TSTO [5].
Se a configurazione di i testi richiede parametri specifici per a Implementazione Sottotesta (IUT), l'infurmazione 0.9 / CR eXtra Implementation for Testing (IXIT).
A Lista di Riferimentu di Casi di Prova 0.9 / CR (TCRL) (opzionale per l'aggiornamenti di e Specificazioni Core).

8. Una analisi di copertura di prova chì indica chì esigenze di specificazione sò o testate o micca testate in a Suite di Test 0.9 / CR (per miglioramenti di specificazioni, l'analisi di copertura di test deve solu includere funzionalità appena aghjunte è impactate, è micca e zone senza impattu di a specificazione originale).
9. Un pianu di prova IOP.

Per i miglioramenti di specificazioni, u Test Suite, ICS è IXIT ponu esse furniti sia cum'è documenti separati sia cum'è sezioni addiziunali in u CR abbreviato.

In a maiò parte di i casi, un CR Integratu o Abreviata duveria esse basatu annantu à a versione aduttata di a specificazione, ma pò ancu esse basata annantu à l'ultime bozze intermedie. L'ultimu numeru di versione di specificazione intermedia deve esse u numeru di versione assuciatu à una versione di u documentu chì hè ghjalatu è chì ùn cambierà micca cù u tempu. Altrimenti, infurmazioni identificative addiziunali (cume a data di u documentu è a URL à un locu permanente) deve esse furnitu per identificà a versione specifica "baseline". S'ellu hè adupratu un abbozzu intermediu, qualsiasi cambiamentu micca direttamente ligatu à u CR in una determinata sezione chì u CR mudifica deve esse inclusu, ma ùn sò micca richiesti di esse mostrati cù u markup. Se e porzioni pertinenti di a bozza intermedia sò più tardi aggiornate, u CR deve esse aggiornatu per riflettà l'aggiornamenti di a bozza intermedia.

Idealmente, u materiale CR abbreviato hè integratu rispettivamente in una bozza di a specifica cumpleta è di i documenti di prova cumpleti, prima di a Fase di Validazione, ma ponu ancu esse integrati à l'iniziu di a Fase di Validazione. Se parechje funzionalità sò sviluppate per una specificazione (per esempiu, a Specificazione Core), pò esse desiderabile integrà e caratteristiche in una sola bozza dopu a prova IOP hè finita.

BSTS tornaview a specificazione 0.9/CR è i documenti di prova per a coerenza cù e Linee di Redazione Bluetooth. Allora BARB tornaview a specificazione 0.9/CR seguita più tardi da u pianu di teste IOP (cum'è discrittu in Section 4.3.1). Una volta chì a specificazione 0.9/CR hè sottumessa da u WG à BARB per review, BSTS renderà accessibile per tutti i membri per review è avvisà tutti i membri di a so dispunibilità. Da questu puntu in avanti in u prucessu di sviluppu di e specificazioni, BSTS metterà i bozze di a specificazione sottumessi à BARB dispunibuli per tutti i membri cù avvisi periodichi mandati à tutti i membri.

Per un miglioramentu di a specificazione, u WG raccomanderà à u BoD se e versioni precedenti di a specificazione devenu esse obsolete o ritirate, cumprese e ragioni tecniche di a raccomandazione.

BARB tornaview l'analisi di u WG di a conformità di a specificazione 0.9/CR cù i requisiti dati in u FRD, qualsiasi prublema di sicurezza potenziale, qualsiasi prublema di regulazione, cunfurmità cù l'architettura Bluetooth, è, per un migliuramentu di specificazione, rispettu di i requisiti di cumpatibilità retrocede descritti in a Sezione 3.3.2. .XNUMX. Se BARB identifica qualsiasi prublema di sicurezza potenziale, BARB avvisarà BSTS per review è a coordinazione cù u Gruppu d'Esperti di Sicurezza; è se BARB identifica ogni implicazione regulatoria, BARB notificà à BSTS per ritruvàview è coordina cù u Cumitatu Regulatore è u cunsigliu legale di Bluetooth SIG. BARB deve appruvà o rifiutà a specificazione 0.9/CR basatu nantu à u so ghjudiziu ingegneria è a cunsiderazione di i fatturi descritti in stu paràgrafu.

BTI saràview i ducumenti di prova 0.9/CR tenendu in contu l'analisi di a cobertura di a prova. BTI deve appruvà o rifiutà i documenti di prova 0.9/CR.

Dopu chì BARB appruva a specificazione 0.9/CR, u WG sottumette u pianu di test IOP à BARB per review.

A specificazione 0.9 / CR appruvata da BARB hè presentata à u BoD per appruvà l'iniziu di i test IOP è a publicazione di a specifica 0.9 / CR à tutti i membri.

Per mette in risaltu i pussibuli prublemi legali, i WG ponu dumandà una specificazione riview da u cunsigliu legale di Bluetooth SIG (legal review) davanti à u re legale obligatoriuview si svolge durante a Fase di Adopzione / Approvazione. Tuttavia, per i miglioramenti di specificazione, u re legaleview deve esse fattu nantu à un CR Integrated (in uppusizione à un CR abbreviatu) è questu deve esse prescheduled quant'è in anticipu pussibule per chì e risorse sò dispunibili.

Pianu di prova IOP

U WG svilupperà un pianu di test IOP scrittu chì deve risponde à tutti i requisiti definiti quì sottu per l'usu durante a Fase di Validazione in l'avvenimenti di test IOP. I WG anu da mandà u pianu di teste IOP à BARB per review prima di u principiu di l'avvenimentu di test IOP. Per i migliuramenti di specificazioni simplici (in particulare quelli chì ùn necessitanu micca di mudificà o aghjunghje casi di teste in Test Suite), a prova IOP pò esse micca necessariu, è u WG pò mandà una dumanda à BARB per una rinuncia da a prova IOP utilizendu u prucessu definitu. in a Sezione 4.4.

U pianu di prova IOP deve cuntene:

Casi di prova per verificà tutte e nuove funzioni obbligatorie, facoltative è cundizionali
Almenu un casu di prova per ogni codice op
Almenu un casu di prova per ogni parametru
Almenu un casu di prova per ogni tippu di pacchettu
Casi di prova di cumpatibilità retroattiva per i miglioramenti di specificazioni in modo chì i requisiti elencati in a Sezione 3.3.2 sò soddisfatti per tutte e funzionalità migliorate (vedi ancu Sezione 4.3.1.1).
Casi di prova induve IUT hè esposta à valori fora di intervalli definiti o à aspetti comportamentali cunsiderati invalidi o inaspettati (Casi di prova di Comportamentu invalidu). Notate chì si prevede chì un tester cum'è PTS o altru strumentu di prova serà l'iniziatore di qualsiasi comportamentu invalidu.
Ogni numeru assignatu temporaneamente (selezionatu in coordinazione cù BSTS per evità a sovrapposizione in i prossimi eventi di prova IOP) da aduprà in l'eventu di prova IOP, cum'è descrittu in a Sezione 4.3.1.2.
Identificazione di u numeru richiestu di implementazioni indipendenti chì devenu passà ogni casu di prova, tenendu contu di i requisiti di copertura descritti in a Sezione 4.3.1.3
Identificazione di tutti i casi di prova in u Test Suite chì u WG crede deve esse esclusu è a ghjustificazione per a so esclusione. Queste tipicamente includenu: • Casi di prova di Pruvenza Futura (per esempiu, testi cumuni in modu chì l'aggiunzioni futuri pussibuli ponu esse accolti, cume caratteristiche addiziunali, caratteristiche di estensione, o l'usu di pezzi o campi Riservati per Usevu Futuru (RFU))
• Casi di prova chì sò un sottogruppu di altri test inclusi
• Casi di prova generichi chì sò virtualmente identichi à e prove chì correnu per parechje altre specificazioni (per esempiu, attivendu codici d'errore cumuni)
• Casi di prova cù u listessu scopu di prova cum'è casi di prova chì attraversanu un altru trasportu (per esempiu, un casu di prova BR / EDR chì hè simile à un casu di test LE)
• Robustezza o test di stress di l'implementazione

U pianu di prova IOP pò ancu includere testi chì sò unichi per i test IOP cume casi di prova end-to-end chì stringenu sequenze più cumplesse chì ponu assimilà un scenariu tipicu di l'utente.

Benchì l'appruvazione BARB di u pianu di prova IOP ùn sia micca necessaria (à a cunniscenza chì u pianu di prova IOP continuerà à esse modificatu è miglioratu cù ogni avvenimentu di test IOP), l'approvazione BARB di u rapportu di test IOP hè necessaria (vede a Sezione 5.1.1) . Se un pianu di test IOP ùn soddisfa micca tutti i requisiti definiti in a Sezione 4.3.1, u WG deve presentà un riassuntu di eventuali varianze cunnisciute è u fundamentu per ogni varianza à BARB prima di l'iniziu di l'eventi di test IOP.

U pianu di prova IOP è i casi di prova devenu esse basati principalmente nantu à u cuntenutu in i documenti di prova di a specificazione associata.

Per fà l'efficienza di l'eventi di prova IOP, u WG duveria avè u pianu di prova IOP è tutti i casi di test associati cumpletati è dispunibuli per l'implementatori idealmente almenu un mese prima di u primu avvenimentu di prova IOP.

Pianificazione per i testi di cumpatibilità retroattiva
Per migliurà a specificazione, a prova IOP di cumpatibilità retrocede deve cunsiderà a verificazione contr'à tutte e versioni attive è obsolete di a specificazione perchè e specificazioni è e funziunalità chì si trovanu cumunamente in i prudutti Bluetooth ponu avè una vita assai longa (per esempiu, i veiculi). U WG deve analizà u livellu adattatu di teste di cumpatibilità retrocede necessariu (se ci hè) cumprese quali versioni per pruvà è e teste da fà, è furnisce questa analisi à BARB. BARB deve riview l'analisi è ricumandemu cambiamenti (se ci sò) per u WG per incorpore in u pianu di teste IOP.

I membri chì participanu à testi di compatibilità retroattiva sò incuraghjiti à purtà dispositivi antichi chì sò stati qualificati contr'à e versioni di specificazioni precedenti. U WG deve segnalà qualsiasi fallimentu di compatibilità retroattiva in u rapportu di prova IOP. E cumpagnie membre sò ancu incuraghjite à fà testi di compatibilità à ritrosu in i so propri laboratori fora di u locu di l'eventu di prova IOP è di segnalà à u WG tutti i prublemi relativi à e specificazioni.

Numeri Assignati Temporanei aduprati in i test IOP
BSTS è BARB devenu esse cunsultati per coordinà l'assegnazione temporanea di numeri assignati chì saranu aduprati à l'eventu di prova IOP in modo chì ùn ci sia micca sovrapposizioni o scontri cù altre specificazioni. Questi valori temporanei devenu esse inclusi in u pianu di prova IOP è ùn seranu assignati per l'usu da alcuna specificazione adottata.

Per i test IOP induve unu o più novi valori UUID à 16 bit sò pruposti, i valori in u intervallu da 0x7F00 à 0x7FFF sò riservati per i test IOP.

Per i test di IOP induve unu o più novi valori di Multiplexer di Serviziu di Prutucollu Fissu (PSM) sò stati pruposti, i valori chì partenu da a fine di u intervallu validu da 0x0000 à 0x007F, cumu specificatu in a Specificazione Core, seranu usati.

Requisiti di copertura
U WG deve furnisce una prova à BARB chì u numeru richiestu (cum'è descrittu in e sezioni chì seguitanu) di implementazioni indipendenti anu passatu ogni casu di prova. Ogni dumanda WG per eccezioni à u numeru richiestu di implementazioni indipendenti deve esse indicata in u pianu di prova IOP chì hè presentatu à BARB.

L'implementazioni sò cunsiderate indipindenti l'una di l'altra fintantu chì tutte e parti chì sò pertinenti per a validazione sò state sviluppate indipindente, vale à dì, da diverse squadre (chì ùn venenu micca necessariamente da diverse sucietà). BSTS pò aiutà à valutà se i prototipi ponu esse cunsiderati indipendenti l'uni da l'altri per priservà l'anonimatu è a riservatezza di i dettagli di l'implementazione.

Innota chì l'utili di prova, cumpresu PTS, ùn sò micca cunsiderati cum'è implementazioni indipendenti.

Requisiti di copertura IOP di Specificazione Core
Una caratteristica di Specificazione Core definisce tipicamente unu o più roli induve ogni rolu hè destinatu à interoperà cù unu o più altri roli o forse cun sè stessu.

Per ogni coppia di roli chì sò destinati à interoperà cun l'altru, almenu trè implementazioni indipendenti di ogni rolu devenu esse dimustrate per interoperà cù trè implementazioni indipendenti di u rolu cumplementariu.

Per ogni rolu chì pò interoperà cù un altru dispositivu in u listessu rolu, almenu trè implementazioni indipendenti di stu rolu devenu dimustrà chì ponu interagisce l'uni cun l'altri in quellu rolu.

Requisiti di copertura IOP di specificazione di serviziu
Almenu trè implementazioni di servizii indipendenti devenu dimustrà chì interoperanu cù almenu una implementazione di u cliente, chì pò esse PTS.

Profile e specificazioni di protocolu esigenze di copertura IOP
Profile è e specificazioni di u protocolu definiscenu tipicamente unu o più roli induve ogni rolu hè pensatu per interoperare cù unu o più altri roles, o possibbilmente cun ellu stessu.

Per ogni coppia di roli chì sò destinati à interoperà cun l'altru, almenu duie implementazioni indipendenti di ogni rolu devenu dimustrà chì interoperanu cù duie implementazioni indipendenti di u rolu cumplementariu.

Per ogni rolu chì pò interoperà cù un altru dispositivu in u listessu rolu, almenu trè implementazioni indipendenti di quellu rolu devenu dimustrà chì interagiscenu unu cun l'altru in quellu rolu.

Specificazione di mudellu Esigenze di copertura IOP
Almenu trè mudele di servitore indipendente o implementazione di mudellu di cuntrollu devenu dimustrà chì interoperanu cù almenu una implementazione di u cliente (chì pò esse PTS), è almenu una implementazione di mudellu di clientela deve dimustrà chì interopera cù almenu una implementazione di mudellu di servitore è PTS.

Numerazione di versione di specificazione

Durante u 0.9/CR Stage, u GT deve preparà una raccomandazione per presentà à u BoD in quantu à u numeru di versione chì deve esse applicatu à a specificazione quandu hè aduttatu.

E versioni di e specificazioni si dividenu in dui tippi: versioni di versione cumpleta, chì includenu funzionalità novi o aggiornate, è versioni di versione di mantenimentu (cunnisciuti ancu cum'è "versioni dot-Z"), chì integranu errate tecniche è editoriali, ma ùn includenu micca novi o aggiornati funziunalità. E versioni di versione cumpleta anu numeri in duie parti in forma di XY, cum'è 2.1 o 5.0, mentre chì e versioni di versione di mantenimentu anu numeri in trè parti in forma di XYZ, cum'è 2.1.2. U valore di Z ùn pò esse 0.

Per qualsiasi duie versioni, una hè chjamata "versione superiore" è l'altra hè a "versione inferiore". Questu hè determinatu secondu e regule seguenti:

Se i cumpunenti X differenu, quellu cù u valore X più altu hè a "versione superiore".
Sì i cumpunenti X sò listessi, ma i cumpunenti Y differenu, quellu chì hà u valore Y più altu hè a "versione superiore".
Se i cumpunenti XY sò listessi, ma i cumpunenti Z differenu, quellu cù u valore Z più altu hè a "versione superiore". Un numeru XY in duie parti hè, per questu scopu, trattatu cum'è un numeru XY0 in trè parti.

Per esample, i seguenti numeri di versione seranu in ordine da a versione più bassa à a versione più alta: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Per CSS, ogni aghjurnamentu aumenta solu u cumpunente X di u numeru di versione.

Prerequisiti per l'approvazione di BoD
À a fine di a fase di Sviluppu di Specificazioni i seguenti requisiti devenu esse soddisfatti prima chì una specifica 0.9 / CR sia sottumessa à u BoD per l'approvazione:

U WG hà compiu l'analisi di a cupertura di i testi.
BSTS hà cumpletu riviewin a specificazione 0.9/CR è i documenti di prova.
BARB hà appruvatu a specifica 0.9 / CR.
BARB hà appruvatu u CSS CR (se e nuove entrate sò richieste da a specificazione) chì pò esse inserite in un CR abbreviato di a specificazione.
BARB hà appruvatu u GSS CR è u MDP CR (se e nuove entrate sò richieste da a specificazione).
BTI hà appruvatu a 0.9/CR Test Suite, ICS, è TCRL, inseme cù un IXIT (sempre chì l'IXIT hè necessariu per eseguisce e teste in Test Suite). U TCRL hè facoltativu in questu stage per l'aghjurnamenti à a Specifica Core.
U WG hà sottumessu u pianu di teste IOP à BARB per review (se a prova ùn hè micca rinunciata da BARB).

I documenti presentati à u CdB devenu cuntene a specifica 0.9 / CR appruvata da BARB, è una presentazione à u CdA chì deve cuntene:

Ogni dumanda cunnisciuta di rinuncia à i test IOP o qualsiasi di i requisiti definiti in a Sezione 4.3.1
Un elencu di trasporti chì a specificazione supporta (per esempiu, BR / EDR, LE. Etc.)
Per un miglioramentu di specificazioni, qualsiasi esenzioni da i requisiti di compatibilità retroattiva (descritti in a Sezione 3.3.2) chì sò richiesti da u WG
Per un miglioramentu di a specificazione, una raccomandazione da u WG per u numeru di versione da applicà à a specificazione adottata
Per un miglioramentu di a specificazione, a raccomandazione di fine di vita di u WG per a versione (e) precedente (e) di a specificazione adottata, cumprese qualsiasi ragione tecnica perchè a deprecazione o u ritruvamentu di qualsiasi versione precedente di a specificazione hè o ùn hè micca raccomandata, è a giustificazione per a raccomandazione
Ogni preoccupazione seria senza risolta da i membri di BARB o BTI (per esempiu, motivi per qualsiasi votu No durante l'appruvazioni, preoccupazioni risultanti da riview di documenti di prova, o preoccupazioni chì a specificazione 0.9/CR hè fora di u scopu di u FRD o a carta)
U statutu di preparazione di u Profile Tuning Suite (PTS) o altri strumenti necessarii assuciati à l'adopzione chì sò preparati da BSTS

U BoD pò sceglie di appruvà a specifica 0.9 / CR per i test IOP cum'è richiesti da i Statuti [2], prima chì BTI approva i ducumenti di test 0.9 / CR è prima chì u WG conferma chì u pianu di prova IOP risponde à i requisiti definiti in a Sezione 4.3.1. 0.9. U BoD pò ancu cundiziunà a so approvazione di a specifica 0.9 / CR per i test IOP dopu l'approvazione da BTI di i documenti di prova XNUMX / CR.

0.9/CR Stage esigenze di uscita
U 0.9/CR Stage hè cumpletu è a Fase di Validazione principia quandu u BoD appruva l'iniziu di e teste IOP.

4.4 Rinunzzioni à u Prucessu di Sviluppu di e Specificazioni

Un WG pò chiede di rinuncia à una o più di e seguenti fasi di prucessu:

U 0.5/DIPD Stage
U 0.7/FIPD Stage
Pruvenzi IOP in a Fase di Validazione

Per dumandà una rinuncia, u WG deve aduprà u mudellu di rinuncia à u prucessu furnitu da Bluetooth SIG [8] è sottumette una dumanda di rinuncia à ogni cumitatu (vale à dì, BARB o BTI) chì hè necessariu di ritruvà.view o appruvà u prugettu di specificazione o i ducumenti di prova associati à u stage chì u GT prupone di rinunzià, è ognunu di sti cumitati deve appruvà a dumanda di rinuncia.

A dumanda di rinuncia deve cuntene i seguenti:

Una identificazione di u stage(s) chì u GT voli rinunzià
Una giustificazione perchè u stage(s) deve esse rinunziatu
Una identificazione di ogni cumitatu (vale à dì, BTI è / o BARB) chì hè necessariu di ritruvàview è appruvà a dumanda di rinuncia

U cumitatu chì cunsidereghja a rinuncia pò richiede chì un rappresentante di u WG faci una presentazione per ghjustificà a rinuncia di u prucessu SMPD prima di decide nantu à a richiesta di rinuncia.

Se una rinuncia richiede di rinuncia à più passi è una parte di a rinuncia hè respinta è una parte hè appruvata, a risposta di u cumitatu deve indicà quali passi in a dumanda di rinuncia sò stati appruvati è quali sò stati respinti. Se una dumanda di rinuncia hè respinta, a notificazione di rigettu deve cuntene i motivi di u rigettu.

5. Fase di Validazione

Durante a Fase di Validazione, u WG eseguirà teste IOP nantu à a specificazione 0.9/CR cù l'obiettivu di furnisce un rapportu di prova IOP per BARB re.view è appruvazioni. Ogni volta chì hè pussibule, a prova IOP di e migliorie di specificazioni deve esse realizatu contru à a specificazione di u prugettu integrata. Inoltre, u membru Review, cum'è esigenza da i Statuti [2], principia durante questa fase.

Se l'ispecificazione (o rinfurzazione) ùn richiede micca i test IOP, allora i test IOP in a Fase di Validazione ponu esse rinunziati cù u prucessu descrittu in a Sezione 4.4.

In tuttu u cursu di a prova IOP (chì pò esse unu o più avvenimenti), u WG deve seguità i prublemi utilizendu u sistema di seguimentu di prublemi di Bluetooth SIG è iterate per incorpore l'aghjurnamenti à l'elaborazione di specificazioni, i documenti di prova è u pianu di prova IOP. Una volta chì a prova IOP cunclude, u GT deve compie l'aghjurnamenti à u prugettu di specificazione è i ducumenti di prova per risolve tutti i prublemi, è preparà è mandà un rapportu di prova IOP à BARB per riview è appruvazioni. Questu hè illustratu in a Figura 5.1.

Durante a Fase di Validazione ci sò parechje attività chì ponu cumincià. Queste attività ponu accade in parallelu è includenu i seguenti:

A specificazione 0.9/CR appruvata da u BoD hè dispunibule per tutti i membri da BSTS cù notificazione di l'iniziu di u Re Member.view durata prevista da i Statuti.
Ogni aghjurnamentu necessariu hè incorporatu in CSS (chì pò esse incrustatu in un CR abbreviato di a specificazione).
E definizioni caratteristiche o descrittori sò incorporate in a specificazione GSS è in PTS per i test IOP.
E definizioni di pruprietà di maglia sò incorporate in a specificazione MDP è ancu PTS per i test IOP.
BSTS permette a registrazione di a piattaforma IOP è u strumentu di entrata di risultati in preparazione per i test IOP.
Prove IOP, se necessariu (vede a Sezione 5.1).
Review i cumenti è i prublemi, cumpresi quelli sottumessi in u risultatu di e teste IOP, sò processati è i cambiamenti sò incorporati in u prugettu di specificazione.

5.1 Prove IOP

L'ughjettu primariu di a prova IOP hè di cunvalidà a specificazione, per esempiuample, cuntrollà l'accuratezza è l'ambiguità in u testu, reviewper ogni errore è omissione di cuncepimentu fundamentali, è furnisce validazione contru à i requisiti stabiliti prima sviluppati prima in u prucessu di sviluppu di specificazione. A prova IOP pò purtà à cambiamenti à l'elaborazione di specificazione è parechji avvenimenti di teste IOP ponu esse necessarii per compie tutte e teste richieste.

Hè impurtante di dà à i membri fora di u GT l'uppurtunità di participà à e teste IOP perchè furniscenu un indipendente view di a specificazione è ponu scopre spazii d'ambiguità in a specificazione chì ùn pò micca esse evidenti à i membri di u GT chì hà sviluppatu u prugettu. Prima di ogni avvenimentu di teste IOP, BSTS renderà i dettagli di l'avvenimentu, l'ultime abbozzu di specificazione, a Suite di Test, è u pianu di teste IOP dispunibuli è avviserà tutti i membri idealmente un mese prima di ogni avvenimentu. L'elaborazione di specificazione aghjurnata, Test Suite, è u pianu di prova IOP utilizatu in un avvenimentu di prova IOP deve esse dispunibule almenu una settimana prima di ogni avvenimentu.

Durante i test di IOP, cumbinazioni coppie di piattaforme pruveranu à eseguisce e prove è i participanti à i test di IOP registreranu i risultati di pass / fail di ogni test è cumenti. Un riassuntu anonimizatu di questi risultati (riferendu per esempiu, "Piattaforma A", "Piattaforma B", ecc.) È qualsiasi cummentariu, serà riunitu durante l'eventi di prova IOP è messu à dispusizione di i membri di u WG durante è dopu u IOP avvenimentu di prova. In casu d'infurmazioni addiziunali sò necessarie per ottene una migliore comprensione di qualsiasi cummentariu o fallimentu accadutu durante i test IOP, BSTS pò agisce cum'è intermediari per raccoglie ulteriori informazioni da u membru sottumettente.

Sè pussibule, PTS deve esse aggiornatu per supportà i test IOP cù piattaforme in tutti i livelli sopra l'interfaccia di u Controller di l'ospite (HCI), è esse presente à l'eventi di prova IOP per questi strati. Altri strumenti di prova ponu ancu esse presenti in eventi di prova IOP. Un riassuntu di i risultati di e prove cù PTS o altri strumenti di prova (se esiste) deve esse inclusu in u rapportu di prova IOP.

I test IOP saranu aperti à tutti i membri chì volenu furnisce un prototipu di implementazione, tuttavia, Bluetooth SIG pò condizionà a participazione à l'accettazione di accordi cù Bluetooth SIG (cumpresi accordi di participazione è riservatezza). U WG hè incaricatu di trattà è risolve i prublemi scuperti durante e prove IOP, è d'aghjurnà i documenti affettati; I cambiamenti appruvati da u WG devenu esse incorporati cum'è aggiornamenti à u prughjettu di specifiche è di documenti di prova da aduprà in ogni avvenimentu di prova IOP.

Prima di a Fase di Validazione, i WG ponu fà test preliminari IOP in eventi chì sò aperti solu à i membri di u WG, tuttavia i risultati di e prove informali ùn ponu micca esse inclusi in i risultati di i test IOP.

Pò accade chì tutti i passi chì portanu à u primu avvenimentu di test IOP sò seguitati, cumprese una data è un locu IOP annunziati cù l'intenzione di inizià i test IOP, ma l'approvazione BoD ùn era micca stata assicurata prima di l'iniziu di l'eventu di prova. In questu casu, u BoD pò autorizà l'inclusione di risultati di test chì sò stati raccolti prima di l'approvazione di u BoD per avviare i test IOP, a condizione chì i risultati raccolti sò stati basati nantu à a stessa specificazione è Test Suite chì hè stata appruvata da u BoD.

U test IOP ùn hè micca necessariu per i miglioramenti à e specifiche CSS, GSS, o MDP.

Rapportu di prova IOP
Dopu chì a prova IOP hè cumpleta, u WG deve mandà u rapportu di prova IOP à BARB cù l'ughjettu di dimustrà chì u numeru necessariu di piattaforme indipendenti anu passatu i testi richiesti. BARB deve riview è appruvà o rifiutà u rapportu di prova di l'IOP è avvisarà u GT se un test IOP supplementu hè necessariu prima di mandà u pacchettu di specificazione di Voting Draft à u BoD. BSTS è u WG anu da assicurà chì nisuna infurmazione d'identità di i membri appare in u rapportu di prova IOP prima di mandà u rapportu à BARB.

U rapportu di prova IOP deve cuntene:

Un elencu di tutti l'eventi di prova IOP accaduti durante a Fase di Validazione cumprese e so date è i so lochi.
U numaru di cumpagnie membri è di piattaforme indipendenti chì anu participatu à ogni avvenimentu IOP cumpresu se PTS hè stata aduprata.
Un elencu di e specificazioni, Test Suite, è versioni di u pianu di test IOP aduprate in ogni avvenimentu.
Un riassuntu esecutivu chì dichiara se tutti i casi di prova rispettanu o micca i criteri di passaghju minimi.
Un riassuntu di ogni varianza da i requisiti di u pianu di test IOP definiti in a Sezione 4.3.1 è u fundamentu per ogni varianza.
Un riassuntu di a copertura PTS per i casi di prova in u Test Suite.
Un elencu di tutti i casi di prova (cumpresi i test di compatibilità retroattiva) da u pianu di test IOP, u numeru di passate di test, u numeru di fallimenti di test, è se i criteri minimi sò stati soddisfatti per ogni casu di prova cumprese una spiegazione per quessa chì qualsiasi esigenze ùn eranu micca scuntratu.
Un riassuntu di prublemi, cumenti è dumande in ogni avvenimentu (cumpresi quelli filed contru à a specificazione durante a prova IOP) è l'impattu à a specificazione è i documenti di prova.

5.2 Requisiti di uscita di Fase di Validazione

A Fase di Validazione hè cumpleta è a Fase di Approvazione / Adozione inizia quandu BARB hà appruvatu u rapportu di test IOP (a menu chì a prova ùn sia stata rinuncia da BARB) è chì tutti i seguenti requisiti sò stati soddisfatti:

BSTS hà messu a specificazione appruvata 0.9/CR dispunibule per tutti i membri per Member Review cum'è dumandata da i Statuti è avvisatu tutti i membri di a so dispunibilità.
Tutti i prublemi chì sò stati identificati durante i test IOP, è chì anu un impattu di test, sò stati incorporati è testati.
WG hà compiu i test IOP (à menu chì u test sia statu rinunziatu da BARB).

6. Fase di Adozione / Approvazione

Durante a Fase di Adopzione / Approvazione, a specificazione è i documenti di prova cunnessi sò finalizzati, l'appruvazioni BARB, BQRB è BTI sò ricevute, l'avvisu di a Data di Adopzione pruposta hè emessu cù a versione finale di u prugettu di specificazione presentata à u BoD per l'adopzione ( Voting Draft), è u pacchettu di specificazione finali hè sottumessu à u BoD. Dopu à a durata minima di Member Review richiestu da i Statuti [2]) hè stata soddisfatta, u CdA cunsidererà a specificazione per l'adopzione à a Data di Adopzione. Dopu l'adopzione, a specificazione hè publicata è u sistema di qualificazione hè attivatu. A Fase di Adopzione / Appruvazioni hè illustrata in Figura 6.1.

6.1 Prughjettu di votu

L'abbozzu di votu hè creatu incorpurendu l'aggiornamenti (furniti in a Fase di Validazione) in i documenti di specificazione richiesti, è preparendu una bozza finale di a nova specificazione. Per i miglioramenti di specificazione, BSTS creerà a specificazione integrata integrendu unu o più CR (s) in a versione più alta adottata in precedenza di a specificazione (vede a Sezione 4.3.2) se ùn hè micca già finita prima di a Fase di Validazione.

Se i cambiamenti sò fatti à a specificazione durante questa fase è u WG, BARB, o BTI determina chì qualsiasi cambiamentu richiede test IOP supplementari, a specificazione tornerà à a parte di prova IOP di a Fase di Validazione per u WG per eseguisce e prove addiziunali. Durante a Fase di Adozione / Approvazione, i seguenti documenti seranu cumpletati è messi à dispusizione di u BoD prima di a Data di Adozione:

L'abbozzu di votu
Tutte e specificazioni di supportu (vale à dì, CSS, GSS, MDP) cume richieste per u tipu di specificazione pertinente (o rinfurzamentu), se ùn sò micca state adottate prima
Per i miglioramenti di specificazioni, una versione tracciata di cambiamentu di a versione di specificazione adottata chì mostra i cambiamenti pruposti in u Prughjettu di Votazione
Una descrizzione da u WG di qualsiasi esigenze di compatibilità retroattiva (cum'è descritta in a Sezione 3.3.2) chì ùn sò micca state soddisfatte è a giustificazione per qualsiasi esenzioni
Una descrizzione da u WG di qualsiasi esigenza di u pianu di prova IOP (cum'è descritta in a Sezione 4.3.1) chì ùn sò micca stati soddisfatte è a ghjustificazione di qualsiasi deviazioni cù u rapportu di prova IOP (chì pò esse furnitu fornendu un ligame à una copia nantu à u SIG Bluetooth websitu)
Una raccomandazione da u WG per a deprecazione o ritirata di qualsiasi versione precedente di a specificazione aduttata cù una ghjustificazione, chì mette in risaltu i cambiamenti da u 0.9/CR S.tage raccomandazione di fine di vita
Un riassuntu, preparatu da u WG, di cambiamenti à e caratteristiche o funzionalità dapoi a specificazione 0.9 / CR (se esiste)
Un riassuntu, preparatu da BARB, di e preoccupazioni suscitate da i membri BARB chì a specificazione prodotta da u WG hè al di là di u scopu di a carta approvata da u BoD (se esiste)
Una lista di i prublemi legali chì restanu micca risolti da u regnu legaleview (s'ellu ci hè)
A Suite di Test appruvata da BTI, cun u riassuntu appruvatu da u WG di a copertura di i testi di a specificazione di u Draft di Votazione. In casu di funzionalità appena aghjuntu o mudificatu senza cupertura di test, hè necessaria una ghjustificazione scritta per l'omissione
L'ICS è l'IXIT appruvati da BTI (se richiesti da a specificazione)
U TCRL appruvatu da BTI è BQRB
Un rapportu preparatu da BSTS cun BTI in quantu à u statu di prontezza di l'utensili (per esempiu, PTS è altri strumenti di prova, Studio di Lanciamentu Bluetooth) ancu se alcuni casi di prova in TCRL ùn sò micca supportati da strumenti di prova
Un riassuntu, preparatu da u WG, di tutti i numeri assignati necessarii
Una lista di verificazione di adozione preparata da BSTS è u WG chì mostra chì tutti i risultati in questa sezione sò tutti stati cumpletati
Tutte l'altre informazioni richieste da u BoD

Durante a Fase di Adozione / Approvazione, u WG deve aduprà u sistema di tracciamentu di emissioni di Bluetooth SIG per catturà questioni è cummenti contr'à u prughjettu di specificazione è di documenti di prova in modu chì sianu contabilizzati in a finalizazione di u Spechju di Prughjettu di Votazione. Per un miglioramentu di specificazioni, tutte e errate appruvate pertinenti (vale à dì quelle errate appruvate micca ancu integrate) devenu esse incorporate, è devenu esse identificate aduprendu cambiamenti tracciati.

U WG deve trasmette a specificazione finale di u prugettu à BSTS per riguardu legaleview. Per e novi specificazioni, u re legaleview includerà a specificazione sana. Per migliurà a specificazione, u review fucalizza principalmente nantu à e parti cambiate di a specificazione. U scopu di re legaleview hè principalmente di identificà i risichi legali chì u GT deve cunsiderà è cercà di risolve. U feedback legale serà categurizatu secondu a gravità. Se un re legale facultativuview hè stata fatta à u 0.9/CR Stage, a versione chì hè sottumessa per re legaleview deve mustrà, cum'è cambiamenti tracciati, tutti i cambiamenti chì sò stati fatti da quella versione (generati da u WG o BSTS). Dopu à u cumpletu di re legaleview, u WG è BSTS accunsenu nantu à i feedback da esse incorporati in u prugettu di specificazione. Sè ci sò qualchi cumenti legale senza risolta da legale review nantu à u prugettu di specificazione, u presidente di u GT pò dumandà u tempu nantu à l'agenda di u BoD per accunsentà a risoluzione.

In parallelu cù re legaleview, u WG deve mandà u prugettu di specificazione à BARB per review. Dopu a presentazione iniziale à BARB, BSTS notificà à tutti i membri chì u prugettu di specificazione hè statu sottumessu à BARB per riview è chì hè ancu dispunibule per Member Review. Se u WG sottumette l'aghjurnamenti à u prugettu di specificazione per BARB re-review, BSTS manderà avvisi supplementari à tutti i membri nantu à una basa periodica.

À a fine di BARB review, u WG è BARB accunsenu nantu à i feedback per esse incorporati in u prugettu di specificazione.

Se u re legaleview risultati in ogni cambiamenti sustantivi, re supplementuview da BARB pò esse necessariu. In listessu modu, se u BARB review risultati in ogni cambiamenti sustantivi, BSTS determinerà se un re legale supplementuview di sti cambiamenti hè necessariu. Dopu à u cumpletu di re legaleview è BARB review, BARB deve appruvà o rifiutà u Draft di Votazione.

Se qualchì documentu di prova richiede un aghjurnamentu, BSTS assisterà u WG à l'aghjurnamentu di i documenti di prova. BTI deve appruvà o rifiutà i documenti di prova. Se hè appruvata da BTI, BTI assisterà à finalizà u TCRL è trasmette stu documentu à BQRB cun l'ICS, IXIT è Test Suite associati. BSTS stimerà a data di a riunione di u BoD quandu u BoD hà l'intenzione di vutà nantu à l'adopzione di u Prughjettu di Votazione (Data di Adozione) è li furnisce BTI per u so usu in TCRL. L'approvazione BARB di a specifica, l'approvazione BTI di tutti i documenti di prova (cumpresu Test Suite, TCRL, ICS è IXIT), è l'approvazione BQRB di TCRL devenu esse in data o prima di a Data di Adozione.

BSTS informarà tutti i membri di a finalizazione è a dispunibilità di u Bozza di Votazione è a Data di Adopzione. A Data di Adopzione serà stabilita micca prima di 60 ghjorni dopu chì i membri sò stati notificati di a specificazione 0.9/CR appruvata da u BoD, salvu chì u Membru Review U periodu hè accurtatu da u CdA in cunfurmità cù i Statuti, è almenu 14 ghjorni dopu chì l'avvisu di a Data di Adopzione hè furnitu à i membri in cunfurmità cù i Statuti. Per i casi induve parechji CR sò stati integrati in un Draft di Votazione, l'iniziu di Member Review hè a data chì i membri sò stati avvisati di u più recente CR appruvatu da u BoD.

Dopu avvisu di a Data di Adozione hè furnitu à i membri, e correzioni appruvate da BoD per errori tipugrafichi in u Prughjettu di Votazione sò permesse. A cronologia di Adozione di Specificazione hè illustrata in Figura 6.2.

6.2 Numeri assignati

Bluetooth SIG mantene un settore publicamente dispunibule di numeri assignati nantu à i Numeri Assignati Bluetooth SIG websitu [7]. Questi numeri assignati sò raggruppati in parechji spazii numerichi (un settore di numeri cunnessi senza duplicati). I numeri assignati ponu sovrappone cù altri numeri assignati in spazii numerichi diffirenti, ma nisun numeru in un spaziu numericu hè permessu di esse riutilizatu. I diversi spazii numerichi sò definiti in a specificazione chì definisce l'usu di i numeri assignati.

Dopu chì BARB appruva u rapportu di prova IOP, u WG trasmette una dumanda à BARB per l'assignazione di novi numeri in u spaziu numericu (s) richiesti da a specificazione finale. BARB tornaview a dumanda è travaglià cù BSTS per determinà i numeri assignati. Dopu l'appruvazioni di BARB, BSTS prugramerà a publicazione di i numeri assignati per esse dispunibuli publicamente nantu à i Numeri Assignati Bluetooth SIG. websitu [7] in una settimana da l'adopzione di a specificazione.

Una volta a publicazione di numeri assignati nantu à u Bluetooth SIG Assigned Numbers websitu o in una specificazione aduttatu, i numeri assignati sò destinati à esse immutabili (per ùn cambià nè valore nè significatu). S'elli diventanu inutilizabili per una certa ragione, diventanu valori riservati è ùn sò micca permessi di esse riutilizzati.

6.3 Requisiti di uscita per a Fase di Adozione / Approvazione

A Fase di Approvazione / Adozione hè cumpleta quandu u BoD hà aduttatu a specificazione è e seguenti attività post-adozione sò state compie:

BSTS hà fattu i numeri assignati finali dispunibuli publicamente nantu à u Bluetooth SIG websitu.
BSTS hà fattu a specificazione aduttata publicamente dispunibule nantu à u Bluetooth SIG websitu
BSTS hà fattu tutti i documenti di supportu (per esempiu, CSS, GSS, MDP) richiesti per a specificazione pertinente publicamente dispunibili nantu à u Bluetooth SIG. websitu.
BSTS hà fattu i ducumenti di prova assuciati dispunibuli per tutti i membri nantu à u Bluetooth SIG websitu.
Per i miglioramenti di e specificazioni, BSTS hà fattu una versione informativa di u cambiamentu di a versione di specificazione aduttata prima cù tutti i cambiamenti fatti da a versione di novu aduttatu è l'hà dispunibile per tutti i membri nantu à u Bluetooth SIG. websitu.
BSTS hà permessu u sistema di qualificazione.
BSTS hà notificatu à tutti i membri a dispunibilità di e specifiche adottate è tutti i documenti di supporto.

U Bluetooth SIG prevede di compie queste attività post-adozione in una settimana dopu l'adopzione di a specifica.

7. Fasi di Manutenzione di e Specificazioni

A Fase di Manutenzione di e Specifiche principia dopu chì a Fase di Adozione / Approvazione sia finita. Se si trovanu prublemi (per esempiu, ambiguità di formulazione o errori tecnichi) cù a specificazione o i documenti di test assuciati, devenu esse documentati creendu pruposte d'errata cù u strumentu Bluetooth SIG Errata. E pruposte d'erratum di specificazione saranu trattate, classificate è appruvate secondu l'EPD [3]. Test Suite erratum sò trattati è categurizzati secondu u TSTO [5]. Se ci sò cunflitti trà u SMPD è sia l'EPD o TSTO, u SMPD hà a precedenza.

L'erratum di specificazione deve esse adupratu solu per curregge errori tecnichi o editoriali in e specifiche Bluetooth adottate finali. L'aggiunta, i cambiamenti è a rimozione di a funzionalità ponu esse fatte solu per mezu di u prucessu di miglioramentu di e specificazioni definitu prima in stu documentu.

7.1 Processu di erratum acceleratu

Quandu un erratum hè appruvatu dopu à u prucessu definitu in l'EPD [3], u WG, BARB, o BSTS pò ricumandemu chì sia cunsideratu urgente è deve esse acceleratu. Quandu questu accade, BSTS inseme cù u WG o BARB presentanu a raccomandazione à u BoD. U BoD decide s'ellu accetta o rifiuta a raccomandazione. Se a raccomandazione hè accettata, BSTS incorporerà immediatamente l'errata appruvata in u mudellu di erratum [8] è travaglià cù u WG rispunsevule per finalizà una Correzione di Errata Rapida da esse presentata à u GT per riview è appruvazione.

Un sopraview di u prucessu di erratum acceleratu hè illustratu in Figura 7.1.

I seguenti documenti devenu esse cumpletati è messi à dispusizione di u BoD prima di a Data di Adozione:

U prugettu appruvatu da BARB Correzione Errata Accelerata.
Una descrizzione da u WG di qualsiasi esigenze di compatibilità retroattiva (cum'è descritta in a Sezione 3.3.2) chì ùn sò micca state soddisfatte è a giustificazione per qualsiasi esenzioni.
Una lista di i prublemi legali chì restanu micca risolti da u regnu legaleview (s'ellu ci hè).
U Test Suite, ICS è IXIT appruvati da BTI (se richiesti da l'erratum).
U TCRL appruvatu BTI- è BQRB (se richiestu da l'erratum).
Un rapportu cumpletatu da BSTS cun BTI in quantu à a situazione di prontezza di l'utensili (per esempiu, PTS è altri strumenti di prova, Studio di Lanciamentu Bluetooth) ancu se alcuni casi di prova in TCRL ùn sò micca supportati da strumenti di prova è una spiegazione (se richiestu da l'erratum ).
Una lista di verificazione di l'adopzione cumpletata da BSTS è u WG chì mostra chì i risultati in questa sezione sò stati cumpletati.
Tutte l'altre informazioni richieste da u BoD.

BSTS hà da travaglià cù u WG rispunsevule per finalizà u prugettu di Correzione di Errata Accelerata è creà una versione da mandà à u WG rispunsevule per riview è appruvazione.

U WG deve mandà a Correzione di Errata Accelerata à BSTS per riguardu legaleview. Dopu à u cumpletu di re legaleview, u WG è BSTS accunsenu nantu à i feedback per esse incorporati in a Correzione di Errata Expedited. Sè ci sò qualchi cumenti legale senza risolta da legale review nantu à a Correzione Rapida di Errata, u presidente di u GT pò dumandà u tempu nantu à l'agenda di u BoD per circà l'input di u BoD nantu à a risoluzione.

In parallelu cù re legaleview, u WG deve mandà a Correzione di Errata Rapida à BARB per review. Una volta chì a Correzione di Errata Accelerata hè sottumessa à BARB, BSTS a rende accessibile per tutti i membri per riview è avvisà tutti i membri di a so dispunibilità. À a fine di BARB review, u WG è BARB accunsenu nantu à i feedback per esse incorporati in a Correzione di Errata Expedited.

Se qualchì documentu di prova richiede un aghjurnamentu, BSTS assisterà u WG à l'aghjurnamentu di i documenti di prova. Dopu l'approvazione BTI di i documenti di prova, BTI assisterà à finalizà u TCRL è consegnerà u documentu à BQRB cù l'ICS, IXIT è Test Suite associati, secondu u casu. BSTS stima a Data di Adozione è a furnisce à BTI per aduprà in TCRL. L'approvazione BARB di a Correzione Errata Accelerata, l'approvazione BTI di tutti i documenti di prova (cumpresu a Suite di Test, TCRL, ICS è IXIT, se applicabile), è l'approvazione BQRB di TCRL deve accadere in o prima di a Data di Adozione.

BSTS informerà tutti i membri di a finalizazione è di a dispunibilità di a Correzione Errata Accelerata è di a Data di Adozione pruposta. A Data di Adozione serà stabilita è notificata à tutti i membri in cunfurmità cù i Statuti [2] è a Data di Adozione serà almenu 14 ghjorni dopu chì l'avvisu sia furnitu à i membri. Dopu avvisu di a Data di Adozione pruposta hè furnitu à i membri, u BoD pò appruvà correzioni di errori tipugrafichi in a Correzione Errata Accelerata senza furnisce un avvisu addiziunale di a Data di Adozione proposta è aspettendu i 14 ghjorni richiesti.

Bluetooth SIG renderà dispunibule publicamente a Correzione Accelerata Errata aduttata è prevede di fà la in una settimana dopu l'adopzione. A notificazione di a so dispunibilità serà emessa da BSTS à tutti i membri.

U prucessu di erratum acceleratu hè cumpletu quandu u BoD hà aduttatu a Correzione di Errata Expedited è e seguenti attività post-adozione sò state compie:

BSTS hà fattu a correzione rapida di l'errata aduttatu è i ducumenti di teste associati (se dumandati da l'errata) publicamente dispunibuli nantu à u Bluetooth SIG. websitu.
BSTS hà permessu u sistema di qualificazione (se richiestu da l'erratum).
BSTS hà avvisatu tutti i membri di a dispunibilità di a Correzione Accelerata Errata aduttata.

À a fine di queste attività, a Correzione Errata serà pianificata per l'integrazione in e specifiche interessate sia in parte di un miglioramentu di specificazioni pianificate sia in una prossima versione di manutenzione cum'è descritta in a Sezione 7.2.

7.2 Processu di liberazione di manutenzione (specifiche .Z)

In una basa apprussimatamente annuale, BSTS determinarà s'ellu ci hè qualchì errata appruvata (chjamata Correzione Errata) chì hè classificata cum'è Tecnica / Alta o Tecnica / Critica è chì ùn deve ancu esse incorporata in u testu di qualsiasi specificazione attiva (vale à dì, una specificazione adottata chì ùn hè stata deprecata o ritirata). Vede l'Appendice A per definizioni di classificazione di errata. Un Proprietariu di Specificazione (sia u WG affittu per mantene l'ispecificazione, sia BARB se nisun WG hè affittuatu per mantene l'ispecificazione) pò ancu dumandà una liberazione di mantenimentu precedente di una specifica attiva in a quale incorpore qualsiasi errata appruvata. Dopu a determinazione BSTS, o a dumanda di u Proprietariu di Specificazione, u prucessu di liberazione di manutenzione inizierà.

Un sopraview di u prucessu di liberazione di mantenimentu hè illustratu in Error! A fonte di riferimentu ùn hè micca trovu.

À l'iniziu di u prucessu di liberazione di manutenzione, BSTS cun u Proprietariu di Specificazione, BARB è BTI svilupperanu è presenteranu un pianu à u BoD per l'incorporazione di e Correzioni Errata in a versione di specificazione publicata. U pianu prupostu deve indicà se e Correzioni Errata seranu incorporate in una versione di mantenimentu di a specificazione (vale à dì, una versione .Z) o una migliurazione di specificazione chì hè digià in corsu (vale à dì, una versione XY). U pianu prupostu deve piglià in contu se qualchì nova funzione obbligatoria hè stata aghjunta trà e versioni di e specifiche adottate, u tempu stimatu quandu a prossima migliurazione di e specifiche hè prevista per l'adopzione, è altri fattori.

Dopu l'appruvazione di un pianu da u BoD, BSTS cù u Proprietariu di Specificazione procederanu à incorporà tutte e Correzioni Errata Tecniche / Medie, Tecniche / Alte, è Tecniche / Critiche in una bozza di specificazione chjamata "Prughjettu di Versione di Mantenimentu". Per Correzioni Editoriali o Tecniche / Errata Bassa, se a Correzione Errata s'applica à più di una versione di a specificazione, BSTS integrerà quelle errata in a versione più recente di specificazione superiore più recente à a prossima messa à ghjornu di quella versione, à menu chì u BoD ùn indichi diversamente . Nisun cambiamentu pò esse inclusu in un Prughjettu di Versione di Mantenimentu altru chì incorpore Correzioni Errata. Ogni Prughjettu di Rilasciu di Manutenzione deve identificà tutte e Correzioni Errata incorporate aduprendu u seguimentu di cambiamenti per mostrà i cambiamenti proposti à a versione adottata in precedenza di a specificazione publicata.

U tempu di l'incorporazione pruposta per ogni Correzione Errata in un Prughjettu di Versione di Manutenzione dipenderà da l'impattu di a Suite Test: tutte e Correzioni Errata chì ùn anu micca impattu Suite Test ponu esse incorporate subitu, ma e Correzioni Errata chì impactanu nantu à a Suite Test saranu trasfurmatu in modu chì u tempu coincida cù un aghjurnamentu à u TCRL.

BTI è BSTS stabilisceranu una scadenza per l'inclusione di Errata Correzioni cù impattu di Test Suite in un Prughjettu di Versione di Manutenzione. Questa scadenza hè tipicamente di 3 à 6 mesi prima di a data di approvazione pianificata per a prossima versione TCRL principale. E Correzioni Errata cù l'impattu di Test Suite chì mancanu a data di scadenza per l'inclusione saranu trattate cum'è parte di a prossima versione annuale di TCRL. Dunque, a menu chì una versione precedente sia dumandata, u tempu massimu per e Correzioni Tecniche / Alte o Tecniche / Critiche Errata da esse incluse in un aggiornamentu di specificazioni hè apprussimatamente 15 à 18 mesi.

U Pruprietariu di Specifica deve trasmette u Progettu di Liberazione di Manutenzione chì hà appruvatu cum'è finali per a riunione legale.view. U re legaleview fucalizza principalmente nantu à e parti cambiate di a specificazione. Dopu à u cumpletu di re legaleview, u Proprietariu di Specifica è BSTS accunsentiranu nantu à i feedback da esse incorporati in u Bozza di Liberazione di Manutenzione. Sè ci sò qualchi cumenti legale senza risolta da legale review nantu à u Bozza di Liberazione di Manutenzione, u Proprietariu di Specifica pò dumandà u tempu nantu à l'agenda di u BoD per cercà l'input di u BoD nantu à a risoluzione.

In parallelu cù re legaleview, u pruprietariu di l'Specificazioni deve invià u Bozza di Liberazione di Manutenzione à BARB per review. Una volta chì u Bozza di Liberazione di Manutenzione hè sottumessu à BARB, BSTS renderà accessibile per tutti i membri per ritruvà.view è avvisà tutti i membri di a so dispunibilità. À a fine di BARB review, u Proprietariu di l'Specificazioni è BARB accunsenu nantu à i feedback da esse incorporati in u prugettu di specificazione.

Per e Correzioni Errata chì impactanu i documenti di prova, è induve e currettive errate di prova saranu trattate in tempu per a prossima versione TCRL, BSTS travagliarà cù u Proprietariu di Specificazione è BTI per aghjurnà i documenti di prova. Dopu l'approvazione BTI di i documenti di prova, BSTS stimerà a Data di Adozione è furnisce a Data di Adozione proposta à BTI per u so usu in TCRL. BTI consegnerà u TCRL à BQRB cù l'ICS, IXIT è Test Suite associati, secondu u casu. L'approvazione BARB di a specifica, l'approvazione BTI di tutti i documenti di prova (cumpresu Test Suite, TCRL, ICS, è IXIT, se applicabile), è l'approvazione BQRB di TCRL deve esse accaduta à a Data di Adozione o prima.

BSTS informerà tutti i membri di a finalizazione è di a dispunibilità di u Prughjettu di Votazione è di a Data di Adozione pruposta. A Data di Adozione serà stabilita è notificata à tutti i membri in cunfurmità cù i Statuti è a Data di Adozione serà almenu 14 ghjorni dopu chì l'avvisu di l'avvisu sia furnitu à i membri. Dopu avvisu di a Data di Adozione pruposta hè furnitu à i membri, u CdB pò appruvà correzioni di errori tipugrafichi in u Prughjettu di Vutazione senza furnisce un avvisu addiziunale di una Data di Adozione pruposta è aspettendu i 14 ghjorni richiesti.

I seguenti documenti devenu esse cumpletati è messi à dispusizione di u BoD prima di a Data di Adozione:

L'abbozzu di votu
Una versione cun traccia di cambiamentu di u Prughjettu di Votazione chì mostra tutti i cambiamenti à a versione aduttata di a specificazione chì hà u listessu valore XY (per esempiu, se u Prughjettu di Votazione hè prupostu cum'è versione 1.4.2, i cambiamenti seranu tracciati contr'à u 1.4.1 versione di a specificazione)
Una raccomandazione da u Proprietariu di Specificazione per a svalutazione o u ritruvamentu di qualsiasi versione (e) precedente (e) di a specificazione adottata cun una ghjustificazione
Una lista di i prublemi legali chì restanu micca risolti da u regnu legaleview (s'ellu ci hè)
U Test Test Suite, ICS è IXIT appruvatu (se richiestu da a versione di manutenzione)
U TCRL appruvatu BTI- è BQRB (se richiestu da a liberazione di manutenzione)
Un rapportu cumpletatu da BSTS cun BTI in quantu à a situazione di prontezza di l'utensili (per esempiu, PTS è altri strumenti di prova, Studio di Lanciamentu Bluetooth) cumprendu tutti i casi di prova in TCRL chì ùn sò micca supportati da strumenti di prova, è spiegazione (se richiestu da a manutenzione liberazione)
Una lista di verificazione di adozione cumpletata da BSTS è u Proprietariu di Specificazione chì mostra chì i risultati in questa sezione sò tutti stati cumpletati
Tutte l'altre informazioni richieste da u BoD

U prucessu di liberazione di mantenimentu hè cumpletu quandu u BoD hà aduttatu u Prughjettu di Votazione è e seguenti attività post-adopzione sò state compie:

BSTS hà fattu a specificazione aduttata è i documenti di prova assuciati (se necessariu da a versione di mantenimentu) publicamente dispunibili nantu à u Bluetooth SIG. websitu.
BSTS hà fattu una versione informativa di u cambiamentu di traccia di a versione di specificazione aduttata prima cù tutti i cambiamenti incorporati in a versione appena aduttata dispunibule per tutti i membri nantu à u Bluetooth SIG. websitu.
BSTS hà permessu u sistema di qualificazione.
BSTS hà avvisatu tutti i membri di a dispunibilità di a specificazione adottata è di i documenti di supporto.

U Bluetooth SIG prevede di compie queste attività post-adozione in una settimana dopu l'adopzione di a specifica.

À a fine di queste attività, a specificazione resta in a fase di Manutenzione di e Specifiche finu chì a specificazione sia obsoleta o ritirata, cum'è definita in a Sezione 8.

8. Specificazione Fase di Fine Vita

E specificazioni ponu esse deprecate o ritirate quandu sò rimpiazzate da versioni più recenti, determinate chì sò tecnicamente insufficienti, o per altri motivi. E specificazioni obsolete è ritirate sò archiviate è ùn sò più aggiornate. E specificazioni obsolete è ritirate sò trattate diversamente in u Prugramma di Qualificazione Bluetooth.

Ogni membru, gruppu o cumitatu pò presentà raccomandazioni per deprecà o ritirà una specificazione cun una cronologia associata à BSTS (per email à

specification.manager@bluetooth.com) in ogni mumentu. BSTS pò ancu ricumandemu a deprecazione o a ritirata di una specificazione è u timeline assuciatu. BSTS rinviarà a raccomandazione à BARB è à u gruppu o cumitatu rispunsevule per mantene a specificazione per riview è feedback.

BARB è u gruppu o cumitatu rispunsevule valuteranu raccomandazioni per deprecà o ritirà una specifica è cunsideranu i criteri seguenti (non esaustivi):

Ci hè una funziunalità in una versione precedente di a specificazione chì hè obsoleta o ùn deve micca esse usata?
Hè stata aghjunta nova funzionalità obbligatoria à e versioni successive?
Ci sò carenze in e versioni precedenti chì compromettenu l'operazione o l'interoperabilità chì sò state corrette in versioni successive è chì sò necessarie per avanzà i scenarii di l'utente esistenti?
Ci hè una funzionalità addizionale in versioni successive necessarie per fà avanzà novi scenarii d'utilizatori?
Ci hè una migliore usabilità è interoperabilità in versioni successive?
Ci sò miglioramenti di sicurezza in e versioni successive?

BARB è u gruppu o cumitatu rispunsevule ponu prupone una raccomandazione alternativa.

Dopu avè ricevutu feedback da BARB o da u gruppu o cumitatu incaricatu di mantene a specificazione, BSTS trasmetterà e raccomandazioni è feedback à u BoD per a considerazione. U BoD pò invità u gruppu o cumitatu chì hè rispunsevuli di mantene e specificazioni affettate à scuntrà è discute e raccomandazioni. U BoD cunsidererà raccomandazioni è feedback è pò accunsente o mudificà a pruposta. U BoD richiederà chì BSTS notificà à tutti i membri di e pruposte per annullà o ritirate specificazioni è scadenze assuciate per una ripresa di 30 ghjorni.view per permette à tutti i membri di furnisce feedback supplementari prima di piglià a so decisione finale.

U BoD cunsidererà i feedback ricevuti da i membri. Una volta chì u BoD approva a deprecazione o a retirazzione di una specificazione, BSTS avverrà tutti i membri di a decisione è di a cronologia associata.

8.1 Deprecazione

Una volta chì una specificazione hè obsoleta, si verificheranu i seguenti:

A specificazione ùn serà più aghjurnata.
U WG rispunsevuli saràview tutti l'errata pendenti scritte contr'à a specificazione obsoleta per determinà s'ellu si applicanu à altre specificazioni. L'errata pò esse rifiutata in u sistema di errata è riscritta contru à e specificazioni applicabili.
U WG o BSTS creerà errata per aghjurnà ogni riferenza necessaria à specificazioni obsolete in altre specificazioni.
BTI aggiornerà i documenti di prova applicabili per indicà a deprecazione di a specifica.
BSTS aghjurnà u Bluetooth SIG websitu cù una guida in quantu à specificazioni alternative à aduprà.
E nuove errate ùn ponu più esse inviate contr'à una specificazione obsoleta.
A specificazione ùn serà riferita in alcuna specificazione futura.
BSTS archivierà una versione di a specificazione marcata cum'è obsoleta per l'accessu di i membri per scopi storichi.

8.2 Ritirata

Una volta chì una specificazione hè stata ritirata, in più di e tappe chì dumandanu a deprecazione, si verificheranu i seguenti:

BTI aggiornerà i documenti di prova applicabili per indicà a ritirata di a specifica.
BSTS aghjurnà u Bluetooth SIG websitu cù una guida in quantu à specificazioni alternative à aduprà.
BSTS archivierà una versione di a specificazione marcata cum'è ritirata per l'accessu di i membri per scopi storichi.

U BoD pò sceglie di ritirà immediatamente una specificazione senza prima deprecà a specifica.

9. Processu di carta bianca

I libri bianchi sò creati à fini informativi solu. U prucedimentu di u libru biancu chì seguita s'applica à tutti i WG Bluetooth, EG, SG, è cumitati. Questa sezione ùn si applica micca à i documenti informativi per l'usu solu in u Bluetooth SIG.

Stu prucessu hè illustratu in Figura 9.1 sottu.

Prima chì qualsiasi gruppu o cumitatu cumminci à travaglià nantu à un libru biancu chì intendenu esse publicati da Bluetooth SIG, u gruppu o cumitatu preparerà sia un aggiornamentu di a carta proposta chì definisce chiaramente u cuntenutu prupostu di u libru biancu sia una presentazione di a proposta di u libru biancu.

A presentazione di a proposta di u libru biancu deve cuntene à u minimu:

A necessità di u libru biancu
Un riassuntu di i cuntenuti pruposti di u libru biancu
Una spiegazione perchè u cuntenutu ùn hè micca cunsigliatu per esse inclusu cum'è parte di una specificazione
U publicu destinatu
Ogni pianu di manutenzione (vale à dì, u tempu stimatu prima di a prossima versione di stu libru biancu pò esse necessariu)
Raccomandazioni per cume gestisce versioni precedenti di u libru biancu, se ne esiste (per esempiu, archiviu)

L'aghjurnamentu di a carta è a presentazione di a pruposta di u libru biancu deve esse presentata per BARB review. Nantu à riview è appruvazioni di l'aghjurnamentu di a carta da BARB, BSTS sottumetterà l'aghjurnamentu di a carta à u BoD per appruvazioni cù a presentazione di a pruposta di u libru biancu di sustegnu.

Se u BoD approva l'aghjurnamentu di a cartula, u gruppu o cumitatu pò prucede à sviluppà u libru biancu.

Quandu u gruppu o cumitatu hà finitu u sviluppu di u libru biancu, BSTS farà un re editorialeview per a coerenza cù e Linee di Redazione Bluetooth.

Dopu a risoluzione di i cumenti di BSTS, u gruppu deve mandà u libru biancu à BSTS per a riunione legaleview. Dopu à u cumpletu di re legaleview, u gruppu è BSTS accunsenu nantu à i feedback per esse incorporati in u libru biancu. Sè ci sò qualchi cumenti legale senza risolta da legale review nantu à u libru biancu, u presidente di u gruppu pò dumandà tempu nantu à l'agenda di u BoD per cercà l'input di u BoD nantu à a risoluzione.

In parallelu cù re legaleview, u gruppu deve sottumette u libru biancu à BARB per review. Comu parte di a so review, BARB pò ricumandemu se ogni parte di u libru biancu deve esse eliminata da u libru biancu è incorporata in una specificazione dopu à u prucessu in a Sezione 3. BARB pò ancu decide di mandà u libru biancu à altri gruppi o cumitati per re.view. À a fine di BARB review, u gruppu è BARB accunsenu nantu à i feedback per esse incorporati in u libru biancu.

Dopu chì BARB approva u libru biancu, u libru biancu appruvatu da BARB sarà presentatu da u gruppu o cumitatu di scrittura à u Cunsigliu per l'approvazione.

U prucessu di u libru biancu hè compiu quandu u BoD hà appruvatu u libru biancu è e seguenti attività dopu l'approvazione sò state compie:

BSTS hà fattu u libru biancu appruvatu publicamente dispunibule nantu à u Bluetooth SIG websitu.
BSTS informa tutti i membri di u libru biancu appruvatu.
Se u libru biancu hè un miglioramentu di un libru biancu esistente, BSTS archivierà una versione di u libru biancu per l'accessu di i membri per scopi storichi.

U Bluetooth SIG prevede di compie l'attività post-appruvazione in una settimana dopu l'approvazione di u libru biancu.

10. Referenze

I documenti Bluetooth riferiti sò dispunibuli da u Bluetooth websitu http://www.bluetooth.com.

Linee Guida di Redazzione Bluetooth (dispunibule nantu à a pagina Modelli è Documenti di u Gruppu di travagliu, à https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Statuti di Bluetooth SIG, Inc. (dispunibule nantu à a pagina di Documenti Governativi, à https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Specificazione Bluetooth Documentu di Processu Errata (dispunibule nantu à a pagina Modelli è Documenti di Gruppi di travagliu, à https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Documentu di Processu di u Gruppu di travagliu (dispunibule nantu à a pagina Modelli è Documenti di u Gruppu di travagliu, à https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Strategia di prova è Terminologia Overview document (disponibile nantu à a pagina Requisiti di u Test di Qualificazione, à https://www.bluetooth.com/specifications/qualification-test-requirements)
Specifica BTI Review Lista di verificazione di u prucessu (dispunibule nantu à a pagina Modelli è documenti di u gruppu di travagliu, à l'indirizzu https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Numeri Assignati Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Modelli è Documenti di Gruppi di travagliu (dispunibule nantu à a pagina Modelli è Documenti di Gruppi di travagliu, à https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Supplemento di Specificazione GATT (GSS) (dispunibule nantu à a pagina di Specificazioni di GATT, à https://www.bluetooth.com/specifications/gatt)
Inviate una Idea per una nova Specificazione https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Acronimi è abbreviazioni

Tabella A: Acronimi è abbreviazioni

Appendice A - Classificazione di severità Erratum

Questa appendice riassume e linee guida di classificazione di severità per un erratum di specificazione. Questa tavula serà aghjuntu à una futura revisione di l'EPD, è dopu sta sezzione serà eliminata.

Leghjite più nantu à stu manuale è scaricate PDF:

Documentu di u Processu di Gestione di e Specificazioni (SMPD) - PDF ottimizatu
Documentu di u Processu di Gestione di e Specificazioni (SMPD) - PDF originale

Dumande nantu à u vostru Manuale? Postu in i cumenti!

Referenze

Manuale d'usu