I understand you're point. I can imagine some interesting things done with XSLT.
I guess I just haven't come across a case in practice (other than pretty printing) where I needed to decode without knowledge of the format of the data. I also feel that there are worse things done with ASN.1, from the standpoint of being able to parse the data in it's entirety without knowledge of the format, that make this implicit tagging issue pale in comparison, such as encoding entire objects into an OCTET STRING member of a structure. The value of an X.509 extension is a good example where, even in the absence of implicit tagging, the content of the extension value is largely unknown: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } Regards, Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Thursday, 8 September 2005 10:35 PM To: openssl-users@openssl.org Subject: RE: OCSP, Nonce and the requestExtensions > Is this a concern for real applications, things other than pretty > printers and protocol dumpers? Yes. > I agree that it makes it difficult to > understand the > content without a format description, but it's no worse than some > proprietary encoding. Is translating into XML without knowing the > "language" of the format something that needs to be done? Yes. A generic BER->XML converter and XML->BER converter would be very handy. That would easily let people interact with a variety of BER applications even in languages that don't manipulate raw binary very well. Another example is a C++ BER decoder. When an integer is received, it is expected to decode it into its integral value. But how can it do that if it can't tell what's an integer and what isn't? > I would have > thought that anything that isn't understood should be left as a "black > box" > blob for a downstream decoder to handle. The idea is to be able to convert BER encoded integers from the BER binary form to host form in once place. The idea is to convert BER encoded floating point values, bit streams, strings, and the like into the appropriate native format once, when they're received. It's a horrible mixing of layers to have the protocol engine receive decoded objects from the BER decoder and then have to pass objects into another BER decoder (or back into it), once it figured out what type they were. How fun would it be to code, say, a telnet server if TCP required a similar mechanism? > You get similar things in XML > where there might be a <Base64Certificate>MIIB...=</Base64Certificate>. I don't think they're really similar because it's not clear there's a better way in this case. It's obvious that BER can provide a better way -- explicit typing. Frankly, I think it's a real shame the BER specification didn't say that if you want to send a BER-encoded integer, you should do it in an object of type INTEGER. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]