NDEF-protokoll

Protokollet "NDEF" är ett sätt att interagera direkt med NFC Forum-enheter så som den är mappad via NFP-leverantörens publicera/prenumerera-modell. Alla klienter som använder det här protokollet måste förstå hur man kodar och avkodar NDEF-paket. För publicering av meddelanden skulle en klient bara ange typen som "NDEF", eftersom resten av typinformationen är inbäddad i själva NDEF-meddelandet. Genom att publicera "NDEF"-typer kan en klient få nästan direkt tillgång att skicka NDEF-meddelanden via NFC. Om du vill prenumerera anger en klient "NDEF" följt av ett ":" (kolon).

Efter kolon kommer en av sex posttyper.

• Tomt
• Ext
• MIME
• URI (Uniform Resource Identifier)
• wkt
• Okänd

En provider stöder NDEF genom att följa de grundläggande providerkraven samt de NDEF-protokollspecifika krav som anges i det här avsnittet.

För att lyssna efter dessa NDEF-meddelanden prenumererar en klient på en av de typer som stöds, till exempel "NDEF:wkt.Sp". När providern identifierar ett NDEF-meddelande som matchar typen levereras hela NDEF-meddelandet (fortfarande kodat i NDEF) till den prenumererande klienten. Enligt konventionen i [NDEF] är den typ som ska matchas för ett NDEF-meddelande fältet TYPE som anges i den första NDEF-posten i ett NDEF-meddelande. För att överföra ett NDEF-meddelande publicerar en klient återigen ett fullständigt NDEF-meddelande som anger ett protokoll för "NDEF".

Det finns också en mekanism för att prenumerera på ALLA NDEF-meddelanden. detta uppnås genom att prenumerera på "NDEF".

Vanliga krav för NDEF-protokolldrivrutiner

Det finns flera vanliga krav för NDEF-stöd för drivrutiner för alla NFC-aktiverade NFP-leverantörer.

Nödvändiga åtgärder

• Drivrutinen måste matcha mottagna NDEF-meddelanden till prenumerationer baserat på fälten TNF och TYPE i den första NDEF-posten i NDEF-meddelandet enligt beskrivningen i [NDEF].
• Om en eller flera "*:WriteTag"-publikationer är aktiverade och drivrutinen identifierar en skrivbar tagg med tillräckligt med tillgängligt utrymme, får den befintliga nyttolasten för taggen INTE läsas i syfte att matcha andra prenumerationer. På så sätt kan en taggskrivningsapp förhindra andra appar eller tjänster som kan prenumerera på meddelanden på taggar.
• För NFC-aktiverade NFP-leverantörer får drivrutinen INTE överföra "*:WriteTag"-publikationer när den är ansluten till en NFC-forumenhet (i motsats till en NFC-forumtagg).
• Om en eller flera "*:WriteTag"-publikationer är aktiverade för tillfället identifierar drivrutinen en skrivbar tagg med tillräckligt med utrymme för minst en av nyttolasten, måste drivrutinen skriva exakt en av nyttolasten till taggen. o Om fler än en publikation är aktiv och tillräckligt liten för att skrivas till en tagg måste den senast skapade eller aktiverade publikationen "*:WriteTag" vara den som skrivits.
• Om en "*:WriteTag"-publikation skapas eller aktiveras medan drivrutinen för närvarande kommunicerar med en skrivbar tagg med tillräckligt med utrymme för nyttolasten måste drivrutinen skriva nyttolasten till taggen även om drivrutinen tidigare skrev till taggen.
• Drivrutinen MÅSTE skriva till taggar på ett sådant sätt att det tidigare innehållet skrivs över.
• Om nyttolasten "*:WriteTag" har skrivits till en tagg, måste drivrutinen utlösa hanteringen av IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE (enligt ovan) för denna publikation.

Publikationer för "NDEF:WriteTag"

Det här är en särskild typ av publikation som gör att ett eller flera NDEF-meddelanden kan skrivas till en NFC Forum-tagg.

Nödvändiga åtgärder

• De vanliga "*:WriteTag"-kraven som beskrivs någon annanstans gäller.
• Eftersom en NFC-forumtagg kan innehålla flera NDEF-meddelanden måste drivrutinen korrekt acceptera publikationerna "NDEF:WriteTag" som råkar ha flera sammanfogade NDEF-meddelanden som nyttolast.

Publikationer för "SetTagReadOnly"

