Proposal: Support dynamic message specs based on MTI or field values

[Stashchenko]

Proposal: Dynamic MessageSpec Switching During Parsing

Summary

Currently, the iso8583 library uses a single static MessageSpec for parsing and building messages.
However, in real-world scenarios (especially in MasterCard, Visa, or proprietary switch implementations), the field definitions can differ depending on the Message Type Indicator (MTI) or even the value of other fields (such as DE 24 or DE 48 subfields).

This limitation makes it difficult to correctly parse messages when a single spec must adapt to multiple variants.

---

Example Use Case

For example:

• For MTI 0800 (Network Management Request), DE 48 may contain a specific set of subelements.
• For MTI 0100 (Authorization Request), DE 48 could have a completely different structure.

Currently, developers must either:

1. Maintain multiple specs and manually select one before parsing, or
2. Define a large "superset" spec that makes many fields optional (which is inefficient and error-prone).

---

❓ Any ideas how to implement this?

[alovak]

That's an interesting request.

I'm thinking about this:

          48: field.NewConditionalField(
              []field.FieldVariant{
                  {
                      Name: "Network Management (0800/0810)",
                      Condition: func(...) bool { return .... },
                      Field: field.NewComposite(&field.Spec{
                          Length:      6,
                          Description: "Network Management Information",
                          Pref:        prefix.ASCII.Fixed,
                          Tag: &field.TagSpec{
                              Sort: sort.StringsByInt,
                          },
                          Subfields: map[string]field.Field{
                              "1": field.NewString(&field.Spec{
                                  Length:      4,
                                  Description: "Message Number",
                                  Enc:         encoding.ASCII,
                                  Pref:        prefix.ASCII.Fixed,
                              }),
                              "2": field.NewString(&field.Spec{
                                  Length:      2,
                                  Description: "Message Priority",
                                  Enc:         encoding.ASCII,
                                  Pref:        prefix.ASCII.Fixed,
                              }),
                          },
                      }),
                  },
              },
              // Default field (much cleaner than a variant with always-true condition)
              field.NewString(&field.Spec{
                  Length:      999,
                  Description: "Additional Data - Private",
                  Enc:         encoding.ASCII,
                  Pref:        prefix.ASCII.LLL,
              }),
          ),
      },

Not sure yet about:

• what we can use in condition, parsed message, binary value to parse, maybe both
• how packing and unpacking will work
• how marshal and unmarshal will work

But, in general I like the idea and understand the need of it.

[Stashchenko]

Yep, I guess we need both parsed data from the message itself or some extra flags which might be set before we parse the message.

[evidencem]

This proposed NewConditionalField field would really be helpful in what I'm currently working on right now.