Partager via

Protocole NDEF

  • Article

Le protocole « NDEF » est un moyen d’interagir directement avec des appareils NFC Forum, tels qu’ils sont mappés via le modèle pub/sub du fournisseur NFP. Tout client utilisant ce protocole doit comprendre comment encoder et décoder des paquets NDEF. Pour la publication de messages, un client spécifie simplement le type « NDEF », car le reste des informations de type est incorporé dans le message NDEF lui-même. La publication de types « NDEF » permet à un client d’accéder quasiment directement à des messages NDEF via NFC. Pour s’abonner, un client doit spécifier « NDEF » suivi d’un « : » (deux-points).

Les deux-points sont l’un des six types d’enregistrements.

  • Vide
  • Poste
  • MIME
  • URI
  • Wkt
  • Unknown

Un fournisseur prend en charge NDEF en suivant les exigences de base du fournisseur ainsi que les exigences spécifiques au protocole NDEF répertoriées dans cette section.

Pour écouter ces messages NDEF, un client s’abonne à l’un des types pris en charge, par exemple « NDEF :wkt. Sp ». Chaque fois que le fournisseur détecte un message NDEF qui correspond au type, l’intégralité du message NDEF (toujours encodé en NDEF) est remise au client abonné. Conformément à la convention dans [NDEF], le « type » à mettre en correspondance pour un message NDEF est le champ TYPE spécifié dans le premier enregistrement NDEF d’un message NDEF. Là encore, pour transmettre un message NDEF, un client publie un message NDEF complet spécifiant un protocole « NDEF ».

Il existe également un mécanisme pour s’abonner à TOUS les messages NDEF ; Pour ce faire, vous vous abonnez à « NDEF ».

Exigences courantes du pilote de protocole NDEF

Il existe plusieurs exigences courantes pour la prise en charge de NDEF sur les pilotes de tous les fournisseurs NFP compatibles NFC.

Mesures à prendre

  • Le pilote DOIT faire correspondre les messages NDEF reçus aux abonnements en fonction des champs TNF et TYPE du premier enregistrement NDEF dans le message NDEF, comme spécifié dans [NDEF].
  • Si une ou plusieurs publications « * :WriteTag » sont activées et que le pilote détecte une balise accessible en écriture avec suffisamment d’espace disponible, la charge utile existante de la balise NE DOIT PAS être lue pour les besoins de la correspondance avec d’autres abonnements. Cela permet à une application d’écriture de balises de préempter d’autres applications ou services qui peuvent être abonnés à des messages sur des balises.
  • Pour les fournisseurs NFP compatibles NFC, le pilote NE DOIT PAS transmettre les publications « * :WriteTag » lorsqu’il est connecté à un appareil de forum NFC (par opposition à une balise de forum NFC).
  • Si une ou plusieurs publications « * :WriteTag » sont activées au moment où le pilote détecte une balise accessible en écriture avec suffisamment d’espace disponible pour au moins une des charges utiles, le pilote DOIT écrire exactement l’une des charges utiles dans la balise. o Dans le cas où plusieurs publications sont actives et suffisamment petites pour être écrites dans une balise, la dernière publication « * :WriteTag » créée ou activée doit être celle écrite.
  • Si une publication « * :WriteTag » est créée ou activée alors que le pilote est actuellement en communication avec une balise accessible en écriture avec suffisamment d’espace disponible pour la charge utile, le pilote DOIT écrire la charge utile dans la balise même si le pilote a précédemment écrit dans la balise.
  • Le pilote DOIT écrire dans les balises de telle sorte que le contenu précédent soit remplacé.
  • Si une charge utile « * :WriteTag » est correctement écrite dans une balise, le pilote DOIT déclencher la gestion IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE (comme spécifié ci-dessus) pour cette publication.

Publications pour « NDEF :WriteTag »

Il s’agit d’un type spécial de publication qui permet d’écrire un ou plusieurs messages NDEF dans une balise NFC Forum.

Mesures à prendre

  • Les exigences courantes « * :WriteTag » décrites ailleurs s’appliquent.
  • Étant donné qu’une balise FORUM NFC peut contenir plusieurs messages NDEF, le pilote DOIT accepter correctement les publications « NDEF :WriteTag » qui ont plusieurs messages NDEF concaténés comme charge utile.

