Protocolo NDEF

El protocolo "NDEF" es un medio para interactuar con dispositivos del NFC Forum directamente según lo asignado a través del modelo de publicación/suscripción del proveedor NFP. Cualquier cliente que utilice este protocolo deberá comprender cómo codificar y decodificar paquetes NDEF. En el caso de los mensajes de publicación, un cliente simplemente especificaría el tipo como "NDEF", porque el resto de la información de tipo se inserta dentro del propio mensaje NDEF. La publicación de tipos "NDEF" permite que un cliente tenga acceso casi directo para enviar mensajes NDEF a través de NFC. Para suscribirse, un cliente especificaría "NDEF" seguido de ":" (dos puntos).

Después de los dos puntos hay uno de los seis tipos de registros.

  • Empty
  • Ext
  • MIMO
  • URI
  • wkt
  • Desconocido

Un proveedor admite NDEF siguiendo los requisitos básicos del proveedor, así como los requisitos específicos del protocolo NDEF enumerados en esta sección.

Para escuchar estos mensajes NDEF, un cliente se suscribe a uno de los tipos admitidos, como "NDEF:wkt. Sp". Cada vez que el proveedor detecta un mensaje NDEF que coincide con el tipo, todo el mensaje NDEF (todavía codificado en NDEF) se entrega al cliente de suscripción. Según la convención de [NDEF], el "tipo" que se va a buscar para un mensaje NDEF es el campo TYPE especificado en el primer registro NDEF de un mensaje NDEF. De nuevo, para transmitir un mensaje NDEF, un cliente publica un mensaje NDEF completo que especifica un protocolo de "NDEF".

También hay un mecanismo para suscribirse a todos los mensajes NDEF; Esto se logra mediante la suscripción a "NDEF".

Requisitos comunes del controlador del protocolo NDEF

Hay varios requisitos comunes para la compatibilidad con NDEF en los controladores de todos los proveedores NFP habilitados para NFC.

Acciones necesarias

  • El controlador DEBE hacer coincidir los mensajes NDEF recibidos con las suscripciones basándose en los campos TNF y TYPE del primer registro NDEF en el mensaje NDEF, tal como se especifica en [NDEF].
  • Si se habilitan una o varias publicaciones "*:WriteTag" y el controlador detecta una etiqueta grabable con suficiente espacio disponible, la carga existente de la etiqueta NO DEBE leerse para buscar coincidencias con otras suscripciones. Esto permite que una aplicación de escritura de etiquetas tenga prioridad sobre otras aplicaciones o servicios que puedan estar suscritos a mensajes sobre etiquetas.
  • En el caso de los proveedores NFP habilitados para NFC, el controlador NO DEBE transmitir publicaciones "*:WriteTag" cuando se conectan a un dispositivo de foro NFC (en lugar de una etiqueta de foro NFC).
  • Si una o varias publicaciones "*:WriteTag" están habilitadas en el momento en que el controlador detecta una etiqueta grabable con espacio suficiente disponible para al menos una de las cargas, el controlador DEBE escribir exactamente una de las cargas en la etiqueta. o En caso de que más de una publicación esté activa y sea lo suficientemente pequeña como para escribirse en una etiqueta, la publicación "*:WriteTag" creada o habilitada más recientemente debe ser la escrita.
  • Si se crea o habilita una publicación "*:WriteTag" mientras el controlador está actualmente en comunicación con una etiqueta grabable con suficiente espacio disponible para la carga, el controlador DEBE escribir la carga en la etiqueta aunque el controlador haya escrito previamente en la etiqueta.
  • El controlador DEBE escribir en etiquetas de tal forma que se sobrescriba el contenido anterior.
  • Si una carga "*:WriteTag" se escribe correctamente en una etiqueta, el controlador DEBE desencadenar el control de IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE (como se especificó anteriormente) para esa publicación.

Publicaciones para "NDEF:WriteTag"

Se trata de un tipo especial de publicación que permite escribir uno o varios mensajes NDEF en una etiqueta de foro NFC.

Acciones necesarias

  • Se aplican los requisitos comunes "*:WriteTag" descritos en otra parte.
  • Dado que una etiqueta de foro NFC puede contener varios mensajes NDEF, el controlador DEBE aceptar correctamente las publicaciones "NDEF:WriteTag" que tienen varios mensajes NDEF concatenados como carga.

