NDEF 通訊協定
“NDEF” 通訊協定是直接與 NFC 論壇裝置互動的方式，就像透過 NFP 提供者 pub/sub 模型對應一樣。 任何使用此通訊協定的用戶端都必須瞭解如何編碼和譯碼 NDEF 封包。 針對發佈訊息，用戶端只會將類型指定為 「NDEF」，因為類型資訊的其餘部分會內嵌在 NDEF 訊息本身內。 發佈 「NDEF」 類型可讓客戶端幾乎直接透過 NFC 傳送 NDEF 訊息。 若要訂閱，用戶端會指定 「NDEF」，後面接著 『：』 (冒號) 。
在冒號後面是六個記錄類型的其中一個。
- Empty
- 內線
- MIME
- URI
- wkt
- Unknown
提供者遵循基本提供者需求，以及本節所列的 NDEF 通訊協定特定需求，以支援 NDEF。
若要接聽這些 NDEF 訊息，用戶端會訂閱其中一種支援的類型，例如 “NDEF：wkt。Sp”。 每當提供者偵測到符合類型的 NDEF 訊息時，整個 NDEF 訊息 (仍以 NDEF 編碼) 傳遞至訂閱用戶端。 根據 [NDEF] 中的慣例，要針對 NDEF 訊息比對的 'type' 是 NDEF 訊息的第一筆 NDEF 記錄中指定的 TYPE 字段。 同樣地，若要傳輸 NDEF 訊息，用戶端會發佈完整的 NDEF 訊息，並指定 「NDEF」 的通訊協定。
另外還有一種機制可訂閱 ALL NDEF 訊息;這可藉由訂閱 「NDEF」 來完成。
常見的 NDEF 通訊協定驅動程式需求
所有已啟用 NFC 的 NFP 提供者驅動程式上，NDEF 支援都有數個常見需求。
必要動作
- 驅動程式必須根據 [NDEF] 訊息中 NDEF 訊息中第一筆 NDEF 記錄的 TNF 和 TYPE 字段，比對收到的 NDEF 訊息。
- 如果啟用一或多個 「*：WriteTag」 發行集，且驅動程式偵測到具有足夠可用空間的可寫入標籤，則無法讀取標記的現有承載，以便比對其他訂用帳戶。 這可讓標記寫入應用程式先佔可能訂閱標記上訊息的其他應用程式或服務。
- 針對已啟用 NFC 的 NFP 提供者，驅動程式在連線到 NFC 論壇裝置時，不得傳輸 「*：WriteTag」 發行集 (，而不是 NFC 論壇標籤) 。
- 如果在驅動程式偵測到至少有一個承載可用空間的可寫入卷標時啟用一或多個 「*：WriteTag」 發行集，則驅動程式必須將其中一個承載完全寫入捲標。 o 如果有多個發行集作用中，且足以寫入標記，則最近建立或啟用的 “*：WriteTag” 發行集必須是寫入的發行集。
- 如果建立或啟用 「*：WriteTag」 發行集，而驅動程式目前與具有足夠可用空間的可寫入標籤時，即使驅動程式先前寫入卷標，驅動程式也必須將承載寫入標記。
- 驅動程式必須以覆寫先前內容的方式寫入標記。
- 如果已成功將 「*：WriteTag」 承載寫入標記，驅動程式必須觸發 IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE處理 ( ，如該發行集的上述) 所指定。
“NDEF：WriteTag” 的發行集
這是特殊的發行集類型，可讓一或多個 NDEF 訊息寫入 NFC 論壇標籤。
必要動作
- 其他位置所述的常見 「*：WriteTag」 需求適用。
- 由於 NFC 論壇標籤可以包含多個 NDEF 訊息，因此驅動程式必須正確接受發生多個串連 NDEF 訊息作為承載的 「NDEF：WriteTag」 發行集。
“SetTagReadOnly” 的發行集
此發行集可讓客戶端鎖定標記為唯讀。 提供者必須將已格式化的 NDEF 讀取/寫入標記轉換成唯讀。
必要動作
- 驅動程式必須先檢查連接的標籤是否符合 NDEF 規範。
- 如果一或多個 “*：”。WriteTag“發行集已啟用，而驅動程式會偵測可寫入的標籤，驅動程式必須先寫入標籤，並遵循其他地方所述的常見 ”*：WriteTag“ 需求，然後將 NDEF 讀取/寫入捲標轉換為只讀。
空的 NDEF 記錄：“NDEF：Empty”
此訊息中沒有類型、標識碼或承載。 從 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“ 僅包含具有 TNF 域值的 NDEF 訊息 0x04，且具有符合 ”<SomeExternalType>>“ 的 TYPE 字段，以 [NFC RTD] 中指定的等價規則為基礎。
“NDEF：MIME” 的訂用帳戶。
訊息可以使用MIME命名空間來定義訊息的內容。
泛型範例類型：「NDEF：MIME。<SomeMimeType>”
具體範例類型：“NDEF：MIME.image/jpeg”
必要動作
驅動程式必須符合 「NDEF：MIME」 的訂用帳戶。<SomeMimeType“ 僅包含已接收的 NDEF 訊息，其 TNF 域值為 0x02，且具有符合 ”<SomeMimeType>>“ 的 TYPE 字段，以 [NDEF] 中指定的等價規則為基礎。
“NDEF：wkt” 的訂用帳戶。
訊息可以使用 NFC 論壇已知類型命名空間來定義訊息的內容。
必要動作
- 驅動程式必須符合 「NDEF：wkt」 的訂用帳戶。<SomeWellKnownType>“ 僅限接收的 NDEF 訊息，這些訊息具有 TNF 域值0x01，且具有符合 ”<SomeWellKnownType>“ 的 TYPE 字段，以 [NDEF] 中指定的等價規則為基礎。
- 驅動程式不得驗證已知的類型，以便 NFC 論壇可以定義未來的已知類型，而不需要驅動程式更新。
未知 NDEF 類型的訂用帳戶：“NDEF：Unknown”
這可讓客戶端訂閱未具類型的數據承載。
必要動作
驅動程式必須比對 「NDEF：Unknown」 的訂用帳戶，且 NDEF 訊息具有 TNF 域值0x05，如 [NDEF] 中所指定。