[alexeckermann]

Simple answer: Available advertising space.

The identifier field in the iBeacon spec is a 16-byte UUID and no longer than that, AltBeacon has a 20-byte space but its because it includes an unstructured major, minor (compared to iBeacon). If your example was to be represented it would be 22-byte in length which is outside the bounds available — granted that I took the number of X literally and could be shortened multiple ways.

Moreover, the UUID is described as a region identifier where, in your scenario, all the beacons for the bus company would have the same region identifier but each individual beacon representing a stop would have an individual major and minor identifier (2-byte each) to uniquely identify that particular stop. So the way in which the iBeacon spec and somewhat AltBeacon are authored don't really allow for that kind of implementation because of the limitations imposed by the small advertising packet space. Its intended that the identifier space be used for something like a UUID with a set of supporting identifiers (major, minor).

As you can see from the AltBeacon spec diagram; there is only 28-bytes available for advertisable data on a Bluetooth Smart peripheral. So there is not a lot of room to play with.

[azdle]

Yep, I over counted the bytes in the AltBeacon spec, but I still think that a URI-based beacon would be very beneficial. I'm not saying that it needs to fit into the iBeacon or AltBeacon specs, I'm just commenting that I think we'd be much better off with a beaconing protocol that doesn't require some central database controlled by one company.

I don't know that much about iBeacon and how the major and minor work, but something similar could work by using a aa.bbb.cc/xxx/yyy type of URL. Sure you're wasting 2-4 bytes on the slashes and dots, but I think that would be worth it to have it be a completely open protocol.

Something you should know about me, I'm overly excitable. I've decided that we need to develop one universal standard that covers everyone's use cases. I'm going to create OpenBeacon! http://obcn.io

[matt_kantor]

Nice job taking initiative!

Do you know if there's a technical reason for ad packets to be so small?

I like the idea of using URIs, but if beacons automatically caused my device send arbitrary network requests along with any kind of identifying information it could be quite scary (someone could track my location in real time by tossing a bunch of cheap beacons around).

Also, you'll probably want to cram a URI scheme in there.

[azdle]

I know what you mean about the tracking and that's actually part of the reason I think this method makes more sense. Something that's been in my head, but not put down anywhere is the idea of applications registering domains. Which to my understanding is similar to how other beaconing works, where UUIDs are registered.

Although there is only so much that you can do to prevent it. I'm kinda mulling around the thought of one basic (anonymous, except IP) request to the base domain for general information about the endpoint and if these implement some sort if well-known action types (transit-stop, point-of-interest, ???) then you'd be able to allow requests to always be made on a domain-by-domain basis or maybe some sort of "tap-for-info" button when you're near something interesting. Not sure yet, but I am generally trying to keep privacy in mind.

EDIT: Missed the part about the advertising packets. I don't really know, I've only read through the BT4 spec really quickly, but I have to imagine it has to do with both not congesting the spectrum with overly verbose broadcast messages and limiting power usage.

[sirvon]

most mobile apps already do that....that being, automatically HTTP POST information about you from your device to various datastores and data crunchers globally. some of our privacy automatically will be made public.