NDEF-Protokoll

Das Protokoll "NDEF" ist ein Mittel zur direkten Interaktion mit NFC-Forum-Geräten, wie es durch das Pub/Sub-Modell des NFP-Anbieters zugeordnet wird. Jeder Client, der dieses Protokoll verwendet, muss verstehen, wie NDEF-Pakete codiert und decodiert werden. Bei der Veröffentlichung von Nachrichten würde ein Client lediglich den Typ als "NDEF" angeben, da der Rest der Typinformationen in die NDEF-Nachricht selbst eingebettet ist. Das Veröffentlichen von "NDEF"-Typen ermöglicht einem Client nahezu direkten Pass-Through-Zugriff, um NDEF-Nachrichten über NFC zu senden. Zum Abonnieren gibt ein Client "NDEF" gefolgt von einem ":" (Doppelpunkt) an.

Nach dem Doppelpunkt sind einer von sechs Datensatztypen angegeben.

• Leer
• Extern
• MIME
• URI (Uniform Resource Identifier)
• wkt
• Unbekannt

Ein Anbieter unterstützt NDEF, indem er die grundlegenden Anbieteranforderungen sowie die in diesem Abschnitt aufgeführten NDEF-protokollspezifischen Anforderungen erfüllt.

Um auf diese NDEF-Nachrichten zu lauschen, abonniert ein Client einen der unterstützten Typen, z. B. "NDEF:wkt". Sp". Wenn der Anbieter eine NDEF-Nachricht erkennt, die dem Typ entspricht, wird die gesamte NDEF-Nachricht (noch in NDEF codiert) an den abonnierten Client übermittelt. Gemäß der Konvention in [NDEF] ist der typ, der für eine NDEF-Nachricht abgeglichen werden soll, das TYP-Feld, das im ersten NDEF-Eintrag einer NDEF-Nachricht angegeben ist. Um eine NDEF-Nachricht zu übertragen, veröffentlicht ein Client eine vollständige NDEF-Nachricht, die ein Protokoll von "NDEF" angibt.

Es gibt auch einen Mechanismus zum Abonnieren aller NDEF-Nachrichten; Dies wird durch Abonnieren von "NDEF" erreicht.

Allgemeine Anforderungen des NDEF-Protokolltreibers

Es gibt mehrere Anforderungen, die für die NDEF-Unterstützung für die Treiber aller NFC-fähigen NFP-Anbieter gelten.

Erforderliche Aktionen

• Der Treiber muss NDEF-Nachrichten den Abonnements zuordnen, basierend auf den Feldern TNF und TYPE des ersten NDEF-Datensatzes in der NDEF-Nachricht, wie in [NDEF] festgelegt.
• Wenn mindestens eine "*:WriteTag"-Publikation aktiviert ist und der Treiber ein beschreibbares Tag mit genügend Speicherplatz erkennt, darf die vorhandene Nutzlast des Tags NICHT für die Zwecke des Abgleichs anderer Abonnements gelesen werden. Dies ermöglicht es einer Tag-Schreiben-App, anderen Apps oder Diensten, die Nachrichten auf Tags abonniert haben, zuvorzukommen.
• Für NFC-fähige NFP-Anbieter darf der Treiber keine "*:WriteTag"-Publikationen übertragen, wenn eine Verbindung mit einem NFC-Forumgerät (im Gegensatz zu einem NFC-Forumtag) hergestellt wird.
• Wenn eine oder mehrere "*:WriteTag"-Publikation aktiviert ist, und der Treiber ein beschreibbares Tag mit ausreichend Speicherplatz für mindestens eine der Nutzlasten erkennt, muss der Treiber genau eine der Nutzlasten auf das Tag schreiben. o Wenn mehrere Publikationen aktiv und klein genug sind, um in ein Tag geschrieben zu werden, muss die zuletzt erstellte oder aktivierte Publikation "*:WriteTag" die geschriebene sein.
• Wenn eine Publikation "*:WriteTag" erstellt oder aktiviert wird, während der Treiber zurzeit mit einem beschreibbaren Tag mit genügend Speicherplatz für die Nutzlast kommuniziert, muss der Treiber die Nutzlast in das Tag schreiben, auch wenn der Treiber zuvor an das Tag geschrieben hat.
• Der Treiber MUSS in einer Weise in die Tags schreiben, dass der vorherige Inhalt überschrieben wird.
• Wenn eine "*:WriteTag"-Nutzlast erfolgreich in ein Tag geschrieben wird, muss der Treiber die IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE Behandlung (wie oben angegeben) für diese Publikation auslösen.

Publikationen für "NDEF:WriteTag"

Dies ist eine spezielle Art von Publikation, mit der eine oder mehrere NDEF-Nachrichten in ein NFC-Forum-Tag geschrieben werden können.

Erforderliche Aktionen

• Die allgemeinen "*:WriteTag"-Anforderungen, die an anderer Stelle beschrieben werden, gelten.
• Da ein NFC-Forum-Tag mehrere NDEF-Nachrichten enthalten kann, muss der Treiber "NDEF:WriteTag"-Publikationen korrekt akzeptieren, die möglicherweise mehrere verkettete NDEF-Nachrichten als Nutzlast enthalten.

