Поделиться через

Протокол NDEF

  • Статья

Протокол "NDEF" — это средство взаимодействия с устройствами NFC Forum напрямую, сопоставленное с помощью модели публикации или подсети поставщика NFP. Любой клиент, использующий этот протокол, должен понимать, как кодировать и декодировать пакеты NDEF. Для публикации сообщений клиент просто указывает тип как "NDEF", так как остальная часть сведений о типе внедряется в само сообщение NDEF. Публикация типов "NDEF" позволяет клиенту почти прямой сквозной доступ для отправки сообщений NDEF через NFC. Чтобы подписаться, клиент указывает "NDEF", за которым следует ":" (двоеточие).

За двоеточием следует один из шести типов записей.

  • Empty
  • Ext
  • MIME
  • URI
  • Wkt
  • Неизвестно

Поставщик поддерживает NDEF, следуя основным требованиям поставщика, а также требованиям к протоколу NDEF, перечисленным в этом разделе.

Чтобы прослушивать эти сообщения NDEF, клиент подписывается на один из поддерживаемых типов, например "NDEF:wkt. Sp". Всякий раз, когда поставщик обнаруживает сообщение NDEF, соответствующее типу, все сообщение NDEF (по-прежнему закодированное в NDEF) доставляется клиенту подписки. Согласно соглашению в [NDEF], "тип" для сообщения NDEF является полем TYPE, указанным в первой записи NDEF сообщения NDEF. Опять же, чтобы передать сообщение NDEF, клиент публикует полное сообщение NDEF, указывающее протокол "NDEF".

Существует также механизм подписки на все сообщения NDEF; это достигается путем подписки на "NDEF".

Общие требования к драйверу протокола NDEF

Существует несколько общих требований к поддержке NDEF для драйверов всех поставщиков NFP с поддержкой NFC.

Необходимые действия

  • Драйвер ДОЛЖЕН сопоставлять полученные сообщения NDEF с подписками на основе полей TNF и TYPE первой записи NDEF в сообщении NDEF, как указано в [NDEF].
  • Если включена одна или несколько публикаций "*:WriteTag" и драйвер обнаруживает доступный для записи тег с достаточным объемом свободного места, существующие полезные данные тега не должны читаться для сопоставления с другими подписками. Это позволяет приложению для записи тегов упрещать другие приложения или службы, которые могут быть подписаны на сообщения в тегах.
  • Для поставщиков NFP с поддержкой NFC драйвер НЕ ДОЛЖЕН передавать публикации "*:WriteTag" при подключении к устройству ФОРУМА NFC (в отличие от тега форума NFC).
  • Если одна или несколько публикаций "*:WriteTag" включены в тот момент, когда драйвер обнаруживает записываемый тег с достаточным объемом свободного места по крайней мере для одной из полезных данных, драйвер должен записать в тег ровно одну из полезных данных. o В случае, если несколько публикаций активны и достаточно малы для записи в тег, то последняя созданная или включенная публикация "*:WriteTag" должна быть написана.
  • Если публикация "*:WriteTag" создается или включена, когда драйвер в настоящее время обменивается данными с тегом, доступным для записи, с достаточным пространством для полезных данных, драйвер должен записать полезные данные в тег, даже если драйвер ранее писал в тег.
  • Драйвер должен выполнять запись в теги таким образом, чтобы предыдущее содержимое перезаписывалось.
  • Если полезные данные "*:WriteTag" успешно записаны в тег, драйвер должен активировать обработку IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE (как указано выше) для этой публикации.

Публикации для "NDEF:WriteTag"

Это особый тип публикации, который позволяет записывать одно или несколько сообщений NDEF в тег форума NFC.

Необходимые действия

  • Применяются общие требования "*:WriteTag", описанные в других местах.
  • Так как тег форума NFC может содержать несколько сообщений NDEF, драйвер должен правильно принимать публикации "NDEF:WriteTag", которые содержат несколько объединенных сообщений NDEF в качестве полезных данных.

