The authors have written several decoders and codecs for the rather complex AIS protocol used by marine safety and navigation systems. Based on this experience, we put forward some lessons learned and design principles that we think should be heeded in the extension of AIS and the design of future application protocols. We also offer pragmatic advice to those implementing decoders for AIS and similar application protocols. The Marine Automatic Identification System (AIS) is a software, hardware, and radio coding protocol that allows ships to broadcast navigational and other status information for use in collision avoidance, navigation, and traffic management. Early design work on AIS was done primarily by Sweden; the International Association of Lighthouse Authorities (IALA) proposed the concept to the International Maritime Organization (IMO) in 1995 [IALA2004]. The core AIS standard is now maintained by the International Telecommunications Union (ITU) in association with IMO [ITU1374]. Both the design of AIS and the process by which it evolved are representative of a large class of application protocols in the real world, especially those concerned with geolocation and geographic information systems. A marked feature of AIS, however, is that due to the hazards of operation at sea, the information it handles can be immediately life-critical. This gives software defects in decoders a special significance and raises the stakes in our design analysis. The physical layer of AIS uses a self organizing (SO) variant of Time Division Multiple Access (TDMA) packet radio scheme to avoid collisions among AIS transmitters serving either of two operating frequencies [LANS1996]. For the analysis in this paper, the physical layer can be largely ignored and AIS viewed as a mechanism for passing binary datagrams in either an addressed or broadcast mode. For AIS purposes an "address" is a Maritime Mobile Service Identity (MMSI), a 9-digit numeric tag associated with a ship or shore station. The binary datagrams have a fixed header containing a dispatch field (the type) followed by information whose formatting varies by type in complex ways. Payload information is encoded mainly as packed numeric bit fields of lengths varying from 1 to 30 bits; these may be interpreted as boolean flags, unsigned or signed two’s-complement big-endian integers, indices into controlled vocabularies, or (implicitly, via scaling formulas) as fixed-point real numbers. Some messages have longer regions that are interpreted as character strings or treated as opaque binary blobs to be passed to from or to helper applications. Typical data items to be extracted from AIS bit fields include latitudes, longitudes, vessel course and speed, capabilities of the transmitting vessel or station, and weather or safety conditions. Some message fields are passed solely for the AIS system’s own housekeeping functions.In practice, software engineers are unlikely to encounter AIS datagrams in raw binary form. AIS receivers commonly make them available over RS422, RS232 and USB ports in an ASCII-armored byte-stream form called AIVDM/AIVDO, a profile or variant of the NMEA format commonly used in shipboard navigation and control systems. The design of AIS is optimized to make efficient use of scarce radio bandwidth. In this it resembles a great many application protocols which tight-pack every bit - either out of rational economy or (more commonly) because the designer’s mental habits were formed in a time when bandwidth was far more expensive than it is today. Raymond maintains a programmer’s-eye view of the details of AIS/AIVDM/AIVDO in [RAYMOND1]. Since that document is available from any browser, we choose not to burden this paper with duplicative details about datagram formats (but see the layout of the Common Navigation Block in the next section for a representative example, the payload of the three most common message types). We will refer to [RAYMOND1] frequently, and readers are assumed to be familiar with it before proceeding.