<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-11-15 18:10 GMT+01:00 Nico Williams <span dir="ltr"><<a href="mailto:nico@cryptonector.com" target="_blank">nico@cryptonector.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, Nov 15, 2017 at 08:53:16AM +0000, Erwann ABALEA wrote:<br>
> > By using extensibility markers.  Which Protocol Buffers.. does not have.<br>
><br>
</span><span class="gmail-">> Correct. Or by declaring the module as EXTENSIBILITY IMPLIED, or simply by<br>
> using BER/DER (where extensibility is implied in the deciding phase even if<br>
> the module doesn't declare it).<br>
<br>
</span>Mind you, just using BER/DER/CER is not sufficient, since a decoder is<br>
free to produce an error when it sees unexpected SEQUENCE fields.  And<br>
for CHOICEs and SETs the extensibility markers are even more important.<br></blockquote><div><br></div><div>A decoder doing that wouldn't be compliant. X.690 Clause 8.1.1.4 forbids it.</div><div><br></div><div><div>8.1.1.4 Encodings specified in this Recommendation | International Standard are not affected by either the ASN.1 subtype notation or the ASN.1 type extensibility notation.</div><div>  NOTE – This means that all constraint notation is ignored when determining encodings, and all extensibility markers in CHOICE, SEQUENCE and SET are ignored, with the extensions treated as if they were in the extension root of the type.</div></div><div><br></div><div><br></div><div>The clause is present (without the NOTE) in the 1997 edition of the standard.</div></div><div><br></div>-- <br><div class="gmail_signature">Erwann.</div>
</div></div>