Last updated August 2004.
This is a fairly frequent question. Developers would like to download the protocol specifications for their phone so they can write code that talks to it. If you would actually just like the phone specifications then try phonescoop.com.
GSM phones mostly conform to ETSI TS 127 (download at www.etsi.org). The protocol is based on AT commands and is similar to reading and writing comma seperated values (CSV) files. Various phones have extensions that are sometimes documented by the manufacturer and other times figured out by various users often by brute force (send all possible command combinations and see which ones don't return an error).
For CDMA phones, there is no specification at all and no documentation anywhere. The most complete information is the BitPim source code. Feel free to use it, but ensure you respect the license.
If the information you want is not in the BitPim source code, get a phone into the hands of the developers and wait.
You can also try to derive the information yourself, but doing so involves reading the long answer.
The largest market for CDMA phones is the US, but the overall CDMA market is substantially smaller than GSM. CDMA is hard to do well, and consequently almost all CDMA phones are based on chipsets from Qualcomm. Please read this article by Stephen Den Beste to get a good understanding of the technical side of GSM/TDMA and CDMA as well as some background politics.
The carriers only stock a limited subset of phones available. For example I count 16 phones total at Verizon Wireless online (I don't include PDA phones in that count). Each manufacturer has one to three phones available at a carrier.
The way phones are brought to market is that the phone manufacturer picks target features they hope the carrier wants such as colour displays, cameras, multi-media, voice commands and get a chipset from Qualcomm. (Look here for a selection of CDMA 3G ones. They also have GSM/UMTS chipsets).
The chipsets also come with reference software modules for the various features available. The phone manufacturer then integrates some of their own customised modules (typically the phonebook) with the reference modules. (The LG VX4400 amusingly has a mostly complete MMS module that is present in various menus, but wasn't actually used over the air in the end).
The manufacturers usually have their own phonebook modules that they have been dragging from phone to phone. However it usually requires updating on each phone due to to new features such as allowing phonebook entries to bring up a camera image on incoming calls. Various files in the embedded filesystem (usually nothing more than an array of C structures) are referenced by the manufacturer modules as well as the reference software modules, and have various sized length fields which will be different than earlier chipsets.
They work out how to manufacture the whole lot including other parts such as batteries. The whole package goes through FCC certification. Work continues with the carriers as the firmware usually has to be customised per carrier because of features available on each carrier, as well as terminology differences. For example Verizon Wireless call their Brew implementation Get-It-Now whereas US Cellular call it EasyEdge which requires different server configuration information, menu entries and logos.
Six to nine months after certification by the FCC the phone becomes available on carriers. The manufacturers don't make much money on the phones, but do try to make up for it on volume and accessories.
This whole process gives little consideration to sync protocols, and there is certainly no intention of allowing random programs at the end of a data cable to have complete access to all internal features, as well as being robust against invalid data, overflows and other out of bounds behaviour.
The phonebook sync protocol is usually the same across the manufacturers phones. It pretty much consists of transferring memory (binary) images of the internal phonebook data structures, with some extra commands to move backwards and forwards. There may be other structures as well such as buffers to lookup callerid on an incoming call instead of scanning the whole phonebook. The internal phonebook data structures are different on every model, and even between firmware variations (for example Brew firmware is different than J2ME firmware).
Sometimes the commercial sync software companies manage to license the protocol/field description information from the manufacturer. But often they and the BitPim developers just work it out. That involves changing entries in the phone and seeing how the layout of the structures change, inputting maximum data lengths, guesswork and experiments.
For features other than the phonebook, there is rarely a protocol. Instead a different tack is used. The Qualcomm chipsets all have an embedded filesystem. There is a generic protocol to manipulate the contents of the filesystem, presumably originally intended for diagnostics, debugging and for developers of Brew applications so their code didn't have to be transferred over the air while under development.
The filesystem protocol can be used to modify files but it is inherently dangerous. The programs on the phone typically just read the binary files directly into memory and operate on them without checking. Invalid data, wrong lengths etc could easily crash the programs on the phone, and may make the phone unable to boot even.
But the only access to many features on the phone is to modify those files. They too are carefully examined and dissected and methods worked out for updating them. That is also why the phones have to rebooted after modifications as that is the only way to get the internal programs to reread the new content.
So in answer to your question, the manufacturers don't want everyone able to manipulate the phone contents over a cable, haven't even implemented a mechanism to do so for almost all features, and certainly haven't gone to the effort of making what is there very robust against bad data. The large amount of elapsed time between when they work on a phone and customers having it means that they are working on the next models by the time their previous models are selling well.
Additionally they expect the carriers to solve the problems over the air. Every carrier would love to nickel and dime you to update you phonebook over the air, send and receive photos and ringtones, update calendars etc. Many already do it to some extent.