Protocollo NDEF

Il protocollo "NDEF" è un mezzo per interagire direttamente con i dispositivi del NFC Forum come mappato tramite il modello "pub/sub" del provider NFP. Tutti i client che usano questo protocollo dovranno comprendere come codificare e decodificare i pacchetti NDEF. Per la pubblicazione di messaggi, un client specifica semplicemente il tipo come "NDEF", perché il resto delle informazioni sul tipo è incorporato all'interno del messaggio NDEF stesso. La pubblicazione di tipi "NDEF" consente a un client di ottenere un accesso quasi diretto per inviare messaggi NDEF tramite NFC. Per sottoscrivere, un client specifica "NDEF" seguito da un ':' (due punti).

Dopo i due punti, c'è uno dei sei tipi di record.

• Vuoto
• Ext
• MIME
• URI (Identificatore Uniforme delle Risorse)
• wkt
• Sconosciuto

Un provider supporta NDEF seguendo i requisiti di base del provider e i requisiti specifici del protocollo NDEF elencati in questa sezione.

Per ascoltare questi messaggi NDEF, un client sottoscrive uno dei tipi supportati, ad esempio "NDEF:wkt. Sp". Ogni volta che il provider rileva un messaggio NDEF che corrisponde al tipo, l'intero messaggio NDEF (ancora codificato in NDEF) viene recapitato al client di sottoscrizione. Come per convenzione in [NDEF], il "tipo" da trovare per un messaggio NDEF è il campo TYPE specificato nel primo record NDEF di un messaggio NDEF. Anche in questo caso, per trasmettere un messaggio NDEF, un client pubblica un messaggio NDEF completo che specifica un protocollo "NDEF".

Esiste anche un meccanismo per la sottoscrizione a TUTTI i messaggi NDEF; questa operazione viene eseguita sottoscrivendo "NDEF".

Requisiti comuni del driver del protocollo NDEF

Esistono diversi requisiti comuni per il supporto NDEF sui driver di tutti i provider NFP abilitati per NFC.

Azioni necessarie

• Il driver DEVE associare i messaggi NDEF ricevuti alle sottoscrizioni in base ai campi TNF e TYPE del primo record NDEF nel messaggio NDEF, come specificato in [NDEF].
• Se una o più pubblicazioni "*:WriteTag" sono abilitate e il driver rileva un tag scrivibile con spazio sufficiente, il payload esistente del tag NON DEVE essere letto per il confronto con altre sottoscrizioni. Ciò consente a un'app di scrittura di tag di anteporre altre app o servizi che potrebbero essere sottoscritti ai messaggi sui tag.
• Per i provider NFP abilitati per NFC, il driver NON DEVE trasmettere le pubblicazioni "*:WriteTag" quando si è connessi a un dispositivo del forum NFC (anziché a un tag del forum NFC).
• Se una o più pubblicazioni "*:WriteTag" sono abilitate nel momento in cui il driver rileva un tag scrivibile con spazio sufficiente disponibile per almeno uno dei payload, il driver DEVE scrivere esattamente uno dei payload nel tag. o Nel caso in cui più pubblicazioni siano attive e sufficientemente piccole da scrivere in un tag, la pubblicazione "*:WriteTag" creata o abilitata più di recente deve essere quella scritta.
• Se una pubblicazione "*:WriteTag" viene creata o abilitata mentre il driver è attualmente in comunicazione con un tag scrivibile con spazio sufficiente disponibile per il payload, il driver DEVE scrivere il payload nel tag anche se il driver ha scritto in precedenza nel tag.
• Il driver DEVE scrivere nei tag in modo che il contenuto precedente venga sovrascritto.
• Se un payload "*:WriteTag" viene scritto correttamente in un tag, il driver DEVE attivare la gestione IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE (come specificato in precedenza) per tale pubblicazione.

Pubblicazioni per "NDEF:WriteTag"

Si tratta di un tipo speciale di pubblicazione che consente di scrivere uno o più messaggi NDEF in un tag forum NFC.

Azioni necessarie

• Si applicano i requisiti comuni "*:WriteTag" descritti altrove.
• Poiché un tag forum NFC può contenere più messaggi NDEF, il driver DEVE accettare correttamente le pubblicazioni "NDEF:WriteTag" che hanno più messaggi NDEF concatenati come payload.

Pubblicazioni per "SetTagReadOnly"