Med den här publikationen kan klienten låsa en tagg till ett skrivskyddat läge. Leverantören måste konvertera en redan formaterad NDEF-läs-/skrivtagg till endast-läsbar.

Nödvändiga åtgärder

• Drivrutinen måste först kontrollera om den anslutna taggen är NDEF-kompatibel.
• Om ett eller flera "*:.WriteTag"-publikationer är aktiverade och drivrutinen identifierar en skrivbar tagg, måste drivrutinen skriva till taggen först, följa de vanliga "*:WriteTag"-kraven som beskrivs någon annanstans och sedan konvertera NDEF-läs-/skrivtaggen till endast läsbar.

Tom NDEF-post: "NDEF:Empty"

Det finns ingen typ, ID eller nyttolast i det här meddelandet. Det verkar som om prenumerationer med typen "NDEF:Empty" inte är meningsfulla för en Windows-klient.

Nödvändiga åtgärder

Prenumerationer eller publikationer av denna typ MÅSTE avvisas av drivrutinen för närhetsleverantören med STATUS_INVALID_PARAMETER.

Prenumerationer för alla NDEF-typer: "NDEF"

Klienter kan prenumerera på alla mottagna NDEF-meddelanden. Om programmet känner till vilken typ av meddelande det är intresserat av prenumererar det vanligtvis specifikt på den typen. Ibland kan det dock vara bra att prenumerera på varje NDEF-meddelande. Till exempel kan ett program som kan kopiera och skriva en duplicerad NDEF-tagg vara användbart.

Nödvändiga åtgärder

Drivrutinen MÅSTE matcha prenumerationer för "NDEF" med varje NDEF-meddelande som den tar emot.

Prenumerationer för externa NDEF RTD-typer: "NDEF:ext".

Leverantörer kan använda ett anpassat utökningsbart RTD-namnområde för att definiera innehållet i sina egna meddelanden. Detta gör att en klient kan prenumerera på externa RTD-typer som inte definierats av NFC-forumet, utan av appen eller en tredje part.

Generisk exempeltyp: "NDEF:ext.<SomeExternalType>"

Exempeltyp för betong: "NDEF:ext.contoso.com:mytype"

Nödvändiga åtgärder

Drivrutinen MÅSTE matcha prenumerationer för "NDEF:ext.<SomeExternalType>" ENDAST med mottagna NDEF-meddelanden som har ett TNF-fältvärde på 0x04 och där TYPE-fältet matchar "<SomeExternalType>" baserat på de likvärdighetsregler som anges i [NFC RTD].

Prenumerationer för "NDEF:MIME".

Meddelanden kan använda MIME-namnområdet för att definiera innehållet i meddelandet.

Allmän exempeltyp: "NDEF:MIME.<SomeMimeType>"

Konkret exempeltyp: "NDEF:MIME.image/jpeg"

Nödvändiga åtgärder

Drivrutinen MÅSTE matcha prenumerationer för "NDEF:MIME.<SomeMimeType>" ENDAST med mottagna NDEF-meddelanden som har ett TNF-fältvärde på 0x02 och som har ett TYPE-fält som matchar "<SomeMimeType>" baserat på de likvärdighetsregler som anges i [NDEF].

Prenumerationer för "NDEF:wkt".

Meddelanden kan använda NFC Forums namnområde för Well Known Type för att definiera innehållet i meddelandet.

Nödvändiga åtgärder

• Drivrutinen MÅSTE matcha prenumerationer för "NDEF:wkt.<SomeWellKnownType>" ENDAST med mottagna NDEF-meddelanden som har ett TNF-fältvärde på 0x01 och som har ett TYPE-fält som matchar "<SomeWellKnownType>" baserat på de likvärdighetsregler som anges i [NDEF].
• Drivrutinen FÅR INTE validera välkända typer, så att framtida välkända typer kan definieras av NFC Forum utan att en drivrutinsuppdatering krävs.

Prenumerationer för okänd NDEF-typ: "NDEF:Unknown"

På så sätt kan en klient prenumerera på en oskriven nyttolast med data.

Nödvändiga åtgärder

Drivrutinen MÅSTE matcha prenumerationer för "NDEF:Unknown" ENDAST med NDEF-meddelanden som har ett TNF-fältvärde på 0x05 enligt beskrivningen i [NDEF].

Relaterade ämnen

NFC API-referens för Near Field Communication