1. Introduzione

L'uso di servizi web (API web) su Internet è diventato onnipresente nella maggior parte delle applicazioni e dipende dall'architettura fondamentale Representational State Transfer [REST] del Web.

Il lavoro su Constrained RESTful Environments (CoRE) mira a realizzare l'architettura REST in una forma adatta ai nodi più vincolati (ad esempio, microcontrollori a 8 bit con RAM e ROM limitate) e alle reti (ad esempio, 6LoWPAN, [RFC4944]). Le reti vincolate come 6LoWPAN supportano la frammentazione dei pacchetti IPv6 in piccoli frame del livello di collegamento; tuttavia, ciò causa una significativa riduzione della probabilità di consegna dei pacchetti. Uno degli obiettivi di progettazione di CoAP è stato quello di mantenere ridotto l'overhead dei messaggi, limitando così la necessità di frammentazione.

Uno degli obiettivi principali di CoAP è progettare un protocollo web generico per i requisiti speciali di questo ambiente vincolato, considerando in particolare l'energia, l'automazione degli edifici e altre applicazioni machine-to-machine (M2M). L'obiettivo di CoAP non è quello di comprimere ciecamente HTTP [RFC2616], ma piuttosto di realizzare un sottoinsieme di REST comune con HTTP ma ottimizzato per le applicazioni M2M. Sebbene CoAP possa essere utilizzato per rimodellare semplici interfacce HTTP in un protocollo più compatto, cosa ancora più importante offre anche funzionalità per M2M come il discovery integrato, il supporto multicast e gli scambi di messaggi asincroni.

Questo documento specifica il Constrained Application Protocol (CoAP), che si traduce facilmente in HTTP per l'integrazione con il Web esistente soddisfacendo al contempo requisiti specializzati come il supporto multicast, un overhead molto basso e la semplicità per ambienti vincolati e applicazioni M2M.

1.1. Funzionalità

CoAP ha le seguenti caratteristiche principali:

o Protocollo Web che soddisfa i requisiti M2M in ambienti vincolati

o Binding UDP [RFC0768] con affidabilità opzionale che supporta richieste unicast e multicast.

o Scambi di messaggi asincroni.

o Basso overhead dell'intestazione e complessità di analisi.

o Supporto URI e Content-type.

o Semplici capacità di proxy e caching.

o Una mappatura HTTP senza stato, che consente di creare proxy che forniscono accesso alle risorse CoAP tramite HTTP in modo uniforme o di realizzare interfacce semplici HTTP alternativamente su CoAP.

o Binding di sicurezza a Datagram Transport Layer Security (DTLS) [RFC6347].

1.2. Terminologia

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119] quando appaiono in TUTTO MAIUSCOLO. Queste parole possono apparire anche in questo documento in minuscolo, assenti i loro significati normativi.

Questa specifica richiede ai lettori di avere familiarità con tutti i termini e i concetti discussi in [RFC2616], inclusi "risorsa", "rappresentazione", "cache" e "fresco". (Essendo stata completata prima che il set aggiornato di RFC HTTP, da RFC 7230 a RFC 7235, diventasse disponibile, questa specifica fa riferimento specificamente alla versione precedente -- RFC 2616.) Inoltre, questa specifica definisce la seguente terminologia:

Endpoint Un'entità che partecipa al protocollo CoAP. Colloquialmente, un endpoint vive su un "Nodo", sebbene "Host" sarebbe più coerente con l'uso degli standard Internet, ed è ulteriormente identificato dalle informazioni di multiplexing del livello di trasporto che possono includere un numero di porta UDP e un'associazione di sicurezza (Sezione 4.1).

Sender (Mittente) L'endpoint di origine di un messaggio. Quando l'aspetto dell'identificazione del mittente specifico è a fuoco, anche "endpoint sorgente".

Recipient (Destinatario) L'endpoint di destinazione di un messaggio. Quando l'aspetto dell'identificazione del destinatario specifico è a fuoco, anche "endpoint di destinazione".

Client L'endpoint di origine di una richiesta; l'endpoint di destinazione di una risposta.

Server L'endpoint di destinazione di una richiesta; l'endpoint di origine di una risposta.

Origin Server (Server di Origine) Il server su cui risiede o deve essere creata una determinata risorsa.

Intermediary (Intermediario) Un endpoint CoAP che agisce sia come server che come client verso un server di origine (possibilmente tramite ulteriori intermediari). Una forma comune di intermediario è un proxy; diverse classi di tali proxy sono discusse in questa specifica.

Proxy Un intermediario che si occupa principalmente di inoltrare le richieste e ritrasmettere le risposte, eseguendo eventualmente caching, traduzione dello spazio dei nomi o traduzione del protocollo nel processo. A differenza degli intermediari in senso generale, i proxy generalmente non implementano specifiche semantiche applicative. In base alla posizione nella struttura complessiva dell'inoltro della richiesta, esistono due forme comuni di proxy: forward-proxy e reverse-proxy. In alcuni casi, un singolo endpoint potrebbe agire come server di origine, forward-proxy o reverse-proxy, cambiando comportamento in base alla natura di ciascuna richiesta.

Forward-Proxy Un endpoint selezionato da un client, solitamente tramite regole di configurazione locali, per eseguire richieste per conto del client, effettuando tutte le traduzioni necessarie. Alcune traduzioni sono minime, come per le richieste proxy per URI "coap", mentre altre richieste potrebbero richiedere la traduzione da e verso protocolli di livello applicativo completamente diversi.

