[RFC] doc: Add MTU parameter to the Get Attribute Value response

[michal-narajowski]

In test cases like GATT/SR/GAR/BV-01-C and GATT/SR/GAR/BV-06-C the PTS will randomly choose a handle on which it will perform ATT_Read_Request. If the value is longer than ATT_MTU then only the first ATT_MTU-1 octets will be included in the response. PTS then asks the Upper Tester to verify if IUT's database contains such value under that handle. In that situation the Upper tester will compare the actual value (which is long) with the short one returned by PTS. This will cause the test to fail randomly.

A proposed solution is to include a return parameter to the Get Attribute Value Response so that we can compare up to (ATT_MTU-1) bytes of value if the length of both values does not match.

[MariuszSkamra]

I'm wondering if it's the right place to put the MTU size, as it might be useful in other scenarios as well. What do you think about adding an BTP GATT event instead?

[KKopyscinski]

I think that if we want to check first bytes, from 0 to MTU-1, we could just check that in hdl_wid_52() i.e. using find() like so:

if value_read.find(MMI.args[1], 0, len(MMI.args[1])) == 0
    return True
else:
    return False'

That way we always check full value from MMI against first bytes of value_read (because find() would return non-zero otherwise)

[michal-narajowski]

@KKopyscinski We want to know the MTU because there may be a bug that the Nimble will respond with a wrong value. So either we have both values with the same length and then compare them as they are or the actual value is long and we want to compare (MTU-1) bytes. If the value in MMI is smaller then there may be a bug.

[KKopyscinski]

ok, makes sense