Why are there validations when GPP encoding?

[SNMY]

1. Regarding the GPP encoding and decoding, why must the length of bitString be a multiple of 8 first? We recently encountered some GPP strings like DBABzw~1YYNBVQVAAAAAg that don't meet this padding logic but can still be decoded via the IAB GPP Encoder / Decoder.
   Could you please share your thoughts on this?
   Thanks in advance.
2. We want to understand why there are validations for fields like mspaServiceProviderMode https://github.com/chuff/iabgpp-java/blob/master/iabgpp-encoder/src/main/java/com/iab/gpp/encoder/segment/UsNatV1CoreSegment.java. We cannot find this validation in the IAB GPP documentation.

We'd appreciate your insights on this matter. Thanks in advance.

[SNMY]

@iabmayank @Net-burst @chuff could you please help on this? Thanks in advance!

[Slukralle]

@chuff Regarding the first point here, is there a reason for the 8 bit length validation here? It doesn't seem to be consistent with the Official IAB GPP Decoder and GPP Specs. Could removal of this validation be in scope for being included in PR #66

if(bitString.length() % 8 > 0) { chars1 = new char[8 - (bitString.length() % 8)];

[chuff]

@Slukralle the code that you referenced isn't used for validation. It's actually used for padding prior to encoding.

[SNMY]

Hi, @chuff
We recently encountered some GPP strings like DBABzw~1YNN~BVQqAAAAAg that don’t follow the expected padding logic. Are these GPP strings are valid?
Why doesn’t the decoder enforce an 8-bit length check during decoding? Could you provide some insights into this behavior? Thanks!

[chuff]

I don't believe that string would be considered valid.

The decoder not enforcing a padding check was just an implementation decision to be less restrictive since an unpadded string can still be decoded.

[lamrowena]

Closing as validations have been removed.