1. No category

Linee Guida per
l’integrazione in Smart
Data Net
Versione 1.3
25/07/2014
01/05/2014
06/07/2014
Versione 1.0
Versione 1.1
25/07/2014
Versione 1.2
10/09/2014
Versione 1.3
Versione iniziale del documento
Inserito capitolo 10 Riferimenti.
Corretti riferimenti incrociati a
tabelle e riferimenti.
Modifica paragrafi:
1. Introduzione
3.1 Disponibilità dei dataset e dei
flussi inviati su SDP
Modificata nomenclatura (resi
minuscoli) campi nei messaggi.
Linee Guida per
l’integrazione
Sommario
1
2
3
4
INTRODUZIONE .............................................................................................................. 3
DEFINIZIONI ED ACRONIMI .............................................................................................. 4
2.1
DEFINIZIONI
4
2.2
ACRONIMI
4
3.2
PANORAMICA DI PROTOCOLLI E FORMATI
6
3.3
TIPOLOGIE DI DATO GEOGRAFICO
6
TIPOLOGIE DI INFORMAZIONI ........................................................................................... 5 2
3.1
DISPONIBILITA’ DEI DATASET E DEI FLUSSI INVIATI SU SDP
5
SPECIFICHE PER L’INVIO DI EVENTI VERSO SDP .................................................................... 8
4.1
SPECIFICHE PER L’INVIO DEI DATI ALFANUMERICI
8
4.2
5
6
8
9
14
INTEGRAZIONE DI DATI TRAMITE IMPORT VERSO SDP ............................................................ 15
SPECIFICHE PER LA FRUIZIONE DI EVENTI ESPOSTI DA SDP ...................................................... 16
6.1
STREAMING API PER LA FRUIZIONE DI EVENTI ALFANUMERICI
16
6.2
7
PROTOCOLLO PER L’INVIO DI DATI MULTIMEDIALI
SPECIFICHE PER LA FRUIZIONE DI STREAM MULTIMEDIALI
17
REST API PER L’ACCESSO AI DATI DELLA SDP TRAMITE SERVIZI .............................................. 17
7.1
FORMATO DI RAPPRESENTAZIONE
17
7.2
BINDING DI TRASPORTO
17
7.3
SPECIFICHE DELLE API ESPOSTE
17
7.4
MODELLO DEI DATI RESTITUITO
18
SICUREZZA E PRIVACY .................................................................................................... 18
8.1
IDENTIFICAZIONE
18
8.2
AUTENTICAZIONE
18
8.3
ULTERIORI ASPETTI DI SICUREZZA
19
8.4
ASPETTI DI PRIVACY
19
APPENDICI ................................................................................................................... 21
9.1
PROTOCOLLO PER LA GESTIONE DEI SENSORI
21
9.2
AGGIORNAMENTI AUTOMATICI DEI SENSORI
25
9.3 SPECIFICHE DI DISCOVERY DEI DATASET ............................................................................. 26
10 RIFERIMENTI .................................................................................................................. 31
Linee Guida per
l’integrazione
1 INTRODUZIONE
Sono qui riportate le specifiche di integrazione con la piattaforma Regionale
per l’Internet of Smart Data che interconnette applicazioni, social network,
sistemi e oggetti distribuiti sul territorio raccogliendo dati e informazioni,
consentendone l’elaborazione e l’analisi avanzata per fornire una mappa
digitale integrata dell’ecosistema e abilitare la realizzazione di soluzioni end-toend finali.
Il documento descrive le principali specifiche tecniche e le condizioni
giuridico-legali necessarie per poter interoperare con la piattaforma
SmartDataPlatform (SDP), sia come fornitore di dati e di flussi che come fruitore
degli stessi.
Si precisa in proposito che la possibilità di interoperare con la piattaforma
SmartDataPlatform (SDP), sia come fornitore di dati e di flussi che come fruitore
degli stessi è aperta a tutti ossia non solo ai soggetti che hanno partecipato al
“Bando regionale a sostegno di progetti di ricerca industriale e/o sviluppo
sperimentale di applicazioni integrate e innovative in ambito Internet of Data –
IoD” decidendo di avvalersi delle funzionalità rese disponibili dalla piattaforma
SDP, ma anche a tutti coloro che, essendo interessati a far parte
dell’Ecosistema SmartDataNet, intendono aderirvi.
L’uso della piattafoma sarà subordinato alla compilazione di apposita
modulistica che sarà resa disponibile in fase di attivazione delle utenze di
accesso.
Tale documentazione dovrà essere pertanto letta e rispettata da tutti coloro
che fruiranno della piattaforma SDP indipendentemente dal ruolo di fornitore e
fruitore e dal titolo della partecipazione al progetto.
Per quanto concerne le specifiche tecniche, verranno descritte le quattro
modalità di integrazione previste:
1.
Invio di eventi verso SDP (tipicamente da sensori, feed social (Twitter) o
applicazioni)
2.
Invio di dataset completi su SDP
3.
Fruizione di eventi in streaming esposti da SDP
4.
Fruizione dei dati presenti nella SDP tramite servizi REST
Il documento descrive inoltre le specifiche necessarie per la gestione di sensori
e webcam che comprendono informazioni di stato e altre informazioni di
contesto (quali la localizzazione).
3
Linee Guida per
l’integrazione
2 DEFINIZIONI ED ACRONIMI
2.1 DEFINIZIONI
Gateway
Identificatore
Sensore
Osservazione
Il gateway è il componente che funziona da mediatore tra
un sensore o una SN e Internet. Nelle piattaforme IoT viene
in generale utilizzato per aggiungere tutte le funzionalità
che sono richieste per l’interfacciamento alla piattaforma e
che non possono essere fornite dai singoli sensori.
Un codice numerico/alfanumerico in grado di identificare
in modo univoco un sensore.
Un sensore è un dispositivo o una componente software
che invia una serie di osservazioni verso la piattaforma IoT
(eventualmente attraverso la mediazione del gateway).
Per osservazione si intende la rappresentazione di un
fenomeno. L’osservazione fornisce la misura di una
grandezza fisica con una serie di elementi di contesto
(quali ad esempio tempo, posizione, accuratezza).
2.2 ACRONIMI
ASN.1
BER
BSON
DASH
DER
FPS
HLS
IoT
JSON
MJPEG
NOSQL
SDP
SN
REST
RTMP
RTSP
RTP
URI
UUID
WSN
XDR
Abstract Syntax Notation One
Basic Encoding Rules
Binary JSON
Dynamic Adaptive Streaming over HTTP
Distinguished Encoding Rules
Frames Per Second
HTTP Live Streaming
Internet of Things
JavaScript Object Notation
Motion JPEG
No SQL
Smart Data Platform
Sensor Network
REpresentational State Transfer
Real Time Messaging Protocol
Real Time Streaming Protocol
Real time Transport Protocol
Uniform Resource Identifier
Universally Unique IDentifier
Wireless Sensor Network
eXternal Data Representation
4
Linee Guida per
l’integrazione
3 TIPOLOGIE DI INFORMAZIONI
La piattaforma SDP contiene le seguenti tipologie di dataset:
• dataset contenenti eventi provenuti dai sensori
• dataset contenenti eventi provenuti da Twitter
• dataset contenenti messaggi provenuti da applicazioni
• dataset frutto di elaborazioni realtime/offline interne alla piattaforma
• dataset provenienti da Data Integration con fonti esterne (quali ad
esempio opendata)
5
SDP
3.1 DISPONIBILITA’ DEI DATASET E DEI FLUSSI INVIATI SU SDP
Indipendentemente dalla natura e dalla fonte di acquisizione dei dataset e
dei flussi integrati su SDP, questi dovranno essere nella piena ed esclusiva
disponibilità del fornitore.
E’ sua esclusiva responsabilità avere infatti acquisito tutte le eventuali
autorizzazioni e consensi da soggetti terzi, necessarie ed indispensabili per
poter integrare in SDP dataset e flussi di dati.
Il fornitore sarà quindi l’unico soggetto che risponderà di eventuali
contestazioni o richieste di risarcimento danno da parte di terzi per violazione
di un qualche diritto per un uso non legittimo e/o non autorizzato dei dati.
Considerata inoltre la previsione del “Bando regionale a sostegno di progetti di
ricerca industriale e/o sviluppo sperimentale di applicazioni integrate e
innovative in ambito Internet of Data – IoD” della Regione Piemonte, in base
alla quale "i dati raccolti grazie alla piattaforma regionale abilitante potranno
sia aumentare il patrimonio informativo disponibile per le imprese
dell’ecosistema in ottica di open data (e quindi riutilizzabile per la realizzazione
di ulteriori nuove iniziative) sia arricchire il patrimonio informativo di
conoscenza disponibile per la pubblica amministrazione in ottica di
miglioramento delle politiche di governo e pianificazione" il fornitore ha la
facoltà di decidere di mettere a disposizione di tutti i fruitori di SPD dataset e
Linee Guida per
l’integrazione
flussi di dati
rielaborazioni.
utilizzati
nell'ambito
dei
progetti
nonchè loro
eventuali
Al fornitore che decide di esercitare questa facoltà si consiglia di adottare, a
propria tutela, una o più licenze che definiscano la paternità e gli usi consentiti
di dataset, flussi e loro rielaborazioni, nonchè le modalità e le condizioni che
dovranno essere rispettate da terzi in caso di creazione di eventuali lavori
derivati.
Si ricorda che le licenze adottate da Regione Piemonte per la diffusione del
proprio patrimonio informativo, in linea anche con le “Linee guida Agid per la
valorizzazione del patrimonio informativo pubblico 2014”, sono consultabili a
partire dal seguente indirizzo web:
http://www.regione.piemonte.it/urp/opendata/
La licenza/le licenze andranno pubblicate sulla piattaforma
essere chiaramente visibile a tutti i fruitori.
in modo
da
Nell'individuare la licenza con cui mettere a disposizione dataset, flussi, loro
rielaborazioni ed eventuali lavori derivati, il fornitore deve tenere conto di
eventuali diritti di terzi. Il fornitore sarà, infatti, l’unico soggetto a rispondere ad
eventuali contestazioni o richieste di risarcimento danni mosse da terzi per
violazione dei loro diritti (L. 633/41, D. lgs. 196/03 e s.m.i.).
Restano altresì nell'esclusiva responsabilità
l'attendibilità di dataset, flussi e rielaborati
del
fornitore
l'affidabilità
e
3.2 PANORAMICA DI PROTOCOLLI E FORMATI
Nell’immagine sottostante sono riassunti i principali protocolli in ingresso e in
uscita dalla piattaforma.
Nei paragrafi successivi sono dettagliate le specifiche di integrazione.
3.3 TIPOLOGIE DI DATO GEOGRAFICO
Qualora l’invio delle informazioni, sia esso tramite eventi o tramite caricamento
massivo di dataset, contenga informazioni geografiche che si intende trattare
come tali, è opportuno che esse si riferiscano al sistema di coordinate UTMWGS84.
6
Linee Guida per
l’integrazione
7
Linee Guida per
l’integrazione
4
SPECIFICHE PER L’INVIO DI EVENTI VERSO SDP
Vista la diversa natura e le diverse necessità di gestione delle informazioni
alfanumeriche rispetto alle informazioni multimediali, verranno descritti
separatamente i protocolli per l’invio dei dati in un caso rispetto all’altro.
4.1 SPECIFICHE PER L’INVIO DEI DATI ALFANUMERICI
8
Rientrano in questa categoria gli eventi provenienti dalle seguenti fonti:
1. Sensori o reti di sensori
2. Applicazioni
3. Feed Social (Twitter)
Gli eventi provenienti dai Feed Social (Twitter) saranno direttamente recuperati
dalla piattaforma, a fronte di una configurazione opportuna. Non vengono
quindi descritte nel seguito le specifiche di interazione tra SDP e la piattaforma
social.
4.1.1
Modello dei dati
Viene descritto nel seguito il modello dati per le interazioni provenienti dalle
applicazioni che intendono colloquiare con la piattaforma e successivamente
viene descritto un modello per gli eventi provenienti dai sensori.
Questa separazione nasce dall’idea che un’applicazione invia alla
piattaforma Eventi di Business, mentre un sensore invia misure di grandezze
fisiche.
4.1.2
Modello dei dati per le applicazioni
Un’ applicazione che invia dati alfanumerici numerici alla SDP (messaggi)
genera un flusso di dati. A questo flusso vengono associati alcuni meta-dati
che sono rappresentati in Tabella 1.
Tale flusso trasporta eventi di business omogenei e rilevanti per l’applicazione.
Dato che un’ applicazione può pubblicare diversi tipi di messaggi (ossia diversi
flussi) è opportuno che a ciascun flusso dati (Stream) sia associato un
identificatore che è locale alla applicazione.
Attributo
id
application
description
tags
visibility
Descrizione
Tipo
Identificatore del flusso (univoco solo per Stringa
una applicazione)
Identificatore dell’applicazione
Stringa (7.1)
Descrizione libera
Stringa
Tag utili per la ricerca
Vettore
stringhe
Visibilità del flusso
“public”
“private”
di
Linee Guida per
l’integrazione
Attributo
domain
license
disclaimer
copyright
components
Descrizione
Il nome di un progetto/consorzio/network
di appartenenza del flusso
Tag Creative Commons che identifica la
licenza sottoposta al flusso
(e. “CC0 1.0”, “CC BY 4.0”)
Dichiarazione
di
limitazione
di
responsabilità
Nota di copyright
Un vettore che contiene la descrizione di
tutte le componenti del flusso
Tabella 1- Oggetto Stream
Tipo
Stringa
Stringa
Stringa
Stringa
Vettore
oggetti
Component
di
Nella descrizione di un flusso (Stream) è opportuno riportare un elenco di
componenti (Component) che collettivamente forniscono la rappresentazione
di un evento di business (Business Event).
Per esempio l’evento di invio di un ordine può contenere diverse informazioni
(componenti) quali identificativo dell’ordine, la quantità ordinata, il tipo di
oggetto, il destinatario etc…
L’approccio usato permette di associare meta dati anche alle singole
componenti (Tabella 2).
Attributo
id
event
type
Descrizione
Identificatore della componente
Nome dell’attributo
Permette di risalire al dominio del dato
(ad esempio numeri reali, interi positivi,
enumerazione e stringhe)
Tabella 2- Oggetto Component
Tipo
Stringa
Stringa
Uno tra: int,
long,
double,
float,
string,
boolean
L’invio dei messaggi deve permettere di ricostruire l’associazione con i
metadati del flusso. Per questo motivo ogni messaggio riporta l’identificatore
del flusso e del applicazione cui si riferisce.
Per poter gestire ogni tipo di situazione (invio di singoli eventi complessi o invio
”batch” di eventi complessi) nell’invio di un messaggio (Message) è possibile
specificare un elenco di valori (Tabella 3).
Attributo
stream
application
values
Descrizione
Identificatore del flusso
Identificatore dell’applicazione
Valori da inviare
Tabella 3- Oggetto Message
Tipo
Stringa
Stringa
Vettore
di
oggetti Business
Event
9
Linee Guida per
l’integrazione
Infine ogni singolo Business Event riporta i valori di tutte le componenti (Tabella
4).
Attributo
time
Descrizione
Data e ora dell’evento di business
components
I valori associati alle diverse componenti
Tabella 4- Oggetto Business Event
Tipo
Stringa
([ISO8601])
Mappa
associativa
in
cui la chiave è
l’id
del
componente e
il valore è il
valore
dell’attributo di
interesse
4.1.3
Modello dei dati per gli eventi provenienti da sensori
L’approccio è simile a quello sopra descritto, con la presenza di campi
obbligatori aggiuntivi tipici di strumenti atti ad effettuare misure. Tali differenze
sono evidenziate con la sottolineatura.
Le classi del modello ottengono nomi specifici con la seguente mappatura:
Dati provenienti da applicazioni
Metadata
Metadata
Metadata
Runtime
data
Runtime
data
Stream
Component
Application
Message
Dati provenienti da
sensori
Stream
Component
Sensor
Observation
Business Event
Measure
Un sensore che invia dati numerici alla SDP (osservazioni) genera un flusso di
dati. A questo flusso vengono associati alcuni meta-dati che sono
rappresentati in Tabella 5.
Dato che un gateway o uno smart sensor possono pubblicare diversi tipi di
misure (si pensi ad esempio una centralina meteo) è opportuno che a ciascun
flusso dati (Stream) sia associato un identificatore che è locale al
sensore/gateway.
10
Linee Guida per
l’integrazione
Attributo
id
sensor
description
tags
visibility
fps
domain
license
disclaimer
copyright
components
Descrizione
Tipo
Identificatore del flusso (univoco solo per Stringa
un dato sensore)
Identificatore del sensore
Stringa (7.1)
Descrizione libera
Stringa
Tag utili per la ricerca
Vettore
stringhe
Visibilità del flusso
“public”
“private”
Associando al concetto di frame una Numero
singola osservazione, questo parametro
(condiviso anche con i flussi multimediali)
permette
di
dare
evidenza
della
frequenza di acquisizione della misura
Il nome di un progetto/consorzio/network Stringa
di appartenenza del flusso
(e. “MeteoNetwork”)
Tag Creative Commons che identifica la Stringa
licenza sottoposta al flusso
(e. “CC0 1.0”, “CC BY 4.0”)
Dichiarazione
di
limitazione
di Stringa
responsabilità
Nota di copyright
Stringa
Un vettore che contiene la descrizione di Vettore
tutte le componenti del flusso
oggetti
Component
di
11
di
Tabella 5 Oggetto Stream
Nella descrizione di un flusso (Stream) è opportuno riportare un elenco di
componenti (Component) che collettivamente forniscono la rappresentazione
di una misura complessa (Measure). Ad esempio un accelerometro che dal
punto di vista logico genera un solo flusso in cui ciascun valore è composto da
tre elementi: il valore delle accelerazioni sui tre assi.
Linee Guida per
l’integrazione
L’approccio usato permette di associare meta dati anche alle singole
componenti, importante per identificare l’unità di misura e la tolleranza
(Tabella 6)
Attributo
id
unit
allowance
event
type
Descrizione
Identificatore della componente (univoco
solo all’interno della misura)
Unità di misura
Tolleranza espressa come valore assoluto
dell’errore sulla misura
Tipo di fenomeno misurato
(e. “Wind Speed”)
Permette di risalire al dominio del dato (ad
esempio numeri reali, interi positivi,
enumerazione e altri)
Tabella 6- Oggetto Component
Tipo
Stringa
Stringa
Numero
Stringa
Uno
tra:
int,
long,
double,
float,
string,
boolean
L’invio delle osservazioni (valori delle misure) deve permettere di ricostruire
l’associazione con i metadati del flusso. Per questo motivo ogni misura riporta
l’identificatore del flusso e del sensore cui si riferisce.
Per poter gestire ogni tipo di situazione (sensori real-time o data logger che si
sincronizzano periodicamente) nell’invio di una osservazione (Observation) è
possibile specificare un elenco di valori (Tabella 7).
Attributo
stream
sensor
values
Descrizione
Identificatore del flusso
Identificatore del sensore
Valori letti
Tabella 7- Oggetto Observation
Tipo
Stringa
Stringa
Vettore
di
oggetti Measure
Infine ogni singola misura riporta i valori di tutte le componenti (Tabella 8).
Occorre notare che il campo Validity è una informazione che generalmente
non deve essere fornita dal sensore, ma viene impostato dalla SDP sulla base
di alcuni algoritmi di elaborazione; tuttavia è possibile che un sensore sia
abbastanza intelligente da effettuare minimi controlli di validità sui valori
acquisiti e rendere nota questa informazione alla SDP.
12
Linee Guida per
l’integrazione
Attributo
time
Descrizione
Data e ora della misura
components
I valori associati alle diverse componenti
validity
Validità della misura
Tipo
Stringa
([ISO8601])
Mappa
associativa
in
cui la chiave è
l’id
del
componente e il
valore
è
la
misura
“valid”
“erroneous”
“doubtful”
“unknown”
Tabella 8- Oggetto Measure
4.1.4
Formati di rappresentazione
Per la serializzazione il protocollo oggetto di questa specifica supporta sia JSON
che BSON.
4.1.5
Binding di trasporto
L’invio di Observation (sensori) e Message (applicazioni) può avvenire su http e
su MQTT.
4.1.6
HTTP
Nell’invio, l’oggetto viene inviato come parte di una richiesta POST e la risposta
del server è vuota.
In presenza di invii da sensori e di aggiornamenti al firmware che interessano il
gateway o lo smart sensor. In tal caso viene restituito l’oggetto descritto in 6.1
(piggybacking).
HTTP/1.1 200 OK
Content-type: text/json
{
}
Version: “1.1c”,
URL: “http://<host>/data.zip”,
Hash: “3ea4c8f57b985435d2f2ca9b5ff99e8a”,
Size: 101310,
Time: “2014-05-12T06:27:36Z”,
Priority: “Critical”,
Requirement: “1.0”
13
Linee Guida per
l’integrazione
4.1.7
MQTT
In questo caso il soggetto che invia messaggi si deve connettere alla coda
come publisher. Essendo questo trasporto privo di risposta, non è possibile
realizzare l’ottimizzazione che in HTTP consente di ricevere eventuale
informazione sulla presenza di nuovi aggiornamenti per i sensori/gateway;
tuttavia in MQTT è possibile sottoscriversi ad un topic dedicato per ottenere le
notifiche di aggiornamento.
4.2 PROTOCOLLO PER L’INVIO DI DATI MULTIMEDIALI
In relazione ai flussi multimediali, la presente specifica si basa principalmente
sulle funzionalità offerte dai prodotti disponibili sul mercato e in modo
particolare dalle videocamere IP utilizzate nell’ambito della video sorveglianza
pubblica e domestica.
4.2.1
Formati di codifica
Nonostante vi siano innumerevoli formati per la codifica audio/video, la
maggior parte delle videocamere IP supporta i formati che più
economicamente è possibile trovare implementati nei microprocessori
dedicati permettendo di mantenere bassi i consumi e il costo finale del
prodotto:
•
•
MPEG-4 Part 10/AVC Baseline/Main Profile (H.264)
Motion JPEG
4.2.2
Protocolli di streaming
I modelli più vecchi di webcam IP utilizzano unicamente il protocollo http per il
trasporto di un flusso MJPEG. Il live viene realizzato attraverso un polling del
client (tipicamente una applicazione Javascript in un browser) o sfruttando il
modello http-push. Tutti i prodotti in grado di supportare la codifica H.264
implementano il protocollo RTSP per distribuire il flusso live verso il client. Pur
esistendo protocolli di streaming innovativi e meglio integrati all’interno delle
piattaforme mobile e browser (quali ad esempio HLS, DASH e RTMP) in questa
specifica i flussi video devono essere messi a disposizione della piattaforma
con le seguenti modalità:
•
•
La webcam deve mettere a disposizione un server RTSP ([RTSP]) che
deve essere raggiungibile dalla SDP;
La webcam deve mettere a disposizione un server http che deve essere
raggiungibile dalla SDP per ricevere le immagini secondo il protocollo
HTTP push (4.2.1).
14
Linee Guida per
l’integrazione
4.2.3
http push
In generale per http-push si intende un modello attraverso il quale un server
manda un contenuto non sollecitato dal client (ovvero non in risposta ad una
esplicita richiesta). Essendo un modello può essere realizzato con diverse
tecnologie, tuttavia ai fini della presente specifica ci si riferisce all’utilizzo di un
oggetto MIME introdotto da Netscape e che quasi tutte le webcam IP
supportano per distribuire i flussi MJPEG.
SDP -> Webcam
GET /path/to/mjpeg/stream HTTP/1.1
Webcam -> SDP
HTTP/1.1 200 OK
Content-Type: multipart/x-mixed-replace;boundary=--MYBOUNDARY
<empty line>
Ricevendo il contenuto x-mixed-raplace il client sa che non deve essere chiusa
la connessione HTTP e resta in attesa di nuovi aggiornamenti della risorsa (in
questo caso si tratta di immagini JPEG).
Sulla base del frame rate, ogni volta che la webcam dispone di una nuova
immagine, invia sulla connessione HTTP attiva il nuovo aggiornamento come
descritto nell’esempio.
Webcam -> SDP
--MYBOUNDARY
Content-Type: image/jpeg
<empty line>
<JPEG bytes>
--MYBOUNDARY
Content-Type: image/jpeg
<empty line>
<JPEG bytes>
...
5 INTEGRAZIONE DI DATI TRAMITE IMPORT VERSO SDP
E’ possibile importare in modalità batch sulla piattaforma dataset nei formati
più comuni: CSV, Excel, Dump di DB relazionali.
15
Linee Guida per
l’integrazione
6 SPECIFICHE PER LA FRUIZIONE DI EVENTI ESPOSTI DA SDP
Vista la diversa natura e le diverse necessità di gestione delle informazioni
alfanumeriche rispetto alle informazioni multimediali, verranno descritti
separatamente le specifiche per l’invio dei dati in un caso rispetto all’altro.
6.1 STREAMING API PER LA FRUIZIONE DI EVENTI ALFANUMERICI
La piattaforma SDP consente la fruizione degli eventi in modalità “stream”.
Diversamente dalle API REST, descritte nel capitolo successivo, che prevedono
un’interazione request-response, nel caso di fruizione in modalità “stream” il
fruitore si sottoscrive ad flusso di informazioni e viene notificato dalla
piattaforma a fronte di un nuovo evento (modalità publish-subscribe).
Esistono due tipologie di sottoscrizione:
1. Sottoscrizione di un endpoint “server”: in questo caso è necessario
dichiarare preventivamente e staticamente l’endpoint sottoscritto. In
questo scenario la piattaforma richiama l’endpoint fornendo le
informazioni dell’evento generato sul flusso sottoscritto (Event Streaming
push) .
2. Sottoscrizione di un endpoint “client”: in questo caso il fruitore è
tipicamente un client “finale” e effettua una sottoscrizione richiamando
un API specifica e, attende le informazioni relative ai nuovi eventi (Event
Streaming API).
6.1.1
Modello dei dati
Il modello dati rispecchia il modello degli eventi ricevuti dalla piattaforma, con
eventuale aggiunta di campi calcolati da elaborazioni realtime eseguite sulla
stessa.
6.1.2
Event Streaming push
6.1.3
JSON/XML over HTTP
Il formato di rappresentazione fornito è JSON o XML. L’endpoint da richiamare
deve essere censito sulla piattaforma indicandone l’url e il formato richiesto
(JSON o XML).
6.1.4
Soap-Event over http
Il formato di rappresentazione fornito è SOAP. L’endpoint da richiamare deve
essere censito sulla piattaforma indicandone l’url.
16
Linee Guida per
l’integrazione
6.1.5
Event Streaming API
6.1.6
STOMP over WebSocket
Il formato di rappresentazione del payload fornito è JSON.
Il protocollo di comunicazione utilizzato è WebSocket.
In questo scenario la piattaforma non consentirà la pubblicazione di eventi da
parte del client, ma solo la sottoscrizione e ricezione.
6.1.7
JSON over MQTT
Il formato di rappresentazione del payload fornito è JSON.
Il protocollo di comunicazione utilizzato è MQTT.
In questo scenario la piattaforma non consentirà la pubblicazione di eventi da
parte del client, ma solo la sottoscrizione e ricezione.
6.2 SPECIFICHE PER LA FRUIZIONE DI STREAM MULTIMEDIALI
La piattaforma SDP espone gli stream multimediali secondo il formato webM.
7 REST API PER L’ACCESSO AI DATI DELLA SDP TRAMITE SERVIZI
Nel presente capitolo sono descritte le specifiche relative alle REST API per la
fruizione dei dati immagazzinati in SmartDataPlatform (SDP).
Le REST API consentono la fruizione omogena di tutti i dati, permettendone
inoltre la discovery.
7.1 FORMATO DI RAPPRESENTAZIONE
Il formato di rappresentazione fornito è JSON o XML.
E’ possibile scegliere il formato di output valorizzando opportunamente la url di
richiamo.
7.2 BINDING DI TRASPORTO
Le API sono esposte tramite protocollo http o https.
7.3 SPECIFICHE DELLE API ESPOSTE
Le API di interrogazione consentono, dato un dataset di interesse, di ricercare
e recuperare le informazioni presenti.
Le specifiche implementate rispettano le specifiche OData in versione 2 per
entità non aggiornabili.
17
Linee Guida per
l’integrazione
7.4 MODELLO DEI DATI RESTITUITO
Il modello dati rispecchia le scelte ed è compatibile con le regole previste nel
portale opendata dati.piemonte.it. Particolare attenzione è stata data a
recepire le best practice presenti nello standard OData.
8 SICUREZZA E PRIVACY
8.1 IDENTIFICAZIONE
L’identificazione univoca dei sensori deve essere fatta utilizzando uno
Universally Unique Identifier (UUID). Si tratta di un numero su 128bit che
attraverso specifici algoritmi di generazione viene garantito univoco nello
spazio e nel tempo ([UUID]). In particolare questo numero su 128 bit deve
essere rappresentato nella sua forma canonica attraverso 32 caratteri
esadecimali e minuscoli (8-4-4-4-12) come nel seguente esempio:
550e8400-e29b-41d4-a716-446655440000
8.2 AUTENTICAZIONE
Tutte le comunicazioni che vanno verso la piattaforma devono contenere le
informazioni che consentano alla piattaforma di autenticare la sorgente.
Tale paradigma si applica quindi ai messaggi provenienti dai sensori o feed, e
alle richieste effettuate tramite REST API o Streaming API.
La SDP mette a disposizione l’autenticazione basic (ovvero quella basata
sull’invio di username e password).
In versioni successive i client potranno opzionalmente utilizzare il protocollo
OAuth 2.0 ([OAUTH]).
I paragrafi successivi descrivono come devono essere passate le credenziali
necessarie all’autenticazione sulla base del trasporto utilizzato (MQTT e HTTP).
8.2.1
Autenticazione su MQTT
L’autenticazione su MQTT avviene inserendo username e password negli
appositi campi previsti dal protocollo nella fase di connessione.
8.2.2
Variante OAuth
Nella variante OAuth 2.0 il sensore deve inviare unicamente il valore del token
di accesso all’interno del campo destinato alla password, mentre nel campo
username occorre inserire la stringa “OAuth Bearer” come indicato
nell’esempio di Tabella 9.
Campo
Username
Password
Valore
OAuth Bearer
mF_9.B5f-4.1JqM
Tabella 9- Bearer token OAuth 2.0 su MQTT
18
Linee Guida per
l’integrazione
8.2.3
Autenticazione su http
Su HTTP occorre utilizzare la Basic Authentication come specificato in [HTTPA].
8.2.4
Variante OAuth
Nella variante OAuth 2.0, il token deve essere inviato utilizzando l’header
Authorization ([BEARER]) come nel seguente esempio.
POST /path/to/endpoint HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM
Content-type: text/json
{
}
“stream”: “thermo_a”
“sensor”: “550e8400-e29b-41d4-a716-446655440000”,
“values”: [
{
“time”: “2014-05-13T17:08:58+0200”,
“components”: { “temp”: ”12.4” }
},
{
“time”: “2014-05-13T17:10:39+0200”,
“components”: { “temp”: ”256” },
“validity”: “erroneous”
}
...
],
8.3 ULTERIORI ASPETTI DI SICUREZZA
Sia il protocollo HTTP che MQTT possono essere veicolati su SSL/TLS ([TLS]).
La SDP può offrire questo protocollo nella configurazione che prevede
l’autenticazione del server e la sicurezza del canale attraverso cifratura.
8.4 ASPETTI DI PRIVACY
Tutti i dati che vanno verso la piattaforma e che identificano o possono
identificare anche indirettamente, mediante riferimento a qualsiasi altra
informazione, una “persona fisica”, sono, a tutti gli effetti di legge, dei “dati
personali” ai sensi del D.Lgs. 196/2003, Codice in materia di protezione dei dati
personali.
In tal caso, si ricorda che al Fornitore spettano, in qualità di Titolare autonomo
del trattamento dei dati forniti, tutti gli adempimenti finalizzati ad ottemperare
alla normativa in materia di privacy (informative, acquisizione di consensi da
parte degli interessati, eventuali nomine, notificazioni, verifiche preliminari,
adozione di idonee misure di sicurezza ecc.).
19
Linee Guida per
l’integrazione
Non sono soggetti agli adempimenti previsti dal Codice in materia di
protezione dei dati personali solo i trattamenti di dati personali “anonimi", dati
che in origine, o a seguito di tecniche di anonimizzazione, non possono essere
associati in modo univoco ad una persona fisica identificata o identificabile.
20
Linee Guida per
l’integrazione
9 APPENDICI
9.1 PROTOCOLLO PER LA GESTIONE DEI SENSORI
9.1.1
Modello dei dati
Per poter inviare dei dati o dei flussi alla SDP, è necessario che il sensore sia
rappresentato all’interno della piattaforma.
Il sensore è in generale un oggetto in grado di interagire direttamente con la
piattaforma, attraverso le interfacce di invio dei dati (le quali sono descritte
nelle sezioni 3 e 4).
In Tabella 10 sono riportati i principali attributi che compongono la descrizione
di un generico sensore. Occorre notare che ai fini della presente specifica,
vengono volutamente omessi da tale tabella tutti gli attributi che vengono
generati dalla piattaforma e che servono per la gestione del sensore stesso.
Attributo
id
name
model
location
description
category
supply
management
status
version
Descrizione
Un identificatore del sensore
Nome descrittivo del sensore
(e. “Centralina Meteo Ciardoney”)
Nome del modello
(e.
“Campbell
GRWS100”,
TrafficConter”)
Posizione del sensore
Tipo
Stringa (7.1)
Stringa
“CSP
Stringa
Oggetto:
Location
(Tabella 6)
Descrizione libera
Stringa
Categoria di appartenenza del sensore.
“Gateway”
“Webcam”
“Smart”
Serve a capire se il sensore è dotato di “Auto”
alimentazione autonoma (e. batteria “Network”
ricaricata con pannelli solari) o se è
collegato alla rete elettrica
La URI che punta all’interfaccia di Stringa (URI)
amministrazione del sensore
Stato del sensore
“Active”
“Unactive”
Versione del software o del firmware
Stringa
Tabella 10- Modello dei dati che rappresenta un generico sensore
21
Linee Guida per
l’integrazione
Attributo
disposition
exposure
positions
Descrizione
Permette di capire se si tratta di un
dispositivo mobile o meno.
Permette di capire se si tratta di un
sensore installato in esterno oppure no.
Elenco delle posizioni
Tabella 11- Oggetto Location
Attributo
lat
lon
ele
time
building
floor
room
Descrizione
Latitudine in gradi
Longitudine in gradi
Altezza in metri
Data e ora della posizione
Struttura che ospita il sensore
Piano in cui è collocato il sensore
Stanza che ospita il sensore
Tabella 12- Oggetto Position
Tipo
“Fixed”
“Mobile”
“Indoor”
“Outdoor”
Vettore
di
oggetti
Position (Tabella 7)
Tipo
Numero reale
Numero reale
Numero reale
Stringa ([ISO8601])
Stringa
Numero intero
Stringa
22
Linee Guida per
l’integrazione
9.1.2
Webcam
Le webcam richiedono ulteriori informazioni che sono legate alle
caratteristiche con cui sono in grado di riprendere una scena (Tabella 13)
Attributo
Descrizione
Tipo
url
URL che permette di accedere al Stringa (URL)
flusso.
(e. “rtsp://<indirizzo_ip>/stream_0”)
username
Utente per accesso in lettura al flusso
Stringa
password
Password per accesso in lettura al flusso Stringa
resolution
Risoluzione dell’immagine
Stringa (“WxH”)
pan
tilt
zoom
ptz
codec
type
infrared
Angolo orizzontale rispetto al nord in
senso antiorario
Angolo rispetto al piombo (asse
verticale)
Zoom ottico (passo di zoom)
La
webcam
può
cambiare
orientamento in quanto dotata di
motori oppure può avere una staffa
fissa.
Il codec video utilizzato dalla webcam
(e. “H264”, “MJPEG”, “VP8”)
Tipo di webcam
Numero naturale
360)
Numero naturale
180)
Intero
“Present”
“Not-Present”
(0(0-
Stringa
“normal”
“termo”
La webcam dispone di un illuminatore “present”
infrarosso
“not-present”
Tabella 13- Attributi aggiuntivi per le webcam
9.1.3
Formato di rappresentazione
Per formato di rappresentazione si intende il formalismo con cui gli oggetti
descritti in questa interfaccia vengono serializzati e scambiati tra
sensore/gateway e la SDP.
Le applicazioni conformi alla presente specifica, devono supportare due
formati di rappresentazione:
•
•
JSON
BSON
9.1.3.1 JSON
JSON (JavaScript Object Notation) è un formato testuale per lo scambio di
dati ([JSON]). A differenza dei linguaggi XML presenta una sintassi
specificatamente orientata alla rappresentazione di strutture dati tipiche dei
moderni linguaggi di programmazione. In particolare la sintassi di JSON è
23
Linee Guida per
l’integrazione
basata su un sottoinsieme del linguaggio di programmazione JavaScript
([ECMA]). Oltre ad essere più compatto rispetto ad XML resta allo stesso tempo
leggibile dalle persone e parsificabile in modo efficiente da parte del software.
Il seguente esempio mostra la rappresentazione di una centralina meteo posta
sul ghiacciaio del Ciardoney.
{
}
“id”: “550e8400-e29b-41d4-a716-446655440000”,
“name”: “Centralina Meteo Ciardoney”,
“model”: “Campbell GRWS100”,
“location”: {
“disposition”: “fixed”,
“exposure”: “outdoor”,
“positions”: [
{ “lat”: 45.521439, “lon”: 7.407167, “ele”: 2850 }
]
},
“category”: “smart”,
“supply”: “auto”,
“owner”: “http://www.nimbus.it/”,
9.1.3.2 BSON
BSON (Binary JSON) è una specifica finalizzata a rappresentare un oggetto
JSON in forma binaria, sfruttando i tipi di base che esistono nel linguaggio di
programmazione C ([BSON]). Si tratta del formato utilizzato da MongoDB: un
database NOSQL orientato ai documenti JSON e che usa un sotto insieme del
linguaggio JavaScript per l’esecuzione di query. Rispetto ad altri formati binari
standard (quali ad esempio ASN.1 DER/BER e XDR), compreso il recente
Protocol Buffers di Google 1, ha caratteristiche di restare un formato privo di
schema.
Il formato BSON può essere utilizzato da sensori autonomi, basati su
microcontrollori tipo Arduino o Microchip, dove è importante mantenere al
minimo non solo la complessità del codice ma anche la sua occupazione in
memoria.
Un formato compatto come BSON permette anche l’uso ottimale delle code
distribuite a bassa latenza per il trasporto di tali oggetti (come ad esempio
MQTT).
9.1.4
Binding di trasporto
9.1.5
http
La SDP mette a disposizione una API accessibile attraverso il protocollo HTTP e
che permette la creazione e la manipolazione degli oggetti che
1
https://developers.google.com/protocol-buffers/
24
Linee Guida per
l’integrazione
rappresentano lo stato di sensori e webcam. Il modello di questi dati è
specificato nella paragrafi 5.1.
Tale API segue il modello REST, dove la rappresentazione dello stato dei sensori
e delle webcam si basa sul modello dei dati e sui formati di codifica descritti
nei paragrafi 5.1 e 5.2 rispettivamente.
Nello specifico gli oggetti verranno inviati dal server verso la piattaforma come
parte di una richiesta POST, mentre i dati in lettura (dalla piattaforma verso il
client) vengono restituiti come parte della risposta.
9.1.6
MQTT
La SDP mette a disposizione un server MQTT che può essere utilizzato da uno
smart sensor o da un gateway per annunciare i sensori e pubblicare
aggiornamenti di stato.
Il corpo del messaggio MQTT contiene gli oggetti descritti nel modello (5.1) i
quali possono essere serializzati in forma testuale o binaria come descritto in
5.2.
9.2 AGGIORNAMENTI AUTOMATICI DEI SENSORI
Smart sensor e gateway devono implementare una interfaccia che permette
alla SDP di effettuare l’aggiornamento automatico del software (o del
firmware).
9.2.1
Modello dei dati
Il modello dei dati per la segnalazione degli aggiornamenti (Tabella 14)
fornisce le informazioni che possono permettere al gateway o allo smart sensor
di applicare diverse politiche di gestione degli aggiornamenti.
Attributo
version
url
hash
Descrizione
Versione del firmware o del software
URL da cui scaricare il firmware
Hash SHA1
size
time
priority
Dimensione in byte
Data e ora di pubblicazione
Priorità dell’aggiornamento
requires
Versione minima cui è
applicare l’aggiornamento
Nome che identifica il modello cui si Stringa
applica l’aggiornamento
model
Tipo
String
Stringa (URL)
Stringa
(numero
esadecimale)
Numero
Stringa ([ISO8601])
“critical”
“optional”
possibile Stringa
Tabella 14- Notifica di aggiornamento
25
Linee Guida per
l’integrazione
9.2.2
Formato di rappresentazione
Per la serializzazione il protocollo oggetto di questa specifica supporta sia JSON
che BSON come descritto in 5.2.
9.2.3
Binding di trasporto
I messaggi di notifica per gli aggiornamenti automatici possono essere
veicolati sia su HTTP che su MQTT (vedi 5.3).
9.2.4
MQTT
Quando si utilizza MQTT il sensore (o gateway) deve sottoscriversi ad uno
specifico topic per ricevere l’informazione.
9.2.5
HTTP
Se il sensore implementa il trasporto HTTP, deve effettuare un polling periodico
ad una specifica URL che per il modello richiesto fornisce i dati relativi
all’aggiornamento più recente.
Per maggiore flessibilità e ottimizzazione, il sensore che invia i dati in
piattaforma utilizzando il trasporto HTTP può ricevere, come parte della
risposta, l’informazione sugli aggiornamenti (3.3.1).
9.2.6
Webcam
La maggior parte delle webcam offre un sistema di aggiornamento del
firmware, tuttavia non c’è la convergenza verso un protocollo unificato.
L’indicazione di massima che viene fornita per accedere alle funzioni di
aggiornamento automatico è quella di utilizzare prodotti in grado di offrire tale
funzione attraverso una interfaccia web.
In questi casi l’interfaccia deve essere resa raggiungibile dalla SDP in modo da
poter riuscire ad effettuare in automatico gli aggiornamenti, sviluppando
specifici adattatori sulla base del modello di webcam utilizzato.
9.3 SPECIFICHE DI DISCOVERY DEI DATASET
9.3.1
Introduzione
La piattaforma sarà dotata di un sito divulgativo che consente la ricerca e la
sottoscrizione, in un’ ottica marketplace, dei dataset disponibili.
In aggiunta a tale possibilità, la piattaforma espone una serie di REST API che
consentono l’esplorazione dei dataset disponibili, con un sottoinsieme di api
conformi allo standard CKAN.
9.3.2
Formato di rappresentazione
Il formato di rappresentazione fornito è JSON.
9.3.3
Binding di trasporto
Le API sono esposte tramite protocollo HTTP.
26
Linee Guida per
l’integrazione
9.3.4
Modello dei dati
In accordo con la nomenclatura CKAN le classi oggetto dalle API REST di
discovery sono:
9.3.5
Package
Il Package corrisponde al dataset, ed è l'oggetto principale di tutto il sistema;
esso rappresenta un insieme coerente di dati appartenenti alla stessa natura.
Per esempio le osservazioni che giungono alla piattaforma da un insieme di
sensori identici utilizzati all’interno di un progetto fanno parte di un Package.
Formato:
{
}
“id” : id,
“name” : name,
“title” : title,
“version” : version,
“url” : url,
“resources” : [Resource1, Resource2, ...],
“author” : author,
“author_email” : author_email,
“maintainer” : maintainer,
“maintainer_email” : maintainer_email,
“license_id” : license_id,
“tags” : Tag - List,
“notes” : notes,
“extras” : {
name : value,
...
}
Nella tabella sottostante sono riportati i dettagli dei vari attributi.
Attributi dell'oggetto
Nome attributo
Tipo attributo
id
String
name
String
title
version
url
String
String
String
resources
Resource
Note
Identificativo del package
Identificativo del package interno al
portale riuso
Titolo del package
Versione del package
Url della pagina web in cui sono
descritti i metadati del package
Elenco di oggetti di tipo Resource
collegati al package
27
Linee Guida per
l’integrazione
Attributi dell'oggetto
Nome attributo
Tipo attributo
author
String
author_email
String
maintainer
String
maintainer_email String
license_id
String
tags
Tag-List
notes
extras
String
String
Note
Proprietario del package
Riferimento email del proprietario del
package
Gestore
o
responsabile
della
pubblicazione del package
Riferimento email del gestore o
responsabile della pubblicazione del
package
Identificativo della licenza a cui è
assoggettato l'utilizzo del package (ad
esempio “cc-by”)
Oggetto di tipo Tag-List.
Contiene i name dei Tag associati al
package
Ulteriori informazioni sul package
Attributi aggiuntivi del package,
costituiti da un elenco di coppie
Name: Value, dove Name è il nome
dell'attributo e
Value
il
valore
corrispondente. Il numero delle coppie
non ha un limite massimo.
L’informazione relativa alla provenienza del dato è presente sotto forma di tag
aggiuntivo scelto tra:
• sensor_data
• social_data
• elaborated_data
• imported_data
9.3.6
Package-List
Il Package-List contiene un elenco di identificativi di Package, che si riferiscono
ad oggetti di tipo Package.
Formato:
[ Id_1, Id_2, Id_3, ... , Id_n]
Id_n indica l'identificativo del Package n ed è una stringa.
9.3.7
Tag
Un Tag rappresenta una parola chiave ed ha significato se riferita ad un
Package. Un Package può essere relazionato a più Tag.
Formato:
{ “name”: name }
dove “name” indica il nome del Tag.
28
Linee Guida per
l’integrazione
9.3.8
Tag-List
Il Tag-List rappresenta un elenco di Tag, con indicazione del numero di
Package relazionati con ciascuno di essi.
Formato:
[ [ name, n], [name, n], …...., [name, n] ]
dove “name” indica il campo name del Tag e “n” indica il numero di Package
relazionati con quel Tag.
9.3.9
Resource
L'oggetto Resource contiene le informazioni per raggiungere il dato vero e
proprio, descritto attraverso il Package.
Il Resource corrisponde ad un file, un endpoint di un’ API o ad un'altra risorsa di
dati disponibile on line.
Un Resource è sempre collegato ad un Package (o Dataset), che può avere
più Resources associati.
Formato:
{
“id” : id,
“url” : url,
“format” : format,
“description” : description,
“hash” : hash,
“package_id” : package_id
}
Nella tabella sottostante sono riportati i dettagli dei vari attributi.
Attributi dell'oggetto
Nome attributo
Tipo attributo
Note
id
String
Identificativo del Resource
url
String
Url che consente di raggiungere la location
in cui la risorsa è effettivamente disponibile.
format
String
Formato della risorsa (ad esempio zip, csv,
api,...).
description
String
Descrizione della risorsa
hash
String
Hash
package_id
String
Identificativo del Package a cui il Resource
si riferisce
29
Linee Guida per
l’integrazione
9.3.10
Specifiche delle API esposte
Di seguito le API Rest che consentono l’interrogazione della piattaforma al fine
di recuperare le informazioni relative ai dataset (package) disponibili
(discovery).
9.3.11
Elenco Package
Consente di estrarre l'elenco degli identificativi di tutti i Package presenti nel
repository.
Input
http://{endpoint}/servizi/api/explore/package
Output
Il metodo restituisce in output un oggetto di tipo Package-List, ossia un elenco
di identificativi di Package.
9.3.12
Package by Id
Consente di estrarre le informazioni complete di un Package relativo ad uno
specifico identificativo.
Input
http://{endpoint}/it/servizi/api/explore/package/[id]
dove [Id] è l’identificativo di uno specifico Package.
Output
Il metodo restituisce in output un oggetto di tipo Package.
9.3.13
Package Search
Consente di ricercare un elenco di identificativi di Package.
Input
http://{endpoint}/servizi/api/explore/package?q=[tag]
Output
La risposta al metodo è strutturata nel seguente modo:
{ “count”: Count-int, “results”:[Id_Package, Id_Package, …] }
dove Count-int è il numero di Packages estratti e Id_Package è l'identificativo
del Package.
9.3.14
Tag Counts
Consente di estrarre l'elenco dei tag con indicazione del numero di Packages
relazionati con ciascuno di essi.
Input
http://{endpoint}/servizi/api/explore/tag_counts
Output
Il metodo restituisce in output un elenco di tag seguiti dal numero di Package
corrispondenti.
30
Linee Guida per
l’integrazione
10 RIFERIMENTI
[BEARER]
[BSON]
[ECMA]
[ISO8601]
[MQTT]
[RTSP]
[HTTPA]
[OAUTH]
[JSON]
[TLS]
[UUID]
RFC 6750, OAuth 2.0 Bearer Token Usage, IETF, 2012
http://bsonspec.org/
ECMA 262, Linguaggio di Programmazione JavaScript Terza Edizione,
1999
ISO 8601:2004, Date and time format Terza Edizione, 2013
http://mqtt.org/
RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998
RFC 2617, HTTP Authentication: Basic and Digest Access31
Authentication, IETF, 1999
RFC 6749, The OAuth 2.0 Authorization Framework, IETF, 2012
ECMA 404, The JSON Data Interchange Format, Ecma International,
2013
RFC 5246, Transport Layer Security (TLS) Protocol Version 1.2, 2008
X.667, Information technology - Procedures for the operation of
object identifier registration authorities: Generation of universally
unique identifiers and their use in object identifiers, ITU, 2012