Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ASN.1
 David Brownell wrote: >Charles Reitzel wrote: >> I would suggest to folks who need this level of data type reuse and/or >> sophistication that they look into ASN.1 ... Perhaps most important, >> all datatypes defined using ASN.1 have a standard, unambiguous method of >> encoding the data for transmission on the wire. These rules are known as >> the "Basic Encoding Rules", or BER, of ASN.1. > >A handful of points there. First, ASN.1 is generally accepted to be far >more complex than is justifiable for most applications. Second, there >are multiple syntaxes (the newer one is more cryptic than the original). >Third, BER is not the only standardized encoding ... there's also DER, which >is a bit more widely used. (X.509 certs use BER, but most everything else >uses DER ... think of BER as "canonical DER".) Choices, choices. Never heard of DER. X.500, SSL, LDAP and SNMP all use BER. BER is really quite simple (or at least the subset needed by the above protocols). Open Source libs to encode/decode BER abound. It boils down to defining a decent set of primitive types and their respective on-the-wire images. Complex types are sequences of the primitive types. Is that a bad thing? Perhaps not appropriate for some applications, hence XML. >And fourth, DER and BER are examples of a philosophy of protocol development >that's been largely discredited for mainstream applications: "bitstuffing". >It was a design principle that bit efficiency was more important than time >spent to encode or decode ... perhaps understandable for systems using X.25 >networks where you more or less paid by the byte, but not on a LAN or even >the Internet. Many folk think DER/BER should be the first to be put against >the wall when the revolution (XML?) comes; they're that unpleasant to use. Never heard of bit stuffing either. Philosophy is the least of my concerns. Rather, I care about the ability to handle standard and custom data types in a hetergeneous network of cooperating applications! >> So, I would use ... >> ASN.1 based private protocol for custom application work. > >At the risk of touching off a religious war, I'd not suggest anyone >inflict ASN.1 on themselves, ever! Unless they're plugging into an >existing system based on it ... and even then, they should think about >whether it's practical to replace/supplant that existing system. Well reasonable people can agree to disagree. Clearly, there are many people who feel as you do. No doubt the full blown ASN.1 is a bit of a bear. I don't think any one protocol uses all of it. It has solved, in an elegant way, some of the problems that remain ugly in XML (to whit FPI's and namespaces, encoding of standard datatypes: numeric, date, time, etc.). Anyone who can write Java or C++ will have no problem learning to write ASN.1 statements. I submit that it is an expiditious approach to application protocol development. Bottom line, I'm saying leave that messy inheritance stuff out of XML because it's already been done in a standard way by ASN.1. Best regards, Charles Reitzel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
