You worked on BT specs ? BT seems an acute case of design by comittee. It's huge, full of profiles and corners. Nobody implements it really well, everything moves before it's finished. Makes you dream of wires some times.
I was involved in the 1.0 Bluetooth specifications and can confirm it was "designed by committee". IIRC the original wireless specification came from either Nokia or Ericsson and they drove a lot of the initial development. They had already developed the RF technology before the Bluetooth SIG was even formed. The original stated goal for Bluetooth was "cable replacement". Features such as pairing a headset to a phone, or a phone to a laptop were an essential part of the original profiles.
A reason for the complexity was that the BT 1.0 profiles often leveraged existing technology, for example:
- RFCOMM was a way of sending arbitrary serial data, reusing RS232 comms which were very common.
- OBEX was a way of sending data which was previously sent over IrDA
- The "LAN access profile" basically said "use RFCOMM to do PPP over a serial link like you do with a modem"
If you tried to implement any of these from scratch then not only do you have to implement the BT part, you also have to implement the technologies that BT reused.
If you look at the initial SIG members, Nokia and Ericsson took care of the initial phone developments. Intel, IBM, Microsoft and Toshiba represented the PC side of things. I was working for 3Com at the time and we were interested in it as a short range network technology. 3Com developed a network device conforming to the "LAN access profile" but it was never released. 3Com also owned Palm and they were interested in incorporating BT with the hand held devices.
It is interesting to compare BT to Wireless Ethernet (IEEE 802.11) world. The IEEE Ethernet (802.3) specifications are pretty much only concerned with getting data packets from A to B at layers 0 through 2. At layer 3 and above they don't care if those packets are IPv4, IPv6 or some other protocol like IPX.
Bluetooth tried to define everything from the the RF communications all the way up to the application layer. The specification mentions how to the PIN code request should be presented to the user when authorizing a new connection. It also mentions which audio codecs should be supported for streaming audio. The BT profiles also tried to define how to transfer files, business cards or print documents.
These detailed application layer specifications simply don't exist in something like Ethernet. There might be an argument that BT tried to over specify things but it was attempting to give a level of interoperability which we still struggle to achieve over other networks.
Yeah, that's how it felt, they provided an out of the box full stack. Maybe this AND the field it lived in, cellphones as opposed to computers, made it too hard to do right. Cellphones changed a lot since the BT 1.0 days, instead of implementing gradual layers, you have to deliver a monolith..
As a user i kinda like the profiles, in particular the OBEX based ones. This because it means i can expect two devices to be able to share files out of the box if both of them have a bluetooth radio. Nothing like that exist for wifi, and i have to set up some client-server scheme to make anything happen.
The OBEX profiles predate even BT, they were inherited from IrDA. IrDA was an earlier method for transferring business cards or similar small files between hand held devices over an infra-red link link.
Not that I disagree with you, but I would love to see examples where it would be the opposite and you would say it was a beautiful and well implemented.
Tends to be hard to implement a specification without any implementation to test it out together with it, but those who do work out, should be looked into why so we all can learn from it.
A reason for the complexity was that the BT 1.0 profiles often leveraged existing technology, for example:
- RFCOMM was a way of sending arbitrary serial data, reusing RS232 comms which were very common.
- OBEX was a way of sending data which was previously sent over IrDA
- The "LAN access profile" basically said "use RFCOMM to do PPP over a serial link like you do with a modem"
If you tried to implement any of these from scratch then not only do you have to implement the BT part, you also have to implement the technologies that BT reused.
If you look at the initial SIG members, Nokia and Ericsson took care of the initial phone developments. Intel, IBM, Microsoft and Toshiba represented the PC side of things. I was working for 3Com at the time and we were interested in it as a short range network technology. 3Com developed a network device conforming to the "LAN access profile" but it was never released. 3Com also owned Palm and they were interested in incorporating BT with the hand held devices.
It is interesting to compare BT to Wireless Ethernet (IEEE 802.11) world. The IEEE Ethernet (802.3) specifications are pretty much only concerned with getting data packets from A to B at layers 0 through 2. At layer 3 and above they don't care if those packets are IPv4, IPv6 or some other protocol like IPX.
Bluetooth tried to define everything from the the RF communications all the way up to the application layer. The specification mentions how to the PIN code request should be presented to the user when authorizing a new connection. It also mentions which audio codecs should be supported for streaming audio. The BT profiles also tried to define how to transfer files, business cards or print documents.
These detailed application layer specifications simply don't exist in something like Ethernet. There might be an argument that BT tried to over specify things but it was attempting to give a level of interoperability which we still struggle to achieve over other networks.