Протокол Windows

Чтобы обеспечить взаимодействие поставщиков NFP с поддержкой NFC, в этом разделе определяется, как следует инкапсулировать сообщение Windows в сообщении NDEF. В этом разделе также сопоставляется модель NFP pub/sub с опубликованными протоколами ФОРУМА NFC для обмена сообщениями NDEF. Эти требования применяются только в том случае, если технология близкого взаимодействия объявляется как NFC.

Инкапсуляция

Для обеспечения правильной инкапсуляции сообщений Windows для взаимодействия NFC необходимо выполнить следующие требования.

Обязательные действия

• Если технология близкого взаимодействия рекламируется как NFC, драйвер ДОЛЖЕН упаковывать каждую "Windows<SomeSubType>" публикацию в сообщениях NDEF со значением поля TNF 0x03.

  • Поле типа NDEF должно содержать прямое сопоставление строки <SomeSubType>, где каждый широкий символ интерпретируется как один байт.
  • Полезные данные NDEF ДОЛЖНЫ содержать непосредственное двоичное содержимое пеймлоуда сообщения публикации.

• Если технология близкого взаимодействия объявлена как NFC, драйвер ДОЛЖЕН соответствовать подпискам на «Windows».<SomeSubType>" ТОЛЬКО с сообщениями NDEF, у которых значение поля TNF равно 0x03, и поле TYPE равно "<SomeSubType>", где каждый широкий символ интерпретируется как один байт.

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

"Windows:WriteTag". Публикации

Публикация типа Windows:WriteTag позволяет приложению просто записывать нагрузку, типизированную Windows, в тег.

Обязательные действия

• Распространенные требования "*:WriteTag", описанные в другом месте.
• Требования к публикации "Windows.<SomeSubType>" также применяются к публикациям "Windows:WriteTag.<SomeSubType>".

Публикации LaunchApp:WriteTag

Средство LaunchApp:WriteTag — это метод, позволяющий приложению легко записывать сообщение "Windows.windows.com/LaunchApp" в тег.

Клиент отправит список строк с табуляцией (или с нулевым разделителем) в качестве полезной нагрузки для этой публикации, закодированной в UTF-16LE. Первая строка — это список аргументов для приложения. После строки аргумента будут пары строк. Первая строка в каждой паре определяет квалификатор платформы для идентификатора приложения, следующая строка — фактический идентификатор приложения для запуска на этой платформе. Этот механизм поддерживает взаимодействие между платформами приложений за пределами Windows.

Обязательные действия

• Тип сообщения должен быть закодирован так, как если бы тип был "Windows.windows.com/LaunchApp".
• Если буфер содержит менее трех строк, драйвер обязан завершить IOCTL с STATUS_INVALID_PARAMETER.
• Если буфер длиннее 3000 символов, драйвер обязан завершить IOCTL с STATUS_INVALID_PARAMETER.
• Если буфер содержит одну или несколько строк нулевой длины (два последовательных символа табуляции), драйвер ОБЯЗАН завершить IOCTL с кодом STATUS_INVALID_PARAMETER.
• Если буфер содержит четное количество строк, драйвер ДОЛЖЕН завершить IOCTL с STATUS_INVALID_PARAMETER.
• Драйвер обязан разобрать буфер на строку аргументов и список кортежей платформы и идентификаторов приложений (AppID).
• Если любая платформа или строка AppID длиннее 255 символов, драйвер обязан завершить выполнение IOCTL со статусом STATUS_INVALID_PARAMETER.
• Первый USHORT полезных данных, записанных в тег, должен содержать количество кортежей платформы или AppID в кодировке big-endian.
• Все строки должны быть преобразованы из UTF-16LE в UTF-8.
• Длина строк, указанных в полезной нагрузке, должна быть в байтах.
• Для каждой пары платформа/AppID драйвер ДОЛЖЕН добавить в полезные данные байт с длиной (в байтах) строки платформы, затем саму строку платформы, затем байт с длиной (в байтах) строки AppID, затем саму строку AppID.
• Драйвер должен добавить USHORT, содержащий длину строки аргумента, за которой следует сама строка аргумента.