Core lexical syntax
Lassi Kortela
(25 Sep 2019 10:15 UTC)
|
||
Re: Core lexical syntax
John Cowan
(25 Sep 2019 14:09 UTC)
|
||
Machines vs humans
Lassi Kortela
(25 Sep 2019 14:25 UTC)
|
||
Re: Core lexical syntax
Alaric Snell-Pym
(25 Sep 2019 15:44 UTC)
|
||
Re: Core lexical syntax
John Cowan
(25 Sep 2019 19:18 UTC)
|
||
Mechanism vs policy
Lassi Kortela
(25 Sep 2019 19:58 UTC)
|
||
Re: Mechanism vs policy
Arthur A. Gleckler
(25 Sep 2019 21:17 UTC)
|
||
Re: Mechanism vs policy
Lassi Kortela
(26 Sep 2019 07:40 UTC)
|
||
Re: Mechanism vs policy
John Cowan
(25 Sep 2019 22:25 UTC)
|
||
Re: Mechanism vs policy
Arthur A. Gleckler
(26 Sep 2019 01:34 UTC)
|
||
Limits, symbols and bytevectors, ASN.1 branding
Lassi Kortela
(26 Sep 2019 08:23 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
Alaric Snell-Pym
(26 Sep 2019 08:56 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
John Cowan
(27 Sep 2019 02:38 UTC)
|
||
ASN.1 branding Lassi Kortela (27 Sep 2019 14:56 UTC)
|
||
Re: ASN.1 branding
Alaric Snell-Pym
(27 Sep 2019 15:24 UTC)
|
||
Re: ASN.1 branding
Lassi Kortela
(27 Sep 2019 18:54 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
John Cowan
(27 Sep 2019 01:57 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
Lassi Kortela
(27 Sep 2019 16:24 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
John Cowan
(27 Sep 2019 17:37 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
Lassi Kortela
(27 Sep 2019 18:28 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
John Cowan
(27 Sep 2019 18:39 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
Lassi Kortela
(27 Sep 2019 18:46 UTC)
|
||
Re: Limits, symbols and bytevectors, ASN.1 branding
John Cowan
(27 Sep 2019 21:19 UTC)
|
||
Re: Mechanism vs policy
Alaric Snell-Pym
(26 Sep 2019 08:45 UTC)
|
||
Implementation limits
Lassi Kortela
(26 Sep 2019 08:57 UTC)
|
||
Re: Implementation limits
Alaric Snell-Pym
(26 Sep 2019 09:09 UTC)
|
||
Re: Implementation limits
Lassi Kortela
(26 Sep 2019 09:51 UTC)
|
||
Meaning of the word "format"
Lassi Kortela
(26 Sep 2019 10:31 UTC)
|
||
Stacking it all up
Lassi Kortela
(26 Sep 2019 11:05 UTC)
|
||
Brief spec-writing exercise
Lassi Kortela
(26 Sep 2019 11:46 UTC)
|
||
Re: Brief spec-writing exercise
John Cowan
(26 Sep 2019 15:45 UTC)
|
||
Standards vs specifications
Lassi Kortela
(26 Sep 2019 21:24 UTC)
|
||
Re: Standards vs specifications
John Cowan
(27 Sep 2019 04:29 UTC)
|
||
Re: Standards vs specifications
Lassi Kortela
(27 Sep 2019 13:47 UTC)
|
||
Re: Standards vs specifications
John Cowan
(27 Sep 2019 14:53 UTC)
|
||
Re: Meaning of the word "format"
John Cowan
(26 Sep 2019 20:59 UTC)
|
||
Re: Meaning of the word "format"
Lassi Kortela
(26 Sep 2019 21:09 UTC)
|
||
Re: Meaning of the word "format"
John Cowan
(27 Sep 2019 02:44 UTC)
|
||
Length bytes and lookahead in ASN.1
Lassi Kortela
(27 Sep 2019 13:58 UTC)
|
||
Re: Length bytes and lookahead in ASN.1
John Cowan
(27 Sep 2019 14:22 UTC)
|
||
Re: Length bytes and lookahead in ASN.1
Alaric Snell-Pym
(27 Sep 2019 15:02 UTC)
|
||
Re: Length bytes and lookahead in ASN.1
hga@xxxxxx
(27 Sep 2019 15:26 UTC)
|
||
(missing)
|
||
Fwd: Length bytes and lookahead in ASN.1
John Cowan
(27 Sep 2019 16:40 UTC)
|
||
Re: Fwd: Length bytes and lookahead in ASN.1
Alaric Snell-Pym
(27 Sep 2019 16:51 UTC)
|
||
Re: Fwd: Length bytes and lookahead in ASN.1
John Cowan
(27 Sep 2019 17:18 UTC)
|
||
Length bytes and lookahead in ASN.1
hga@xxxxxx
(27 Sep 2019 16:58 UTC)
|
||
Re: Length bytes and lookahead in ASN.1
John Cowan
(27 Sep 2019 17:21 UTC)
|
||
Re: Mechanism vs policy
John Cowan
(27 Sep 2019 03:52 UTC)
|
||
Re: Core lexical syntax
Alaric Snell-Pym
(26 Sep 2019 08:36 UTC)
|
||
Re: Core lexical syntax
John Cowan
(25 Sep 2019 14:13 UTC)
|
> Maybe LER should be the name of the textual format we're developing, then. > Except it will make Lassi's marketing iinstincts go ding-ding-ding-ding. lol. Okay, you asked for it :) Techies often like to throw the baby out with the bathwater with marketing concerns. In fact, a lot of it just boils down to making sense and getting to the point. Take "Encoding Rules" for example. How is "encoding rules" different from "encoding"? Isn't all encoding about following rules? Instead of "ASCII" we could say "ASCII Encoding Rules". What would be the point? Since ASN.1 is useful solely for its encodings, we can drop "encoding" from the names too, since what else would most users want to deal with? Now we have "Basic ASN.1", "Distinguished ASN.1" and "Lisp ASN.1", which are things one can read without their eyes glazing over. (Well, "ASN.1" scans weirdly but let it be. At least it's the cool end of weird.) I've dealt with many products of heavyweight specification processes and the alphabet soup has always puzzled me. There's something about poring over those specs that at some point makes ordinary people unable to write plainly anymore. At SpaceX there used to be an "Acronyms Seriously Suck" rule (which was of course justly shortened to the "ASS" rule). I digress. So these names are basically okay: * ASN.1 Basic * ASN.1 Packed * ASN.1 XML * ASN.1 JSON * ASN.1 Lisp These are still baffling: * Distinguished * Canonical * Encoding Control Notation * Canonical XML * Extended XML * Octet * Generic String Without knowing anything about them: "canonical", "distinguished" and "basic" sound like they should be the same thing. "Basic" is a good name. "Canonical" is a prankish way to say "normal". "Distinguished" sounds like "we made some mistakes when designing 'basic'; this is what it should have been". The fact that "basic" and "canonical" are different is suspect. If the point of "basic" is to be lighter than "canonical", it should be called "light" or "small" for clarity. But those sound the same as "packed"; what's the difference? And "extended" is a complicated way to say "large" or "heavy". Finally, "Octet" and "Generic String" are geek-speak so opaque that even geeks have no idea what they are, and "Encoding Control Notation" is the victory lap. So a set of sensible names would be for example: * ASN.1 Light * ASN.1 Normal * ASN.1 Heavy * ASN.1 XML * ASN.1 JSON * ASN.1 Lisp The above dissected mentality, applied top to bottom, is why even bright people's eyes glaze over whenever they try to find out what ASN.1 is. It gets worse when you actually go read about it: "The key difference between the BER format and the CER or DER formats is the flexibility provided by the Basic Encoding Rules." --- So the "basic" thing is more flexible than the things with the fancy names. "DER (Distinguished Encoding Rules) is a subset of BER providing for exactly one way to encode an ASN.1 value. DER is intended for situations when a unique encoding is needed. DER can be considered a canonical form of BER." --- The thing with the fancy name is more basic than the "basic" thing. And the "canonical" and "distinguished" encodings compete over who is more canonical. It's like old Coke and new Coke. This is why people prefer things that are "marketed". A clear message is not a guarantee that the people behind it can think clearly, but an confused message is a near-guarantee that the substance is equally confused. There may be an un-confused core struggling to get out, but it needs a great deal of help.