Lowercased country code fails with InvalidStructureResult

[Hoffs]

I have been looking at this for a while and can't find concrete information which way it should work. Right now I can see that the validation in StructureValidator tries to match first symbols with expected country code. As I see, because country code is lowercased it will not be equals to expected country code which is always uppercased:

IbanNet/src/IbanNet/Validation/StructureValidator.cs

Line 18 in 39f9b9a

if (iban[0] != _expectedCountryCode[0] && iban[1] != _expectedCountryCode[1])

But in other places, like Mod97 validation or finding iban country it uses upper cased ones, which makes it pass:

IbanNet/src/IbanNet/Validation/Rules/IsValidCountryCodeRule.cs

Lines 43 to 52 in 39f9b9a

	private static string? GetCountryCode(string value)
	{
	return value.Length < 2
	? null
	: new string(new[]
	{
	char.ToUpperInvariant(value[0]),
	char.ToUpperInvariant(value[1])
	});
	}

IbanNet/src/IbanNet/CheckDigits/Calculators/Mod97CheckDigitsCalculator.cs

Lines 47 to 50 in 39f9b9a

	// - For letters, always is two digits so shift 2 digits.
	// - Use bitwise OR with ' ' (space, 0x20) to convert char to lowercase.
	// - Then subtract 'a' to get value 0, 1, 2, etc.
	// - Last, add 10 so: - a = 10, b = 11, c = 12, etc.

So I wonder, is this valid and expected behavior?

[skwasjer]

The check digits calculation is correctly ignoring case, as is the country code rule. I think this is a remnant of older implementation where IbanNet was built around Swift registry specifically, but was refactored to support multiple providers. This specific country code check should actually be made a 'test' and injected as a StructureSegmentTest, this would solve the problem and allow Swift provider to still be strict but allow more relaxed providers to pass this check.

That said, using strict validation, it would still fail when you'd have an IBAN with lowercase further up in the IBAN (for countries that require upper case), so the next debate would be, should we allow this at all? This is also why there is a loose validation mode. Alternatively, the SwiftStructureValidationFactory could be opened up a bit for extensibility/configurability.

So in short, yes, it is expected behavior, or at least, lets call it originally as intended. The entire IBAN could perhaps be uppercased to solve the problem, but I have to investigate if that breaks the spec.