Questa pubblicazione consente al client di bloccare un tag in modalità di sola lettura. Il provider deve convertire un tag di lettura/scrittura NDEF già formattato in Sola lettura.

Azioni necessarie

• Il driver deve prima verificare se il tag connesso è conforme a NDEF.
• Se una o più pubblicazioni "*:.WriteTag" sono abilitate e il driver rileva un tag scrivibile, il driver DEVE prima scrivere nel tag, rispettando i requisiti comuni "*:WriteTag" descritti altrove, e quindi convertire il tag NDEF di lettura/scrittura in sola lettura.

Record NDEF Vuoto: "NDEF:Empty"

Nessun tipo, ID o payload in questo messaggio. Sembra che le sottoscrizioni con il tipo "NDEF:Empty" non abbiano alcun senso dal punto di vista di un client Windows.

Azioni necessarie

Le sottoscrizioni o le pubblicazioni di questo tipo DEVONO essere rifiutate dal driver del fornitore di prossimità con STATUS_INVALID_PARAMETER.

Sottoscrizioni per tutti i tipi NDEF: "NDEF"

I client possono sottoscrivere tutti i messaggi NDEF ricevuti. In genere, se l'applicazione conosce il tipo di messaggio a cui è interessato, sottoscriverà specificamente tale tipo. Tuttavia, a volte è utile sottoscrivere ogni messaggio NDEF. Ad esempio, un'applicazione in grado di copiare e scrivere un tag NDEF duplicato potrebbe risultare utile.

Azioni necessarie

Il driver deve abbinare le sottoscrizioni per "NDEF" ad ogni messaggio NDEF ricevuto.

Sottoscrizioni per tipi RTD NDEF esterni: "NDEF:ext".

I fornitori possono usare uno spazio dei nomi RTD estendibile personalizzato per definire il contenuto dei messaggi proprietari. In questo modo un client può sottoscrivere tipi esterni RTD definiti non dal forum NFC, ma dall'app o da terze parti.

Tipo di esempio generico: "NDEF:ext.<SomeExternalType>"

Tipo di esempio concreto: "NDEF:ext.contoso.com:mytype"

Azioni necessarie

Il driver DEVE corrispondere alle sottoscrizioni per "NDEF:ext.<SomeExternalType>" SOLO con messaggi NDEF ricevuti con valore di campo TNF pari a 0x04 e che hanno un campo TYPE che corrisponde a "<SomeExternalType>" in base alle regole di equivalenza specificate in [NFC RTD].

Sottoscrizioni per "NDEF:MIME".

I messaggi possono usare lo spazio dei nomi MIME per definire il contenuto del messaggio.

Tipo di esempio generico: "NDEF:MIME.<SomeMimeType>"

Tipo di esempio concreto: "NDEF:MIME.image/jpeg"

Azioni necessarie

Il driver DEVE corrispondere alle sottoscrizioni per "NDEF:MIME.<SomeMimeType>" SOLO con messaggi NDEF ricevuti con valore di campo TNF pari a 0x02 e con un campo TYPE che corrisponde a "<SomeMimeType>" in base alle regole di equivalenza specificate in [NDEF].

Sottoscrizioni per "NDEF:wkt".

I messaggi possono usare lo spazio dei nomi NFC Forum Well Known Type per definire il contenuto del messaggio.

Azioni necessarie

• Il driver deve corrispondere alle sottoscrizioni per "NDEF:wkt.<SomeWellKnownType>" SOLO con i messaggi NDEF ricevuti che hanno un valore di campo TNF pari a 0x01 e che hanno un campo TYPE che corrisponde a "<SomeWellKnownType>" in base alle regole di equivalenza specificate in [NDEF].
• Il driver NON DEVE convalidare i tipi noti, in modo che i futuri tipi noti possano essere definiti dal forum NFC senza richiedere un aggiornamento del driver.

Sottoscrizioni per tipo NDEF sconosciuto: "NDEF:Unknown"

In questo modo un client può sottoscrivere un payload non tipizzato di dati.

Azioni necessarie

Il driver DEVE corrispondere alle sottoscrizioni per "NDEF:Unknown" SOLO con messaggi NDEF con un valore di campo TNF pari a 0x05 come specificato in [NDEF].

Argomenti correlati

Riferimento API per le comunicazioni a corto raggio (NFC)