「NDEF」協議是一種直接與 NFC Forum 裝置互動的方法，對應為 NFP 提供者的發佈/訂閱模型。 任何使用此協定的用戶端都需要瞭解如何編碼和解碼 NDEF 封包。 針對發佈訊息，用戶端只會將類型指定為 “NDEF” ，因為其餘的類型資訊會內嵌在 NDEF 訊息本身內。 發佈「NDEF」類型可讓用戶端幾乎直接傳遞存取，以透過 NFC 傳送 NDEF 訊息。 若要訂閱，用戶端會指定 “NDEF” ，後面接著 '：' （冒號）。
冒號後面所列的是六種記錄類型之一。
- 空
- 內線
- MIME
- URI
- 週
- 未知
提供者會遵循基本提供者需求，以及本節中列出的 NDEF 通訊協定特定需求，以支援 NDEF。
若要接聽這些 NDEF 訊息，用戶端會訂閱其中一個支援的類型，例如 “NDEF：wkt.Sp“。 每當提供者偵測到符合類型的 NDEF 訊息時，整個 NDEF 訊息 （仍以 NDEF 編碼） 會傳遞至訂閱用戶端。 根據 [NDEF] 中的慣例，要與 NDEF 訊息相符的「類型」是 NDEF 訊息的第一個 NDEF 記錄中指定的 TYPE 欄位。 同樣地，若要傳輸 NDEF 訊息，用戶端會發佈完整的 NDEF 訊息，指定 「NDEF」 通訊協定。
還有一種機制用於訂閱所有 NDEF 消息;這是通過訂閱“NDEF”來實現的。
常見的 NDEF 通訊協定驅動程式需求
NDEF 支援的共通要求適用於所有支援 NFC 的 NFP 提供者的驅動程式。
必要動作
- 驅動程式必須根據 NDEF 訊息中第一個 NDEF 記錄的 TNF 和 TYPE 欄位，將收到的 NDEF 訊息與訂用帳戶比對，如 [NDEF] 中所指定。
- 如果已啟用一或多個 "*:WriteTag" 發行集，且驅動程式偵測到具有足夠可用空間的可寫入標籤，則不得讀取該標籤的現有承載，以便配對其他訂閱。 這可讓標籤寫入的應用程式優先於其他可能訂閱標籤訊息的應用程式或服務。
- 針對已啟用 NFC 的 NFP 提供者，當驅動程式連線到 NFC 論壇裝置時，不得傳輸 "＊：WriteTag" 訊號，這與 NFC 論壇標籤不同。
- 如果在驅動程式偵測到可寫入標籤時啟用了一个或多個「*:WriteTag」發佈，且至少有一个負載具備足夠的空間可用，則驅動程式必須將其中一個負載寫入標籤。 o 如果多個發佈處於作用中狀態，且小到足以寫入標籤，則最近建立或啟用的「*：WriteTag」發佈必須是寫入的發佈。
- 如果在驅動程式目前與具有足夠空間可用的可寫入標籤通訊時創建或啟用 *:WriteTag 發行時，驅動程式必須將載荷寫入標籤，即使驅動程式先前已將資料寫入標籤也是如此。
- 驅動程式必須以覆寫先前內容的方式寫入標籤。
- 如果 「*：WriteTag」 承載成功寫入標籤，驅動程式必須觸發該發行集的 IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE 處理 （如上述） 。
“NDEF：WriteTag”的出版物
這是一種特殊類型的出版品，可將一或多個 NDEF 訊息寫入 NFC Forum 標籤。
必要動作
- 其他地方所述的常見 「*：WriteTag」 需求適用。
- 因為 NFC 論壇標籤可以包含多個 NDEF 訊息，所以驅動程式必須正確接受 「NDEF：WriteTag」 發行集，這些發行集碰巧有多個串連的 NDEF 訊息作為承載。
「SetTagReadOnly」的出版物
此發佈可讓用戶端將標籤鎖定為唯讀。 提供者必須將已格式化的 NDEF 讀取/寫入標籤轉換成唯讀。
必要動作
- 驅動程式必須先檢查連線的標籤是否符合 NDEF 規範。
- 如果一或多個 “*：.WriteTag」 發行集已啟用，且驅動程式偵測到可寫入的標籤，驅動程式必須先寫入標籤，並遵守其他地方所述的常見 「*：WriteTag」 需求，然後將 NDEF 讀取/寫入標籤轉換成唯讀。
空 NDEF 記錄：「NDEF：空」
此訊息中沒有類型、ID 或承載。 從 Windows 用戶端的角度來看，具有「NDEF：Empty」類型的訂閱似乎沒有任何意義。
必要動作
具有此類型的訂閱或出版物必須被鄰近提供者驅動程式以STATUS_INVALID_PARAMETER拒絕。
所有 NDEF 類型的訂閱：「NDEF」
用戶端可以訂閱所有收到的 NDEF 訊息。 一般而言，如果應用程式知道它感興趣的訊息類型，它會特別訂閱該類型。 但是，訂閱每個NDEF消息有時很有用。 例如，可以複製和寫入重複 NDEF 標籤的應用程式可能會發現這很有用。
必要動作
驅動程式必須比對 “NDEF” 的訂用帳戶與它收到的每個 NDEF 訊息。
針對外部 NDEF RTD 類型的訂閱：「NDEF:ext」。
廠商可以使用自訂可延伸的 RTD 命名空間來定義其專屬訊息的內容。 這可讓用戶端訂閱 RTD 外部類型，而不是由 NFC 論壇定義，而是由應用程式或第三方定義。
泛型範例類型：「NDEF：ext.<SomeExternalType>」
具體範例類型：「NDEF:ext.contoso.com：mytype」
必要動作
驅動程式必須將 “NDEF：ext.<SomeExternalType>” 的訂閱匹配僅限於收到的 NDEF 訊息，這些訊息具有 TNF 欄位值為 0x04，且根據 [NFC RTD] 中指定的對等規則，其 TYPE 欄位必須匹配 "<SomeExternalType>"。
訂閱“NDEF：MIME”。
訊息可以使用 MIME 命名空間來定義訊息的內容。
泛型範例類型：「NDEF：MIME。<SomeMimeType>」
具體範例類型：「NDEF：MIME.image/jpeg」
必要動作
驅動程式必須僅將 "NDEF:MIME.<SomeMimeType>" 的訂閱匹配對象是 TNF 欄位值為 0x02 且 TYPE 欄位依據 [NDEF] 中指定的對等規則符合 "<SomeMimeType>" 的已接收 NDEF 訊息。
訂閱“NDEF：wkt”。
訊息可以使用 NFC 論壇已知類型命名空間來定義訊息的內容。
必要動作
- 驅動程式必須僅將“NDEF:wkt.<SomeWellKnownType>” 與符合下列條件的接收 NDEF 訊息匹配：其 TNF 欄位值為 0x01，且根據 [NDEF] 中指定的對等規則，其 TYPE 欄位必須匹配 “<SomeWellKnownType>”。
- 驅動程式不得驗證已知類型，讓 NFC 論壇可以定義未來的已知類型，而不需要更新驅動程式。
未知 NDEF 類型的訂閱：「NDEF：Unknown」
這允許客戶端訂閱無類型的資料載荷。
必要動作
驅動程式必須僅將「NDEF：未知」的訂閱與 [NDEF] 中 TNF 欄位值為 0x05 的 NDEF 訊息進行匹配。