Protocolo NDEF
O protocolo "NDEF" é um meio de interagir com dispositivos nfc forum diretamente conforme mapeado por meio do modelo pub/sub do provedor NFP. Qualquer cliente que use esse protocolo será necessário para entender como codificar e decodificar pacotes NDEF. Para publicar mensagens, um cliente apenas especificaria o tipo como "NDEF", pois o restante das informações de tipo é inserido na própria mensagem NDEF. A publicação de tipos "NDEF" permite que um cliente quase direcione o acesso de passagem para enviar mensagens NDEF por NFC. Para assinar, um cliente especificaria "NDEF" seguido por um ':' (dois-pontos).
Após os dois-pontos, há um dos seis tipos de registro.
- Vazio
- Ext
- MIME
- URI
- Wkt
- Unknown
Um provedor dá suporte ao NDEF seguindo os requisitos básicos do provedor, bem como os requisitos específicos do protocolo NDEF listados nesta seção.
Para ouvir essas mensagens NDEF, um cliente assina um dos tipos com suporte, como "NDEF:wkt. Sp". Sempre que o provedor detecta uma mensagem NDEF que corresponde ao tipo, toda a mensagem NDEF (ainda codificada no NDEF) é entregue ao cliente inscrito. De acordo com a convenção em [NDEF], o 'tipo' a ser correspondido para uma mensagem NDEF é o campo TYPE especificado no primeiro registro NDEF de uma mensagem NDEF. Novamente, para transmitir uma mensagem NDEF, um cliente publica uma mensagem NDEF completa especificando um protocolo de "NDEF".
Também há um mecanismo para assinar todas as mensagens NDEF; isso é feito assinando o "NDEF".
Requisitos comuns do driver de protocolo NDEF
Há vários requisitos comuns para o suporte a NDEF nos drivers de todos os provedores NFP habilitados para NFC.
Ações necessárias
- O driver DEVE corresponder mensagens NDEF recebidas a assinaturas com base nos campos TNF e TYPE do primeiro registro NDEF na mensagem NDEF, conforme especificado em [NDEF].
- Se uma ou mais publicações "*:WriteTag" estiverem habilitadas e o driver detectar uma marca gravável com espaço suficiente disponível, o conteúdo existente da marca NÃO DEVERÁ ser lido para fins de correspondência de outras assinaturas. Isso permite que um aplicativo de gravação de marcas preempite outros aplicativos ou serviços que possam ser assinados em mensagens em marcas.
- Para provedores NFP habilitados para NFC, o driver NÃO DEVE transmitir publicações "*:WriteTag" quando conectado a um dispositivo nfc forum (em vez de uma marca nfc forum).
- Se uma ou mais publicações "*:WriteTag" estiverem habilitadas no momento em que o driver detectar uma marca gravável com espaço suficiente disponível para pelo menos uma das cargas, o driver DEVERÁ gravar exatamente uma das cargas na marca. o No caso de mais de uma publicação estar ativa e pequena o suficiente para ser gravada em uma marca, a publicação "*:WriteTag" criada ou habilitada mais recentemente DEVE ser a escrita.
- Se uma publicação "*:WriteTag" for criada ou habilitada enquanto o driver estiver atualmente em comunicação com uma marca gravável com espaço suficiente disponível para o conteúdo, o driver DEVERÁ gravar o conteúdo na marca, mesmo que o driver tenha gravado anteriormente na marca.
- O driver DEVE gravar em marcas de forma que o conteúdo anterior seja substituído.
- Se uma carga "*:WriteTag" for gravada com êxito em uma marca, o driver DEVERÁ disparar o tratamento de IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE (conforme especificado acima) para essa publicação.
Publicações para "NDEF:WriteTag"
Esse é um tipo especial de publicação que permite que uma ou mais mensagens NDEF sejam gravadas em uma marca do Fórum NFC.
Ações necessárias
- Os requisitos comuns de "*:WriteTag" descritos em outro lugar se aplicam.
- Como uma marca nfc forum pode conter várias mensagens NDEF, o driver DEVE aceitar corretamente publicações "NDEF:WriteTag" que têm várias mensagens NDEF concatenadas como conteúdo.
Publicações para "SetTagReadOnly"
Esta publicação permite que o cliente bloqueie uma marca somente leitura. O provedor deve converter uma marca de leitura/gravação NDEF já formatada em Somente leitura.
Ações necessárias
- O driver deve primeiro marcar se a marca conectada for compatível com NDEF.
- Se um ou mais "*:. As publicações WriteTag" estão habilitadas e o driver detecta uma marca gravável, o driver DEVE gravar na marca primeiro, aderindo aos requisitos comuns de "*:WriteTag" descritos em outro lugar e, em seguida, converter a marca de leitura/gravação NDEF para somente leitura.
Registro NDEF vazio: "NDEF:Empty"
Não há nenhum tipo, ID ou conteúdo nesta mensagem. Parece que as assinaturas com o tipo "NDEF:Empty" não fazem sentido do ponto de vista de um cliente Windows.
Ações necessárias
Assinaturas ou publicações com esse tipo DEVEM ser rejeitadas pelo driver do provedor de proximidade com STATUS_INVALID_PARAMETER.
Assinaturas para todos os tipos de NDEF: "NDEF"
Os clientes podem assinar todas as mensagens NDEF recebidas. Normalmente, se o aplicativo souber o tipo de mensagem em que está interessado, ele assinará esse tipo especificamente. No entanto, às vezes é útil assinar cada mensagem NDEF. Por exemplo, um aplicativo que pode copiar e gravar uma marca NDEF duplicada pode achar isso útil.
Ações necessárias
O driver DEVE corresponder assinaturas para "NDEF" com cada mensagem NDEF recebida.
Assinaturas para tipos RTD de NDEF externos: "NDEF:ext".
Os fornecedores podem usar um namespace RTD extensível personalizado para definir o conteúdo de suas mensagens proprietárias. Isso permite que um cliente assine tipos externos RTD definidos não pelo Fórum NFC, mas pelo aplicativo ou por terceiros.
Tipo de exemplo genérico: "NDEF:ext.<SomeExternalType>"
Tipo de exemplo concreto: "NDEF:ext.contoso.com:mytype"
Ações necessárias
O driver DEVE corresponder às assinaturas de "NDEF:ext.<SomeExternalType>" ONLY com mensagens NDEF recebidas que têm um valor de campo TNF de 0x04 e que têm um campo TYPE que corresponde a "<SomeExternalType>" com base nas regras de equivalência especificadas em [NFC RTD].
Assinaturas para "NDEF:MIME".
As mensagens podem usar o namespace MIME para definir o conteúdo da mensagem.
Tipo de exemplo genérico: "NDEF:MIME.<SomeMimeType>"
Tipo de exemplo concreto: "NDEF:MIME.image/jpeg"
Ações necessárias
O driver DEVE corresponder às assinaturas de "NDEF:MIME.<SomeMimeType>" SOMENTE com mensagens NDEF recebidas que têm um valor de campo TNF de 0x02 e que têm um campo TYPE que corresponde a "<SomeMimeType>" com base nas regras de equivalência especificadas em [NDEF].
Assinaturas para "NDEF:wkt".
As mensagens podem usar o namespace Tipo Conhecido do Fórum NFC para definir o conteúdo da mensagem.
Ações necessárias
- O driver DEVE corresponder às assinaturas de "NDEF:wkt.<SomeWellKnownType>" SOMENTE com mensagens NDEF recebidas que têm um valor de campo TNF de 0x01 e que têm um campo TYPE que corresponde a "<SomeWellKnownType>" com base nas regras de equivalência especificadas em [NDEF].
- O driver NÃO DEVE validar tipos conhecidos, para que tipos conhecidos futuros possam ser definidos pelo NFC Forum sem a necessidade de uma atualização de driver.
Assinaturas para tipo NDEF desconhecido: "NDEF:Unknown"
Isso permite que um cliente assine uma carga de dados não tipada.
Ações necessárias
O driver DEVE corresponder assinaturas para "NDEF:Unknown" somente com mensagens NDEF que tenham um valor de campo TNF de 0x05 conforme especificado em [NDEF].