9.10.1 The push() method doesn't mention how record data is verified

[kenchris]

Like it just states that things should be of type NFCMessageInit, but there is no verification that for instance recordType isn't set to bogus values like "blah-blah". It seems pretty vague, and just trusts that people look at the data mapping table and known how to follow that, but it doesn't even refer to that today

I wonder how we implemented this

[riju]

9.10.1 Step 10.14. .. ah too much nesting, basically this step ->

Initiate data transfer to device using output as buffer, using the NFC adapter in communication range with (connected to) device.

Did you mean "overflow" errors? Like developer trying to push more than tag capacity ?
What else should platform verify?

[leonhsl]

10.8 of https://w3c.github.io/web-nfc/#the-push-method states:

Let output be the notation for the NDEF message to be created by UA, as the result of passing message to create Web NFC message. If this throws an exception, reject p with that exception and abort these steps.

And 'create Web NFC message' process verifies data of NDEFMessageInit, like an invalid record type as 'blablabla'. See https://w3c.github.io/web-nfc/#creating-web-nfc-message

[zolkis]

Right now the implementation (and the underlying platform) decide what to do with the input received from a web page.

I suggest we factor out from the push steps the "validate NDEFMessage" steps, eventually relying on "validate NDEFRecord" steps.

[kenchris]

Please do! 👍

[zolkis]

Might be still valid, reopening until confirmed.

[beaufortfrancois]

@zolkis Can we close it or is this issue still valid?

[zolkis]

As to the opening comment, I think the algorithms do deal with bogus input (since they react only on valid values and throw otherwise). But it would be good to have a second look at it, maybe @leonhsl could you check the "create" algorithms and close the issue if it's the case?

[leonhsl]

https://w3c.github.io/web-nfc/#creating-ndef-message is verifying various user input, in this respect I think we can close this one.