Re: [Cryptography] encoding formats should not be committee'ised
On 10/04/2013 01:23 AM, James A. Donald wrote: On 2013-10-04 09:33, Phillip Hallam-Baker wrote: The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. That is fairly horrifying, as COM was designed for a single threaded environment, and becomes and incomprehensible and extraordinarily inefficient security hole in a multi threaded environment. Well, yes, as a matter of fact DCOM was always incomprehensible and extraordinarily inefficient. However, it wasn't so much of a security hole in the remotely crashable bug sense. It made session management into something of a difficult problem though. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Oct 3, 2013, at 7:33 PM, Phillip Hallam-Baker hal...@gmail.com wrote: XML was not intended to be easy to read, it was designed to be less painful to work with than SGML, that is all More to the point, it was designed to be a *markup* format. The markup is metadata describing various semantic attributes of the data. If you mark up a document, typically almost all the bytes are data, not metadata! TeX and the x-roff's are markup formats, though at a low level. LaTeX moves to a higher level. The markup commands in TeX or sroff or LaTeX documents are typically a couple of percent of the entire file. You can typically read the content, simply ignoring the markup, with little trouble. In fact, there are programs around at least for TeX and LaTeX that strip out all the markup so that you can read the content as just plain text. You can typically get the gist with little trouble. If you look at what XML actually ended up being used for, in many cases nearly the entire damn document is ... markup! The data being marked up becomes essentially vestigial. Strip out the XML and nothing is left. In and of itself, there may be nothing wrong with this. But it's why I object to the use of markup language to describe many contemporary uses of XML. It leads you to think you're getting something very different from what you actually do get. (The XML world has a habit of using words in unexpected ways. I had the damnedest time understanding much of the writing emanating from this world until I realized that when the XML world say semantics, you should read it as syntax. That key unlocks many otherwise-mysterious statements.) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On 2013-10-04 09:33, Phillip Hallam-Baker wrote: The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. That is fairly horrifying, as COM was designed for a single threaded environment, and becomes and incomprehensible and extraordinarily inefficient security hole in a multi threaded environment. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On 3/10/13 00:37 AM, Dave Horsfall wrote: On Wed, 2 Oct 2013, Jerry Leichter wrote: Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. Managers, in particular. SQL, too, had that goal. 4GLs (remember them?). XML. Has it ever worked? iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Thu, 3 Oct 2013, Peter Gutmann wrote: For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. In a previous life I had to read, understand, and debug EDIFACT (it was OpenLDAP, as I recall). It wasn't all that difficult; then again, at one time I had to know APL\360 (once described as a write-only language). Want crypto? Try obscurity :-) -- Dave ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Thu, Oct 3, 2013 at 5:19 AM, ianG i...@iang.org wrote: On 3/10/13 00:37 AM, Dave Horsfall wrote: On Wed, 2 Oct 2013, Jerry Leichter wrote: Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. Managers, in particular. SQL, too, had that goal. 4GLs (remember them?). XML. Has it ever worked? XML was not intended to be easy to read, it was designed to be less painful to work with than SGML, that is all. There are actually good reasons why a document markup format needs to have more features than a protocol data encoding format. People tend to edit documents and need continuous syntax checks for a start. XML is actually a good document format and a lousy RPC encoding. Although that is exactly what SOAP is designed to turn XML into. The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. What does work in my experience is to design a language that is highly targeted at a particular problem set. Like building FSRs or LR(1) parsers or encoding X.509 certificates (this week's work). And no, an ASN1 compiler is not a particularly useful tool for encoding X.509v3 certs as it turns out. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Wed, 2 Oct 2013, Jerry Leichter wrote: Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. Managers, in particular. -- Dave ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