Reverse-Proxy Un endpoint che sostituisce uno o più altri server e soddisfa le richieste per conto di questi, effettuando tutte le traduzioni necessarie. A differenza di un forward-proxy, il client potrebbe non essere consapevole di comunicare con un reverse-proxy; un reverse-proxy riceve le richieste come se fosse il server di origine per la risorsa di destinazione.

CoAP-to-CoAP Proxy Un proxy che mappa da una richiesta CoAP a una richiesta CoAP, ovvero utilizza il protocollo CoAP sia sul lato server che sul lato client. In contrasto con cross-proxy.

Cross-Proxy Un proxy cross-protocol, o "cross-proxy" in breve, è un proxy che traduce tra protocolli diversi, come un proxy CoAP-to-HTTP o un proxy HTTP-to-CoAP. Sebbene questa specifica ponga richieste molto specifiche ai proxy CoAP-to-CoAP, c'è più variazione possibile nei cross-proxy.

Confirmable Message (Messaggio Confernabile) Alcuni messaggi richiedono una conferma. Questi messaggi sono chiamati "Confirmable". Quando non vengono persi pacchetti, ogni messaggio Confirmable suscita esattamente un messaggio di ritorno di tipo Acknowledgement (Conferma) o di tipo Reset.

Non-confirmable Message (Messaggio Non Confernabile) Alcuni altri messaggi non richiedono una conferma. Ciò è particolarmente vero per i messaggi che vengono ripetuti regolarmente per requisiti applicativi, come letture ripetute da un sensore.

Acknowledgement Message (Messaggio di Conferma) Un messaggio di Conferma riconosce che è arrivato uno specifico messaggio Confirmable. Di per sé, un messaggio di Conferma non indica il successo o il fallimento di alcuna richiesta incapsulata nel messaggio Confirmable, ma il messaggio di Conferma può anche trasportare una Piggybacked Response (vedi sotto).

Reset Message (Messaggio di Reset) Un messaggio di Reset indica che è stato ricevuto un messaggio specifico (Confirmable o Non-confirmable), ma manca un contesto per elaborarlo correttamente. Questa condizione è solitamente causata quando il nodo ricevente si è riavviato e ha dimenticato un certo stato che sarebbe richiesto per interpretare il messaggio. Provocare un messaggio di Reset (ad esempio, inviando un messaggio Confirmable vuoto) è anche utile come controllo economico della vivacità di un endpoint ("CoAP ping").

Piggybacked Response (Risposta Piggybacked) Una risposta piggybacked è inclusa direttamente in un messaggio di Conferma (ACK) CoAP che viene inviato per confermare la ricezione della Richiesta per questa Risposta (Sezione 5.2.1).

Separate Response (Risposta Separata) Quando un messaggio Confirmable che trasporta una richiesta viene confermato con un messaggio Vuoto (ad esempio, perché il server non ha la risposta immediatamente), una Risposta Separata viene inviata in uno scambio di messaggi separato (Sezione 5.2.2).

Empty Message (Messaggio Vuoto) Un messaggio con un Codice di 0.00; né una richiesta né una risposta. Un messaggio Vuoto contiene solo l'intestazione di 4 byte.

Critical Option (Opzione Critica) Un'opzione che dovrebbe essere compresa dall'endpoint che riceve infine il messaggio per elaborare correttamente il messaggio (Sezione 5.4.1). Notare che l'implementazione delle opzioni critiche è, come suggerisce il nome "Opzione", generalmente facoltativa: le opzioni critiche non supportate portano a una risposta di errore o al rifiuto sommario del messaggio.

Elective Option (Opzione Elettiva) Un'opzione che è intesa per essere ignorata da un endpoint che non la comprende. L'elaborazione del messaggio anche senza comprendere l'opzione è accettabile (Sezione 5.4.1).

Unsafe Option (Opzione Non Sicura) Un'opzione che dovrebbe essere compresa da un proxy che riceve il messaggio per inoltrare in modo sicuro il messaggio (Sezione 5.4.2). Non tutte le opzioni critiche sono opzioni non sicure.

Safe-to-Forward Option (Opzione Sicura da Inoltrare) Un'opzione che è intesa per essere sicura per l'inoltro da parte di un proxy che non la comprende. L'inoltro del messaggio anche senza comprendere l'opzione è accettabile (Sezione 5.4.2).

Resource Discovery (Discovery delle Risorse) Il processo in cui un client CoAP interroga un server per il suo elenco di risorse ospitate (ovvero, collegamenti come definiti nella Sezione 7).

Content-Format (Formato del Contenuto) La combinazione di un tipo di media Internet, potenzialmente con parametri specifici forniti, e una codifica del contenuto (che è spesso la codifica del contenuto dell'identità), identificata da un identificatore numerico definito dal registro "CoAP Content-Formats". Quando l'attenzione è meno sull'identificatore numerico che sulla combinazione di queste caratteristiche di una rappresentazione della risorsa, questo è anche chiamato "formato di rappresentazione".

Terminologia aggiuntiva per nodi vincolati e reti di nodi vincolati può essere trovata in [RFC7228].

In questa specifica, il termine "byte" è usato nel suo senso ormai consueto come sinonimo di "ottetto".

Tutti gli interi multi-byte in questo protocollo sono interpretati nell'ordine dei byte di rete.

Dove viene utilizzata l'aritmetica, questa specifica utilizza la notazione familiare dal linguaggio di programmazione C, tranne per il fatto che l'operatore "**" sta per l'esponenziazione.