Publicaciones para "SetTagReadOnly"

Esta publicación permite que el cliente bloquee una etiqueta de solo lectura. El proveedor debe convertir una etiqueta de lectura y escritura de NDEF ya formateada en solo lectura.

Acciones necesarias

  • El controlador debe comprobar primero si la etiqueta conectada es compatible con NDEF.
  • Si una o más publicaciones "*:.WriteTag" están habilitadas y el controlador detecta una etiqueta grabable, el controlador debe escribir primero en la etiqueta, cumplir con los requisitos comunes "*:WriteTag" descritos en otra parte y, a continuación, convertir la etiqueta NDEF de lectura/escritura a solo lectura.

Registro NDEF vacío: "NDEF:Empty"

No hay ningún tipo, identificador ni carga en este mensaje. Parece que las suscripciones con el tipo "NDEF:Empty" no tienen sentido desde el punto de vista de un cliente de Windows.

Acciones necesarias

El controlador del proveedor de proximidad debe rechazar suscripciones o publicaciones con este tipo con STATUS_INVALID_PARAMETER.

Suscripciones para todos los tipos de NDEF: "NDEF"

Los clientes pueden suscribirse a todos los mensajes NDEF recibidos. Normalmente, si la aplicación conoce el tipo de mensaje que le interesa, se suscribirá específicamente a ese tipo. Sin embargo, a veces resulta útil suscribirse a todos los mensajes NDEF. Por ejemplo, una aplicación que puede copiar y escribir una etiqueta NDEF duplicada podría resultar útil.

Acciones necesarias

El controlador DEBE hacer coincidir cada suscripción de "NDEF" con cada mensaje de NDEF que recibe.

Suscripciones para tipos RTD de NDEF externos: "NDEF:ext".

Los proveedores pueden usar un espacio de nombres RTD extensible personalizado para definir el contenido de sus mensajes propietarios. Esto permite a un cliente suscribirse a tipos externos RTD definidos no por el foro NFC, sino por la aplicación o un tercero.

Tipo de ejemplo genérico: "NDEF:ext.<SomeExternalType>"

Tipo de ejemplo concreto: "NDEF:ext.contoso.com:mytype"

Acciones necesarias

El controlador DEBE coincidir las suscripciones de "NDEF:ext.<SomeExternalType>" SOLO con los mensajes NDEF recibidos que tengan un valor de campo TNF de 0x04 y que tengan un campo TYPE que coincida con "<SomeExternalType>" según las reglas de equivalencia especificadas en [NFC RTD].

Suscripciones para "NDEF:MIME".

Los mensajes pueden usar el espacio de nombres MIME para definir el contenido del mensaje.

Tipo de ejemplo genérico: "NDEF:MIME.<SomeMimeType>"

Tipo de ejemplo concreto: "NDEF:MIME.image/jpeg"

Acciones necesarias

El controlador DEBE hacer coincidir las suscripciones de "NDEF:MIME.<SomeMimeType>" ÚNICAMENTE con los mensajes NDEF recibidos que tienen un valor del campo TNF de 0x02 y que tienen un campo TYPE que coincide con "<SomeMimeType>" basado en las reglas de equivalencia especificadas en [NDEF].

Suscripciones para "NDEF:wkt".

Los mensajes pueden usar el espacio de nombres de tipo conocido del foro NFC para definir el contenido del mensaje.

Acciones necesarias

  • El controlador DEBE coincidir las suscripciones para "NDEF:wkt.<SomeWellKnownType>" SOLO con mensajes NDEF recibidos que tienen un valor de campo TNF de 0x01 y cuyo campo TYPE coincida con "<SomeWellKnownType>" en función de las reglas de equivalencia especificadas en [NDEF].
  • El controlador NO DEBE validar tipos conocidos, de modo que los futuros tipos conocidos se puedan definir mediante el foro NFC sin necesidad de actualizar el controlador.

Suscripciones para el tipo NDEF desconocido: "NDEF:Unknown"

Esto permite que un cliente se suscriba a una carga de datos sin tipo definido.

Acciones necesarias

El controlador DEBE emparejar las suscripciones de "NDEF:Unknown" SOLO con mensajes NDEF que tengan un valor de campo TNF de 0x05, tal como se especifica en [NDEF].

Referencia de la API de comunicaciones de campo cercano (NFC)

  • Last updated on