Публикации для SetTagReadOnly

Эта публикация позволяет клиенту заблокировать тег только для чтения. Поставщик должен преобразовать уже отформатированный тег NDEF для чтения и записи в только для чтения.

Необходимые действия

  • Драйвер должен сначала проверка, соответствует ли подключенный тег NDEF.
  • Если один или несколько "*:. Публикация WriteTag включена, и драйвер обнаруживает тег, доступный для записи. Драйвер должен сначала записать в тег, придерживаясь общих требований "*:WriteTag", описанных в других местах, а затем преобразовать тег NDEF для чтения и записи в только для чтения.

Пустая запись NDEF: "NDEF:Empty"

В этом сообщении нет ни типа, ни идентификатора, ни полезных данных. Кажется, что подписки с типом "NDEF:Empty" не имеет смысла с точки зрения клиента Windows.

Необходимые действия

Подписки или публикации с этим типом должны быть отклонены драйвером поставщика близкого взаимодействия с STATUS_INVALID_PARAMETER.

Подписки для всех типов NDEF: "NDEF"

Клиенты могут подписаться на все полученные сообщения NDEF. Как правило, если приложению известен тип интересующего его сообщения, оно будет подписываться на этот тип. Однако иногда полезно подписаться на каждое сообщение NDEF. Например, приложение, которое может копировать и записывать повторяющийся тег NDEF, может оказаться полезным.

Необходимые действия

Драйвер должен сопоставлять подписки для "NDEF" с каждым получаемым сообщением NDEF.

Подписки для внешних типов RTD NDEF: "NDEF:ext".

Поставщики могут использовать пользовательское расширяемое пространство имен RTD для определения содержимого своих собственных сообщений. Это позволяет клиенту подписываться на внешние типы RTD, определенные не на форуме NFC, а в приложении или стороннем.

Универсальный тип примера: "NDEF:ext.<SomeExternalType>"

Тип конкретного примера: "NDEF:ext.contoso.com:mytype"

Необходимые действия

Драйвер ДОЛЖЕН соответствовать подпискам для "NDEF:ext.<SomeExternalType>" ТОЛЬКО с полученными сообщениями NDEF, имеющими значение поля TNF 0x04 и поле TYPE, соответствующее "<SomeExternalType>" на основе правил эквивалентности, указанных в [NFC RTD].

Подписки для "NDEF:MIME".

Сообщения могут использовать пространство имен MIME для определения содержимого сообщения.

Универсальный тип примера: "NDEF:MIME.<SomeMimeType>"

Конкретный тип примера: "NDEF:MIME.image/jpeg"

Необходимые действия

Драйвер ДОЛЖЕН соответствовать подпискам для "NDEF:MIME.<SomeMimeType>" только с полученными сообщениями NDEF, которые имеют значение поля TNF 0x02 и имеют поле TYPE, соответствующее "<SomeMimeType>" на основе правил эквивалентности, указанных в [NDEF].

Подписки на "NDEF:wkt".

Сообщения могут использовать пространство имен хорошо известных типов NFC для определения содержимого сообщения.

Необходимые действия

  • Драйвер ДОЛЖЕН соответствовать подпискам для "NDEF:wkt.<SomeWellKnownType>" только с полученными сообщениями NDEF, которые имеют значение поля TNF 0x01 и имеют поле TYPE, соответствующее "<SomeWellKnownType>" на основе правил эквивалентности, указанных в [NDEF].
  • Драйвер НЕ ДОЛЖЕН проверять хорошо известные типы, чтобы будущие хорошо известные типы можно было определить на форуме NFC без необходимости обновления драйвера.

Подписки для неизвестного типа NDEF: "NDEF:Unknown"

Это позволяет клиенту подписаться на нетипизированные полезные данные.

Необходимые действия

Драйвер должен соответствовать подпискам для "NDEF:Unknown" только с сообщениями NDEF, которые имеют значение поля TNF 0x05, как указано в [NDEF].

Справочник по API nfc