MSPA Activity control support for api keys with v1 suffix

[PhreeMason]

The U.S. National Privacy section currently has a discrepancy between the documented client side API prefix and how it is implemented via the GPP stub file.

Some sites use "usca" api prefix while others use "uscav1".

Sections Prefix table

State	Number	Code	Description
California	8	usca/uscav1*	US - California section
Colorado	10	usco/uscov1*	US - Colorado section
Connecticut	12	usct/usctv1*	US - Connecticut section
Utah	11	usut/usutv1*	US - Utah section
Virginia	9	usva/usvav1*	US - Virginia section
All other U.S. states	7	usnat/usnatv1*	US - national section

Noted here , here, and here.

This can also be verified by running the following command to verify supported apis for gpp string.

__gpp("ping", function (data, success) {
  console.log(data);
});

Type of change

• Bugfix

Description of change

Other information

[patmmccann]

@PhreeMason we consider the v1 suffix simply incorrect. Do you have any resource suggesting otherwise?

Cc @lamrowena @jaredmoscow

[patmmccann]

Stub` was correct and without suffices on sections 7+ before and after this PR one year ago. I am not sure why the sourcepoint documentation suggests an ongoing issue. Perhaps they are referring to another source?

InteractiveAdvertisingBureau/Global-Privacy-Platform@8fa9953

This is the source of truth: https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md

[PhreeMason]

@PhreeMason we consider the v1 suffix simply incorrect. Do you have any resource suggesting otherwise?

Cc @lamrowena @jaredmoscow

Yeah in the IAB docs it is referred to as an api prefix. Also their implementation libraries use the v1 prefix so any CMP using their library will end up with v1 strings.

[patmmccann]

Those v1 strings remain incorrect. I am not sure we want to encourage poor cmp behavior when the GPP committee has been very clear these strings should not be expressed this way.

[patmmccann]

The JS IABTL GPP library has a fix in progress. IABTechLab/iabgpp-es#24 and IABTechLab/iabgpp-es#54 . Instead of pulling on this project to accept the wrong value, why not fix the IABTL java repo?

[PhreeMason]

The JS IABTL GPP library has a fix in progress. IABTechLab/iabgpp-es#24 and IABTechLab/iabgpp-es#54 . Instead of pulling on this project to accept the wrong value, why not fix the IABTL java repo?

I see that there is already a fix in the Java repo. I gave it a +1.

Since that also fixes the issue I will close this PR and simply get the latest from the Java repo once its merged.

[patmmccann]

fwiw i only see the fix in the iabtl js repo, i cant find the java fix