On 4/10/13 11:17 AM, Peter Gutmann wrote:
Trying to get back on track, I think any attempt at TLS 2 is doomed. We've
already gone through, what, about a million messages bikeshedding over the
encoding format and have barely started on the crypto. Can you imagine any
two people on this list
On 2/10/13 00:16 AM, James A. Donald wrote:
On 2013-10-02 05:18, Jerry Leichter wrote:
To be blunt, you have no idea what you're talking about. I worked at
Google until a short time ago; Ben Laurie still does. Both of us have
written, submitted, and reviewed substantial amounts of code in the
On Thu, Oct 3, 2013 at 1:35 PM, Lodewijk andré de la porte
l...@odewijk.nlwrote:
IMO readability is very hard to measure. Likely things being where you
expect them to be, with minimal confusing characters but clear anchoring
so you can start reading from anywhere.
If someone could write a
d...@geer.org writes:
The (U.S.) medical records system that started at the Veterans'
Administration and has now spread to all but all parts of the U.S. Federal
government that handle electronic health records is ASCII encoded, and
readable. Called The Blue Button,[1] there is even an HL7-Blue
Jerry Leichter leich...@lrw.com writes:
My favorite more recent example of the pitfalls is TL1, a language and
protocol used to managed high-end telecom equipment. TL1 has a completely
rigorous syntax definition, but is supposed to be readable.
For those not familiar with TL1, supposed to be
On 2013-10-02 23:09, Phillip Hallam-Baker wrote:
No, the reason for baring multiple inheritance is not that it is too
clever, it is that studies have shown that code using multiple
inheritance is much harder for other people to understand than code
using single inheritance.�
That is
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.
utter_tangent
The (U.S.) medical records system that started at the Veterans'
Administration and has now spread to all but all parts of the
On 2013-10-03 09:49, Peter Gutmann wrote:
Jerry Leichter leich...@lrw.com writes:
My favorite more recent example of the pitfalls is TL1, a language and
protocol used to managed high-end telecom equipment. TL1 has a completely
rigorous syntax definition, but is supposed to be readable.
IMO readability is very hard to measure. Likely things being where you
expect them to be, with minimal confusing characters but clear anchoring
so you can start reading from anywhere.
If someone could write a generative meta-language we can then ask people to
do text comprehension tasks on the
On 09/30/13 04:41, ianG wrote:
Experience suggests that asking a standards committee to do the encoding format
is a disaster.
I just looked at my code, which does something we call Wire, and it's 700 loc.
Testing code is about a kloc I suppose. Writing reference implementations is a
piece
Replying to James and John.
Yes, the early ARPANET protocols are much better than many that are in
binary formats. But the point where data encoding becomes an issue is where
you have nested structures. SMTP does not have nested structures or need
them. A lot of application protocols do.
I have
On Oct 2, 2013, at 10:46 AM, Viktor Dukhovni cryptogra...@dukhovni.org wrote:
Text encodings are easy to read but very difficult to specify
boundaries in without ambiguity.
Yes, and not just boundaries.
Always keep in mind - when you argue for easy readability - that one of
COBOL's design
On Mon, Sep 30, 2013 at 9:41 AM, Mark Atwood m...@mark.atwood.name wrote:
Well, there are Protobufs, and there is Thrift, and there is
MessagePack, and there is Avro...
Here's a crazy idea: instead of using one of these formats, use a human
readable format that can be described by a formal
On 1 October 2013 01:10, James A. Donald jam...@echeque.com wrote:
On 2013-10-01 04:22, Salz, Rich wrote:
designate some big player to do it, and follow suit?
Okay that data encoding scheme from Google protobufs or Facebook thrift.
Done.
We have a complie to generate C code from ASN.1
On 1 October 2013 09:46, James A. Donald jam...@echeque.com wrote:
On 2013-10-01 18:06, Ben Laurie wrote:
On 1 October 2013 01:10, James A. Donald jam...@echeque.com wrote:
Further, google is unhappy that too-clever-code gives too-clever
programmers too much power, and has prohibited
On Mon, Sep 30, 2013 at 6:04 PM, Mark Atwood m...@mark.atwood.name wrote:
YAML?
YAML is a bit insane ;) There's JSON, and also TOML:
https://github.com/mojombo/toml
--
Tony Arcieri
___
The cryptography mailing list
cryptography@metzdowd.com
On Mon, Sep 30, 2013 at 6:17 PM, Mark Atwood m...@mark.atwood.name wrote:
YAML is a superset of JSON
C++ is a (not completely proper) superset of C. Does that make it better? ;)
is more human readable, and, unlike JSON, has internal references.
YAML also has the property that indentation
On Sep 30, 2013, at 8:10 PM, James A. Donald wrote:
We have a complie to generate C code from ASN.1 code
Google has a compiler to generate C code from protobufs source
The ASN.1 compiler is open source. Google's compiler is not.
http://code.google.com/p/protobuf/source/checkout. BSD
Here's a crazy idea: instead of using one of these formats, use a
human readable format that can be described by a formal grammar
which is hopefully regular, context-free, or context-sensitive in a
limited manner
YAML?
On Mon, Sep 30, 2013 at 5:48 PM, Tony Arcieri basc...@gmail.com wrote:
YAML is a superset of JSON, is more human readable, and, unlike JSON,
has internal references.
On Mon, Sep 30, 2013 at 6:14 PM, Tony Arcieri basc...@gmail.com wrote:
On Mon, Sep 30, 2013 at 6:04 PM, Mark Atwood m...@mark.atwood.name wrote:
YAML?
YAML is a bit insane ;) There's JSON, and
On 2013-10-01 18:06, Ben Laurie wrote:
On 1 October 2013 01:10, James A. Donald jam...@echeque.com
mailto:jam...@echeque.com wrote:
Further, google is unhappy that too-clever-code gives too-clever
programmers too much power, and has prohibited its employees from
ever doing
On 2013-10-01 22:08, Salz, Rich wrote:
Further, google is unhappy that too-clever-code gives too-clever programmers
too much power, and has prohibited its employees from ever doing something like
protobufs again.
Got any documentation for this assertion?
The google style guide prohibits
On Oct 1, 2013, at 12:28 PM, James A. Donald jam...@echeque.com wrote:
Further, google is unhappy that too-clever-code gives too-clever
programmers too much power, and has prohibited its employees from ever
doing something like protobufs again.
Got any documentation for this assertion?
The
On Mon, Sep 30, 2013 at 1:41 AM, ianG i...@iang.org wrote:
Experience suggests that asking a standards committee to do the encoding
format is a disaster.
I just looked at my code, which does something we call Wire, and it's 700
loc. Testing code is about a kloc I suppose. Writing reference
Here's a crazy idea: instead of using one of these formats, use a
human readable format that can be described by a formal grammar
which is hopefully regular, context-free, or context-sensitive in a
limited manner
If only we could channel the late Jon Postel. Didn't you ever notice
how
On 2013-10-02 05:18, Jerry Leichter wrote:
To be blunt, you have no idea what you're talking about. I worked at
Google until a short time ago; Ben Laurie still does. Both of us have
written, submitted, and reviewed substantial amounts of code in the
Google code base. Do you really want to
Why can't we just designate some big player to do it, and follow suit? Why
argue in committee?
Well, there are Protobufs, and there is Thrift, and there is
MessagePack, and there is Avro...
http://www.igvita.com/2011/08/01/protocol-buffers-avro-thrift-messagepack/
..m
On 2013-10-01 04:22, Salz, Rich wrote:
designate some big player to do it, and follow suit?
Okay that data encoding scheme from Google protobufs or Facebook thrift. Done.
We have a complie to generate C code from ASN.1 code
Google has a compiler to generate C code from protobufs source
The
28 matches
Mail list logo
