Protocolo NDEF
El protocolo "NDEF" es un medio para interactuar con dispositivos de foro NFC directamente como asignados a través del modelo pub/sub del proveedor NFP. Cualquier cliente que use este protocolo será necesario para comprender cómo codificar y descodificar 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 en el propio mensaje NDEF. La publicación de tipos "NDEF" permite a un cliente acceder casi directo de paso a través 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 seis tipos de registro.
- Vacío
- Ext
- MIME
- 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 coincidir con los mensajes NDEF recibidos en las suscripciones en función de los campos TNF y TYPE del primer registro NDEF del mensaje NDEF tal como se especifica en [NDEF].
- Si una o varias publicaciones "*:WriteTag" están habilitadas y el controlador detecta una etiqueta grabable con suficiente espacio disponible, la carga existente de la etiqueta NO debe leerse con el fin de buscar coincidencias con otras suscripciones. Esto permite que una aplicación de escritura de etiquetas adelante otras aplicaciones o servicios que puedan suscribirse a mensajes en 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 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 que uno o varios mensajes NDEF se escriban en una etiqueta de foro NFC.
Acciones necesarias
- Se aplican los requisitos comunes "*:WriteTag" descritos en otro lugar.
- 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 uno o varios "*:. Las publicaciones WriteTag" están habilitadas y el controlador detecta una etiqueta grabable, el controlador DEBE escribir primero en la etiqueta, cumpliendo los requisitos comunes "*:WriteTag" descritos en otro lugar y, a continuación, convierte la etiqueta de lectura y escritura de NDEF en solo lectura.
Registro NDEF vacío: "NDEF:Empty"
No hay ningún tipo, identificador o 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
Las suscripciones o publicaciones con este tipo DEBEN ser rechazadas por el controlador del proveedor de proximidad 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 cada mensaje NDEF. Por ejemplo, una aplicación que puede copiar y escribir una etiqueta NDEF duplicada podría resultar útil.
Acciones necesarias
El controlador DEBE coincidir con las suscripciones de "NDEF" con cada mensaje 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 con las suscripciones de "NDEF:ext.<SomeExternalType>" SOLO con mensajes NDEF recibidos que tienen un valor de campo TNF de 0x04 y que tienen un campo TYPE que coincide con "<SomeExternalType>" en función de 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 coincidir con las suscripciones de "NDEF:MIME.<SomeMimeType>" SOLO con mensajes NDEF recibidos que tienen un valor de campo TNF de 0x02 y que tienen un campo TYPE que coincide con "<SomeMimeType>" en función de 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 con las suscripciones de "NDEF:wkt.<SomeWellKnownType>" SOLO con mensajes NDEF recibidos que tienen un valor de campo TNF de 0x01 y que tienen un campo TYPE que coincide con "<SomeWellKnownType>" en función de las reglas de equivalencia especificadas en [NDEF].
- El controlador NO DEBE validar tipos conocidos, por lo que los futuros tipos conocidos se pueden definir mediante el foro NFC sin necesidad de una actualización del controlador.
Suscripciones para el tipo NDEF desconocido: "NDEF:Unknown"
Esto permite que un cliente se suscriba a una carga de datos sin tipo.
Acciones necesarias
El controlador DEBE coincidir con las suscripciones de "NDEF:Unknown" SOLO con mensajes NDEF que tienen un valor de campo TNF de 0x05 como se especifica en [NDEF].