Publications pour « SetTagReadOnly »

Cette publication permet au client de verrouiller une balise en lecture seule. Le fournisseur doit convertir une balise de lecture/écriture NDEF déjà mise en forme en lecture seule.

Mesures à prendre

  • Le pilote doit d’abord case activée si la balise connectée est conforme À NDEF.
  • Si un ou plusieurs « * :. Les publications WriteTag » sont activées et le pilote détecte une balise accessible en écriture, le pilote DOIT d’abord écrire dans la balise, en respectant les exigences courantes « * :WriteTag » décrites ailleurs, puis convertir la balise de lecture/écriture NDEF en lecture seule.

Enregistrement NDEF vide : « NDEF :Empty »

Il n’y a aucun type, ID ou charge utile dans ce message. Il semble que les abonnements de type « NDEF :Empty » n’ont aucun sens du point de vue d’un client Windows.

Mesures à prendre

Les abonnements ou les publications de ce type DOIVENT être rejetés par le pilote du fournisseur de proximité avec STATUS_INVALID_PARAMETER.

Abonnements pour tous les types NDEF : « NDEF »

Les clients peuvent s’abonner à tous les messages NDEF reçus. En règle générale, si l’application connaît le type de message qui l’intéresse, elle s’abonnera à ce type spécifiquement. Toutefois, il est parfois utile de s’abonner à chaque message NDEF. Par exemple, une application qui peut copier et écrire une balise NDEF en double peut trouver cela utile.

Mesures à prendre

Le pilote DOIT correspondre aux abonnements pour « NDEF » avec chaque message NDEF qu’il reçoit.

Abonnements pour les types NDEF RTD externes : « NDEF :ext ».

Les fournisseurs peuvent utiliser un espace de noms RTD extensible personnalisé pour définir le contenu de leurs messages propriétaires. Cela permet à un client de s’abonner à des types externes RTD définis non pas par le forum NFC, mais par l’application ou un tiers.

Exemple de type générique : « NDEF :ext.<SomeExternalType> »

Type d’exemple concret : « NDEF :ext.contoso.com :mytype »

Mesures à prendre

Le pilote DOIT correspondre aux abonnements pour « NDEF :ext.<SomeExternalType> » UNIQUEMENT avec les messages NDEF reçus qui ont une valeur de champ TNF de 0x04 et qui ont un champ TYPE qui correspond à «< SomeExternalType> » en fonction des règles d’équivalence spécifiées dans [NFC RTD].

Abonnements pour « NDEF :MIME ».

Les messages peuvent utiliser l’espace de noms MIME pour définir le contenu du message.

Type d’exemple générique : « NDEF :MIME.<SomeMimeType> »

Exemple de type concret : « NDEF :MIME.image/jpeg »

Mesures à prendre

Le pilote DOIT correspondre aux abonnements pour « NDEF :MIME.<SomeMimeType> » UNIQUEMENT avec les messages NDEF reçus qui ont une valeur de champ TNF de 0x02 et qui ont un champ TYPE qui correspond à «< SomeMimeType> » en fonction des règles d’équivalence spécifiées dans [NDEF].

Abonnements pour « NDEF :wkt ».

Les messages peuvent utiliser l’espace de noms Nfc Forum Well Known Type pour définir le contenu du message.

Mesures à prendre

  • Le pilote DOIT correspondre aux abonnements pour « NDEF :wkt.<SomeWellKnownType> » UNIQUEMENT avec les messages NDEF reçus qui ont une valeur de champ TNF de 0x01 et qui ont un champ TYPE qui correspond à «< SomeWellKnownType> » en fonction des règles d’équivalence spécifiées dans [NDEF].
  • Le pilote NE DOIT PAS valider les types connus, afin que les futurs types connus puissent être définis par le forum NFC sans nécessiter de mise à jour du pilote.

Abonnements pour le type NDEF inconnu : « NDEF :Unknown »

Cela permet à un client de s’abonner à une charge utile de données non typée.

Mesures à prendre

Le pilote DOIT faire correspondre les abonnements pour « NDEF :Unknown » UNIQUEMENT avec les messages NDEF dont la valeur de champ TNF est 0x05 comme spécifié dans [NDEF].

Informations de référence sur l’API NFC (Near Field Communications)