HTTP1.0 is old. But we're nearing HTTP3.0 now. Not that HTTP1.0 has gone away, nor would it need to; but for the devices that need the features it offers, the newer versions are better.

I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP. Ideally there'd be a CAN2.0 for the cars that want it, that's backwards-compatible with CAN1.0 readers/etc.

> I think the author is pointing at that concept, with the idea that CAN hasn't evolved over time in the same way as HTTP.

If he works in this space, I would think he'd know that there are new things being worked on:

* https://en.wikipedia.org/wiki/CAN_FD

* https://en.wikipedia.org/wiki/FlexRay

Not that these seem to work differently at the OSI Layer 1/2 layer, so while older messages can be sent over the newer transport, it is not wire compatible.

Right, you'd likely have to connect your old CAN-bus reader to the new system through an active PHY-to-PHY adapter dongle, sort of like a VGA-to-HDMI adapter, or (presumably, once it happens) a MIDI1.0 to MIDI2.0 adapter.

As long as the new version of the protocol is still formatted on the higher OSI layers in terms of reusing the core messages from the old version, and then adding new messages that are optional to the understanding of what's going on from a CAN1.0 perspective, then a change in the PHY layer still isn't really throwing the baby out with the bath-water.