1. Introduction (Introduzione)

L'uso dei 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 sui 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 quantità limitate di RAM e ROM) e alle reti (ad esempio, 6LoWPAN, [RFC4944]). Le reti vincolate come 6LoWPAN supportano la frammentazione dei pacchetti IPv6 in piccoli frame di livello collegamento; tuttavia, ciò causa una significativa riduzione della probabilità di consegna dei pacchetti. Uno degli obiettivi di progettazione di CoAP è stato mantenere basso il sovraccarico 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 è comprimere ciecamente HTTP [RFC2616], ma piuttosto realizzare un sottoinsieme di REST comune con HTTP ma ottimizzato per applicazioni M2M. Sebbene CoAP possa essere utilizzato per rimodellare semplici interfacce HTTP in un protocollo più compatto, cosa più importante, offre anche funzionalità per M2M come discovery integrata, supporto multicast e 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 supporto multicast, overhead molto basso e semplicità per ambienti vincolati e applicazioni M2M.

1.1. Features (Funzionalità)

CoAP ha le seguenti caratteristiche principali:

• Protocollo web che soddisfa i requisiti M2M in ambienti vincolati

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

• Scambi di messaggi asincroni.

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

• Supporto per URI e tipo di contenuto.

• Semplici capacità di proxy e caching.

• Un mapping HTTP stateless, che consente di costruire proxy che forniscono accesso alle risorse CoAP tramite HTTP in modo uniforme o di realizzare interfacce semplici HTTP alternativamente su CoAP.

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

1.2. Terminology (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 MAIUSCOLO. Queste parole possono anche apparire in questo documento in minuscolo, senza il loro significato normativo.

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

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

Sender (Mittente) : L'endpoint di origine di un messaggio. Quando l'aspetto dell'identificazione del mittente specifico è al centro, anche chiamato "source endpoint" (endpoint sorgente).

Recipient (Destinatario) : L'endpoint di destinazione di un messaggio. Quando l'aspetto dell'identificazione del destinatario specifico è al centro, anche chiamato "destination endpoint" (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 data 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 richieste e inoltrare risposte, possibilmente eseguendo caching, traduzione dello spazio dei nomi o traduzione del protocollo nel processo. A differenza degli intermediari in senso generale, i proxy generalmente non implementano semantica applicativa specifica. In base alla posizione nella struttura complessiva dell'inoltro delle richieste, ci sono 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 (Proxy diretto) : Un endpoint selezionato da un client, solitamente tramite regole di configurazione locali, per eseguire richieste per conto del client, eseguendo eventuali traduzioni necessarie. Alcune traduzioni sono minime, come per le richieste proxy per URI "coap", mentre altre richieste potrebbero richiedere traduzione da e verso protocolli di livello applicazione completamente diversi.

Reverse-Proxy (Proxy inverso) : Un endpoint che rappresenta uno o più altri server e soddisfa le richieste per loro conto, eseguendo eventuali traduzioni necessarie. A differenza di un forward-proxy, il client potrebbe non essere consapevole di comunicare con un reverse-proxy; un reverse-proxy riceve richieste come se fosse il server di origine per la risorsa di destinazione.

CoAP-to-CoAP Proxy (Proxy CoAP-CoAP) : 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 (Proxy cross-protocollo) : Un proxy cross-protocollo, o "cross-proxy" in breve, è un proxy che traduce tra protocolli diversi, come un proxy CoAP-HTTP o un proxy HTTP-CoAP. Mentre questa specifica fa richieste molto specifiche ai proxy CoAP-CoAP, c'è più variazione possibile nei cross-proxy.

Confirmable Message (Messaggio confermabile) : Alcuni messaggi richiedono un riconoscimento. Questi messaggi sono chiamati "Confirmable" (confermabili). Quando nessun pacchetto viene perso, ogni messaggio confermabile suscita esattamente un messaggio di ritorno di tipo Acknowledgement (riconoscimento) o di tipo Reset (ripristino).

Non-confirmable Message (Messaggio non confermabile) : Alcuni altri messaggi non richiedono un riconoscimento. Questo è particolarmente vero per i messaggi che vengono ripetuti regolarmente per requisiti applicativi, come letture ripetute da un sensore.

Acknowledgement Message (Messaggio di riconoscimento) : Un messaggio di riconoscimento conferma che un messaggio confermabile specifico è arrivato. Di per sé, un messaggio di riconoscimento non indica il successo o il fallimento di alcuna richiesta incapsulata nel messaggio confermabile, ma il messaggio di riconoscimento può anche trasportare una Piggybacked Response (risposta piggyback) (vedi sotto).

Reset Message (Messaggio di ripristino) : Un messaggio di ripristino indica che un messaggio specifico (confermabile o non confermabile) è stato ricevuto, ma manca un certo contesto per elaborarlo correttamente. Questa condizione è solitamente causata quando il nodo ricevente è stato riavviato e ha dimenticato uno stato che sarebbe richiesto per interpretare il messaggio. Provocare un messaggio di ripristino (ad esempio, inviando un messaggio confermabile vuoto) è anche utile come controllo poco costoso della vitalità di un endpoint ("CoAP ping").

Piggybacked Response (Risposta piggyback) : Una risposta piggyback è inclusa direttamente in un messaggio CoAP Acknowledgement (ACK) che viene inviato per confermare la ricezione della richiesta per questa risposta (Section 5.2.1).

Separate Response (Risposta separata) : Quando un messaggio confermabile 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 (Section 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 definitivamente il messaggio per elaborare correttamente il messaggio (Section 5.4.1). Si noti che l'implementazione delle opzioni critiche è, come implica il nome "Option" (opzione), generalmente opzionale: le opzioni critiche non supportate portano a una risposta di errore o al rifiuto sommario del messaggio.

Elective Option (Opzione elettiva) : Un'opzione che è destinata a essere ignorata da un endpoint che non la comprende. Elaborare il messaggio anche senza comprendere l'opzione è accettabile (Section 5.4.1).

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

Safe-to-Forward Option (Opzione sicura da inoltrare) : Un'opzione che è destinata a essere sicura per l'inoltro da parte di un proxy che non la comprende. Inoltrare il messaggio anche senza comprendere l'opzione è accettabile (Section 5.4.2).

Resource Discovery (Scoperta delle risorse) : Il processo mediante il quale un client CoAP interroga un server per il suo elenco di risorse ospitate (ovvero, collegamenti come definito nella Section 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 identità), identificata da un identificatore numerico definito dal registro "CoAP Content-Formats". Quando il focus è meno sull'identificatore numerico che sulla combinazione di queste caratteristiche di una rappresentazione di risorsa, questo è anche chiamato "representation format" (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 "octet" (ottetto).

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