NDEF-Protokoll

  • Artikel

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

Nach dem Doppelpunkt sind einer von sechs Datensatztypen.

  • Leer
  • Extern
  • MIME
  • URI
  • Wkt
  • Unbekannt

Ein Anbieter unterstützt NDEF, indem er die grundlegenden Anforderungen des Anbieters 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 abonnierenden Client übermittelt. Gemäß der Konvention in [NDEF] ist der "Typ", der für eine NDEF-Nachricht abgeglichen werden soll, das TYPE-Feld, das im ersten NDEF-Datensatz einer NDEF-Nachricht angegeben wird. 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 erreicht, indem Sie "NDEF" abonnieren.

Allgemeine Anforderungen an den NDEF-Protokolltreiber

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

Erforderliche Aktionen

  • Der Treiber MUSS empfangene NDEF-Nachrichten basierend auf den Feldern TNF und TYPE des ersten NDEF-Datensatzes in der NDEF-Nachricht gemäß [NDEF] mit Abonnements abgleichen.
  • Wenn eine oder mehrere "*:WriteTag"-Veröffentlichungen aktiviert sind und der Treiber ein beschreibbares Tag mit genügend verfügbarem Speicherplatz erkennt, darf die vorhandene Nutzlast des Tags NICHT zum Abgleich mit anderen Abonnements gelesen werden. Dadurch kann eine App zum Schreiben von Tags andere Apps oder Dienste, die möglicherweise Nachrichten für Tags abonniert werden, vorentsetzt.
  • Bei NFC-fähigen NFP-Anbietern darf der Treiber keine "*:WriteTag"-Veröffentlichungen übertragen, wenn er mit einem NFC Forum-Gerät verbunden ist (im Gegensatz zu einem NFC Forum-Tag).
  • Wenn mindestens eine "*:WriteTag"-Veröffentlichung aktiviert ist, wenn der Treiber ein beschreibbares Tag mit genügend Speicherplatz für mindestens eine der Nutzlasten erkennt, MUSS der Treiber genau eine der Nutzlasten in das Tag schreiben. o Für den Fall, dass mehrere Publikationen aktiv und klein genug sind, um in ein Tag geschrieben zu werden, muss die zuletzt erstellte oder aktivierte "*:WriteTag"-Publikation die geschriebene sein.
  • Wenn eine "*:WriteTag"-Veröffentlichung erstellt oder aktiviert wird, während der Treiber derzeit mit einem beschreibbaren Tag in Kommunikation steht, der genügend Speicherplatz für die Nutzlast zur Verfügung hat, MUSS der Treiber die Nutzlast in das Tag schreiben, auch wenn der Treiber zuvor in das Tag geschrieben hat.
  • Der Treiber MUSS in Tags so schreiben, dass der vorherige Inhalt überschrieben wird.
  • Wenn eine "*:WriteTag"-Nutzlast erfolgreich in ein Tag geschrieben wurde, muss der Treiber die IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE Behandlung (wie oben angegeben) für diese Veröffentlichung auslösen.

Publikationen für "NDEF:WriteTag"

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

Erforderliche Aktionen

  • Es gelten die allgemeinen "*:WriteTag"-Anforderungen, die an anderer Stelle beschrieben werden.
  • Da ein NFC Forum-Tag mehrere NDEF-Nachrichten enthalten kann, MUSS der Treiber "NDEF:WriteTag"-Veröffentlichungen, die zufällig mehrere verkettete NDEF-Nachrichten als Nutzlast enthalten, ordnungsgemäß akzeptieren.

Publikationen für "SetTagReadOnly"

Diese Veröffentlichung ermöglicht es dem Client, ein Tag schreibgeschützt zu sperren. Der Anbieter muss ein bereits formatiertes NDEF-Lese-/Schreibtag in Schreibgeschützt konvertieren.

Erforderliche Aktionen

  • Der Treiber muss zuerst überprüfen, ob das verbundene Tag NDEF-konform ist.
  • Wenn einer oder mehrere "*:. WriteTag"-Veröffentlichungen sind aktiviert, und der Treiber erkennt ein beschreibbares Tag. Der Treiber MUSS zuerst in das Tag schreiben, wobei er die allgemeinen "*:WriteTag"-Anforderungen erfüllt, die an anderer Stelle beschrieben werden, und konvertiert dann das NDEF-Tag mit Lese-/Schreibzugriff in schreibgeschützt.

Leerer NDEF-Datensatz: "NDEF:Empty"

Diese Nachricht enthält keinen Typ, keine ID oder keine Nutzlast. Es scheint, dass Abonnements mit dem Typ "NDEF:Empty" aus Sicht eines Windows-Clients keinen Sinn ergeben.

Erforderliche Aktionen

Abonnements oder Veröffentlichungen 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. Wenn die Anwendung den Nachrichtentyp kennt, an dem sie interessiert ist, abonniert sie diesen Typ in der Regel speziell. Es ist jedoch manchmal nützlich, jede NDEF-Nachricht zu abonnieren. Dies kann beispielsweise für eine Anwendung nützlich sein, die ein dupliziertes NDEF-Tag kopieren und schreiben kann.

Erforderliche Aktionen

Der Treiber MUSS abonnements für "NDEF" mit jeder empfangenen NDEF-Nachricht abgleichen.

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 werden.

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

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

Erforderliche Aktionen

Der Treiber MUSS mit Abonnements für "NDEF:ext.<SomeExternalType>" NUR mit empfangenen NDEF-Nachrichten, die den TNF-Feldwert 0x04 und ein TYPE-Feld aufweisen, das "<SomeExternalType>" basierend auf den in [NFC RTD] angegebenen Äquivalenzregeln entspricht.

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 mit Abonnements für "NDEF:MIME.<SomeMimeType>" NUR mit empfangenen NDEF-Nachrichten, die den TNF-Feldwert 0x02 und ein TYPE-Feld aufweisen, das "<SomeMimeType>" basierend auf den in [NDEF] angegebenen Äquivalenzregeln entspricht.

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 mit Abonnements für "NDEF:wkt.<SomeWellKnownType>" NUR mit empfangenen NDEF-Nachrichten, die einen TNF-Feldwert von 0x01 und ein TYPE-Feld aufweisen, das "<SomeWellKnownType>" basierend auf den in [NDEF] angegebenen Äquivalenzregeln entspricht.
  • Der Treiber DARF KEINE bekannten Typen überprüfen, sodass zukünftige bekannte Typen vom NFC-Forum definiert werden können, ohne dass ein Treiberupdate erforderlich ist.

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

Dadurch kann ein Client eine nicht typisierte Nutzlast von Daten abonnieren.

Erforderliche Aktionen

Der Treiber MUSS Abonnements für "NDEF:Unknown" NUR mit NDEF-Nachrichten abgleichen, die den TNF-Feldwert 0x05 haben, wie in [NDEF] angegeben.

Near Field Communications (NFC)-API-Referenz