https://pinboard.in/u:jm/public/ recent bookmarks from jm 2025-08-25T16:20:35+00:00 https://lobste.rs/s/gvtlpo/email_is_easy_email_address_quiz#c_vkssdf jm email history 1970s via:fanf smtp ietf standards internet https://pinboard.in/ https://pinboard.in/u:jm/b:219e04c983b2/ 2023-03-28T08:45:07+00:00 https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header-02 jm via:nurkiewicz idempotency http standards ietf rest apis https://pinboard.in/ https://pinboard.in/u:jm/b:f19faee78889/ 2019-09-12T15:54:03+00:00 https://mailarchive.ietf.org/arch/msg/dnsop/ch3dM6_y2FSBVnSfwvA09nnVXIo jm no. nor ip itself, or ncp which preceded it, or tcp, or udp, or icmp, or smtp, ot http. it was insecure because it evolved in a safe, germ free academic bubble. absolutely none of it was designed with billions of people in mind, or the full cross section of humanity which would include criminals and national intelligence services. the world of the internet in 2019 would have been seen as a total freak show by the community who deployed dns in the 1980's. nothing that can be abused won't be. you may or may not believe this; it's considered controversial, and there are arguments being had about it today. but noone considered that now-controversial near-truism at all when the core internet protocols were first designed and implemented. the idea of abuse was considered novel in the 1990's when commercialization and privatization brought abuse into the internet world and burst the academic bubble. a lot of old timers blamed AOL and MSN and even Usenet for the problems, but in actuality, it's what humans _always_ do at scale. putting the full spectrum of human culture atop a technology platform designed for academic and professional culture should have been understood to be a recipe for disaster. ]]> ietf computers abuse internet security dns paul-vixie history scale culture https://pinboard.in/ https://pinboard.in/u:jm/b:1b1ad7b60bf8/ 2015-02-25T16:43:58+00:00 http://timkellogg.me/blog/2015/02/20/can-http2-replace-mqtt/ jmMQTT definitely has a smaller size on the wire. It’s also simpler to parse (let’s face it, Huffman isn’t that easy to implement) and provides guaranteed delivery to cater to shaky wireless networks. On the other hand, it’s also not terribly extensible. There aren’t a whole lot of headers and options available, and there’s no way to make custom ones without touching the payload of the message. It seems that HTTP/2 could definitely serve as a reasonable replacement for MQTT. It’s reasonably small, supports multiple paradigms (pub/sub & request/response) and is extensible. Its also supported by the IETF (whereas MQTT is hosted by OASIS). From conversations I’ve had with industry leaders in the embedded software and chip manufacturing, they only want to support standards from the IETF. Many of them are still planning to support MQTT, but they’re not happy about it. I think MQTT is better at many of the things it was designed for, but I’m interested to see over time if those advantages are enough to outweigh the benefits of HTTP. Regardless, MQTT has been gaining a lot of traction in the past year or two, so you may be forced into using it while HTTP/2 catches up. ]]> http2 mqtt iot pub-sub protocols ietf embedded push http https://pinboard.in/ https://pinboard.in/u:jm/b:1277082f29b4/ 2014-11-15T22:56:22+00:00 https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ jmNewly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation.  Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation.  There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation. We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected. Wow. so much for IPSec]]> ipsec iab ietf snowden surveillance crypto protocols internet https://pinboard.in/ https://pinboard.in/u:jm/b:cc8a7725bdf7/ 2011-11-17T13:21:08+00:00 http://www.virusbtn.com/news/2011/11_17.xml jm jd-falk death cancer rfcs ietf anti-spam people https://pinboard.in/ https://pinboard.in/u:jm/b:a7394e2b729c/