5 ms·

> give me a binary protocol to parse any time I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my y

> give me a binary protocol to parse any time I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my years and that is an extremely painful thing to deal with compared to text-based protocols.

chrismorgan 5y ago
Ugh, flashbacks. Now that you’ve mentioned that I feel the burning need to change my wording to add the condition “fairly described”. I have also come across very poorly documented binary protocols!
jrockway 5y ago
I think it's pretty easy to make poor use of HTTP to the same end. Imagine you're dumping traffic between a client and a server and the exchange is: GET /asdfasdfasdfdsaf X-Asdf-Asdf: 83e7234 HTTP/1.0 202 X-83e7233: 1 X-83f730b: 4 It's text, but you still have no idea what's going on. Overall, I think it's kind of a wash. It's basically equally easy to take a documented text or binary protocol and write a working parser. Neither format solves any intrinsic problems -- malicious input has to be accounted for, you have to write fuzz tests, you have to deal with broken producers. It's a wash. People like text because they can type it into telnet and see something work, which is kind of cool, but probably not a productive use of time. I can type HTTP messages, but use curl anyway. (SMTP was always my favorite. "HELO there / MAIL FROM foo / RCPT TO bar / email body / ." Felt like a real conversation going on. Still not sure how to send an email that consists of a single dot on its own line though.)
- taejo 5y ago
  > Still not sure how to send an email that consists of a single dot on its own line though. A line starting with a period is escaped by adding an extra period; the receiving side removes the first character of a line if it is a period.
- knome 5y ago
  >Still not sure how to send an email that consists of a single dot on its own line though. It seems you prefix any line of data starting with a period with an additional period, to therefore distinguish it from the end of mail period. https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2 https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2

chrismorgan 5y ago

Ugh, flashbacks. Now that you’ve mentioned that I feel the burning need to change my wording to add the condition “fairly described”. I have also come across very poorly documented binary protocols!

jrockway 5y ago

I think it's pretty easy to make poor use of HTTP to the same end. Imagine you're dumping traffic between a client and a server and the exchange is: GET /asdfasdfasdfdsaf X-Asdf-Asdf: 83e7234 HTTP/1.0 202 X-83e7233: 1 X-83f730b: 4 It's text, but you still have no idea what's going on. Overall, I think it's kind of a wash. It's basically equally easy to take a documented text or binary protocol and write a working parser. Neither format solves any intrinsic problems -- malicious input has to be accounted for, you have to write fuzz tests, you have to deal with broken producers. It's a wash. People like text because they can type it into telnet and see something work, which is kind of cool, but probably not a productive use of time. I can type HTTP messages, but use curl anyway. (SMTP was always my favorite. "HELO there / MAIL FROM foo / RCPT TO bar / email body / ." Felt like a real conversation going on. Still not sure how to send an email that consists of a single dot on its own line though.)

taejo 5y ago
> Still not sure how to send an email that consists of a single dot on its own line though. A line starting with a period is escaped by adding an extra period; the receiving side removes the first character of a line if it is a period.
knome 5y ago
>Still not sure how to send an email that consists of a single dot on its own line though. It seems you prefix any line of data starting with a period with an additional period, to therefore distinguish it from the end of mail period. https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2 https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2