Это, безусловно, не зависит от реализации. То есть, если разные реализации обрабатывают это по-разному, одна из них делает это неправильно.
Если вы собираетесь декодировать неизвестные поля, используя декодер, который не ожидает неизвестных полей, декодирование должно завершиться неудачно. Он не будет пропускать неизвестные поля.
Однако есть способ предоставить дополнительные поля еще до того, как они станут известны. Это использовать маркер расширения ("..."). Допустим, мы разрабатываем различные версии спецификации ASN.1. Давайте назовем их V1, V2, V3 и т. Д. V1 - это оригинальная спецификация, но мы понимаем, что во время разработки V1, вероятно, нам придется изменить ее в какой-то момент. Чтобы позволить это, вместо чего-то вроде
Z ::= SEQUENCE { a INTEGER,
b OCTET STRING,
c Message1
}
мы бы объявили Z расширяемым, как это
Z ::= SEQUENCE { a INTEGER,
b OCTET STRING,
c Message1,
...
}
Маркер расширения говорит о том, что после c может быть больше полей, которые пока неизвестны. Декодер должен обрабатывать сообщения, содержащие такие поля, если они следуют c, как допустимые. Декодер не сможет их декодировать, поскольку он не знает, какими они должны быть, но знает, что они допустимы.
Допустим, мы обновляем V1 до V2, вставляя два новых поля, примерно так:
Z ::= SEQUENCE { a INTEGER, -- V1
b OCTET STRING, -- V1
c Message1, -- V1
...,
[[ d PrintableString, -- V2
e BOOLEAN ]] -- V2
}
В этом случае версия V1 может взаимодействовать с версией V2. Кодер V1 не будет включать d или e, тогда как кодер V2 будет включать их. С точки зрения декодера, декодер V1 будет принимать (но не декодировать) d и e, тогда как декодер V2 будет декодировать d и e, если они найдены. Таким образом, декодер V1 будет принимать кодировки V1 и V2, игнорируя d и e всякий раз, когда они найдены; декодер V2 также будет принимать кодировки V1 и V2, отмечая, что кодировка V1 не будет включать d или e, но она остается действительной.
Мы можем продолжить это через дополнительные версии, например,
Z ::= SEQUENCE { a INTEGER, -- V1
b OCTET STRING, -- V1
c Message1, -- V1
...,
[[ d PrintableString, -- V2
e BOOLEAN ]], -- V2
[[ f PrintableString, -- V3
g ExtensionMessage]] -- V3
}
где V1, V2 и V3 могут взаимодействовать.
Обратите внимание, что, поскольку мы имеем дело с ПОСЛЕДОВАТЕЛЬНОСТЬЮ, порядок должен быть сохранен. Вы не могли бы иметь e без d, и g без d, e и f.
Таким образом, можно сделать вывод, что если ваше определение типа включает в себя маркеры расширения, вы можете добавлять новые поля, но если это не так, вы не можете.