Publikationen für "SetTagReadOnly"

Diese Publikation ermöglicht es dem Client, ein Tag auf nur lesen zu setzen. Der Anbieter muss ein bereits formatiertes NDEF-Tag mit Lese-/Schreibzugriff in "Schreibgeschützt" konvertieren.

Erforderliche Aktionen

• Der Treiber muss zuerst überprüfen, ob das verbundene Tag NDEF-kompatibel ist.
• Wenn eine oder mehrere "*:.WriteTag"-Publikationen aktiviert sind und der Treiber ein beschreibbares Tag erkennt, muss der Treiber zuerst in das Tag schreiben, wobei die allgemeinen Anforderungen "*:WriteTag" eingehalten werden, die anderswo beschrieben sind, und dann das NDEF-Lese-/Schreib-Tag in schreibgeschützt umwandeln.

Leerer NDEF-Eintrag: "NDEF:Empty"

In dieser Nachricht gibt es keinen Typ, keine ID oder Nutzlast. Es scheint, dass Abonnements mit dem Typ "NDEF:Empty" aus Sicht eines Windows-Clients keinen Sinn machen.

Erforderliche Aktionen

Abonnements oder Publikationen mit diesem Typ MÜSSEN vom Näherungsanbietertreiber mit STATUS_INVALID_PARAMETER abgelehnt werden.

Abonnements für alle NDEF-Typen: "NDEF"

Clients können alle empfangenen NDEF-Nachrichten abonnieren. Typischerweise, wenn die Anwendung den Nachrichtentyp kennt, an dem sie interessiert ist, wird sie gezielt für diesen Typ abonniert. Es ist jedoch manchmal nützlich, jede NDEF-Nachricht zu abonnieren. Beispielsweise kann eine Anwendung, die ein dupliziertes NDEF-Tag kopieren und schreiben kann, dies hilfreich finden.

Erforderliche Aktionen

Der Treiber MUSS Abonnements für "NDEF" mit jeder empfangenen NDEF-Nachricht abstimmen.

Abonnements für externe NDEF-RTD-Typen: "NDEF:ext".

Anbieter können einen benutzerdefinierten erweiterbaren RTD-Namespace verwenden, um den Inhalt ihrer proprietären Nachrichten zu definieren. Dadurch kann ein Client externe RTD-Typen abonnieren, die nicht vom NFC-Forum, sondern von der App oder einem Drittanbieter definiert sind.

Generischer Beispieltyp: "NDEF:ext.<SomeExternalType>"

Konkreter Beispieltyp: "NDEF:ext.contoso.com:mytype"

Erforderliche Aktionen

Der Treiber MUSS Übereinstimmungen von Abonnements für "NDEF:ext.<SomeExternalType>" NUR mit erhaltenen NDEF-Nachrichten herstellen, die einen TNF-Feldwert von 0x04 haben und deren TYP-Feld "<SomeExternalType>" entspricht, basierend auf den Gleichwertigkeitsregeln, die in [NFC RTD] festgelegt sind.

Abonnements für "NDEF:MIME".

Nachrichten können den MIME-Namespace verwenden, um den Inhalt der Nachricht zu definieren.

Generischer Beispieltyp: "NDEF:MIME.<SomeMimeType>"

Konkreter Beispieltyp: "NDEF:MIME.image/jpeg"

Erforderliche Aktionen

Der Treiber MUSS Abonnements für "NDEF:MIME.<SomeMimeType>" NUR mit empfangenen NDEF-Nachrichten abgleichen, die einen TNF-Feldwert von 0x02 haben und ein TYPE-Feld, das "<SomeMimeType>" entspricht, basierend auf den in [NDEF] angegebenen Gleichwertigkeitsregeln.

Abonnements für "NDEF:wkt".

Nachrichten können den NFC Forum Well Known Type Namespace verwenden, um den Inhalt der Nachricht zu definieren.

Erforderliche Aktionen

• Der Treiber MUSS Abonnements für "NDEF:wkt.<SomeWellKnownType>" NUR mit empfangenen NDEF-Nachrichten abgleichen, die einen TNF-Feldwert von 0x01 haben und deren TYP-Feld "<SomeWellKnownType>" gemäß den Äquivalenzregeln in [NDEF] entspricht.
• Der Treiber MUSS keine bekannten Typen überprüfen, damit zukünftige bekannte Typen vom NFC-Forum definiert werden können, ohne dass ein Treiberupdate erforderlich ist.

Abonnements für unbekannten NDEF-Typ: "NDEF:Unknown"

Auf diese Weise kann ein Client eine nicht typierte Nutzlast von Daten abonnieren.

Erforderliche Aktionen

Der Treiber MUSS Abonnements für "NDEF:Unknown" nur mit NDEF-Nachrichten abgleichen, die einen TNF-Feldwert von 0x05 aufweisen, wie in [NDEF] angegeben.

Zugehörige Themen

Near Field Communications (NFC)-API-Referenz