Updating documentation for Eddystone launch

README.md

@@ -24,29 +24,14 @@ The number of smart objects is going to explode, both in our homes and in public
 The Physical Web must be an open standard that everyone can use. This can’t be a product that is locked down by a single company. Like many web specifications, this is an open source design that is being released early so everyone can experiment and comment on it. There is much to discuss and add to this specification.
 
 ##Contents
-* [Introduction/FAQ](http://github.com/google/physical-web/blob/master/documentation/introduction.md) Most common questions
-* [Getting started guide](http://github.com/google/physical-web/blob/master/documentation/getting_started.md) How you can try it out
-* [Technical Overview](https://github.com/google/physical-web/blob/master/documentation/technical_overview.md)
-* [URI Beacon Spec](https://github.com/google/uribeacon) Partner repo with code/examples for the beacons themselves
-* [mDNS support](https://github.com/google/physical-web/blob/master/documentation/mDNS_Support.md) How to use mDNS instead of Bluetooth to broadcast URLs
-* [Branding Guildelines](documentation/branding_guidelines.md)
-* [SSDP support](documentation/ssdp_support.md) How to use SSDP instead of Bluetooth to broadcast URLs
+* [Introduction/FAQ](http://github.com/google/physical-web/blob/master/documentation/introduction.md) - Most common questions
+* [Getting started guide](http://github.com/google/physical-web/blob/master/documentation/getting_started.md) - How you can try it out
+* [Technical overview](https://github.com/google/physical-web/blob/master/documentation/technical_overview.md)
+* [Eddystone](https://github.com/google/eddystone) - Repo with the specification for the beacons themselves
+* [mDNS support](https://github.com/google/physical-web/blob/master/documentation/mDNS_Support.md) - How to use mDNS instead of Bluetooth to broadcast URLs
+* [Branding guildelines](documentation/branding_guidelines.md)
+* [SSDP support](documentation/ssdp_support.md) - How to use SSDP instead of Bluetooth to broadcast URLs
 * Different Physical Web clients
     * [Android](android)  
     * [IOS](ios)  
     * [Node](nodejs)  This is a minimal client meant for building utilities
-
-##Beacons
-Our most common request is how to get [UriBeacons](http://uribeacon.org). 
-There are a number of firmware examples for Arduino, Raspberry Pi, node and many more on the [Uri Beacon repo](https://github.com/google/uribeacon).
-
-The following companies now sell premade URIbeacons:
-* [Blesh](https://www.blesh.com/physical-web/)
-* [KST](https://kstechnologies.com/particle/)
-* [Accent Systems](http://ibeacon.accent-systems.com/)
-* [iBlio](https://sites.google.com/site/iblionet/beacons)
-* [BKON](http://www.bkon.com/uribeacon)
-* [LilyPad-nano51822](http://www.embeda.com.tw/ucxpresso/?article=2-3-google-uribeacon-project)
-* [GoPlus](http://iffu.co.kr/eng/product/go-plus_uri.html)
-* [BlueUp](http://www.blueupbeacons.com/index.php?page=products)
-* [TwoCanoes](http://twocanoes.com/products/hardware/physical-web-beacon)

documentation/branding_guidelines.md

@@ -11,18 +11,18 @@ The following guidelines provide you with guidance for using the Physical Web na
 * **Do** use the trademark symbol in the first or most prominent instance of Physical Web™ in your creative
 * **Do** modify the logo’s foreground color, background color, and size
 * **Do** use the logo in conjunction with the Physical Web name, or as a standalone logo
-* **Do** use the Physical Web name and/or logo to indicate that a nearby device is broadcasting UriBeacon advertisement packets, e.g. on your visual advertisements or in your coffee shop
+* **Do** use the Physical Web name and/or logo to indicate that a nearby device is broadcasting [Eddystone-URL](https://github.com/google/eddystone/tree/master/eddystone-url) advertisement packets, e.g. on your visual advertisements or in your coffee shop
 * **Don’t** modify the dimensions of the logo or distort it
 * **Don’t** combine the Physical Web logo with other logos, including your own
 * **Don’t** put “Google” before or after the Physical Web name or associate “Google” directly with the Physical Web logo
     * Incorrect: "Google’s Physical Web”
     * Incorrect: "Physical Web from Google”
     * Correct: Just use the Physical Web logo with TM only (nothing else required)
-    * Correct: "Physical Web, an open web discovery layer built on top of UriBeacon”
+    * Correct: "Physical Web, an open web discovery layer built on top of Eddystone-URL”
 
 * **Don’t** use Google or Android logos on product pages where the Physical Web name or logo appear
 
-You may display, modify according to the above rules, or use the Physical Web name and logo only in connection with compliant implementations of UriBeacon and compliant implementations of the Physical Web. A compliant implementation of UriBeacon is a Bluetooth Low Energy device that broadcasts advertisement packets according to the unmodified UriBeacon specification found in the corresponding GitHub repository. A compliant implementation of the Physical Web is software that scans for UriBeacon advertisement packets and presents results to the user that directly correspond to these scanned packets.
+You may display, modify according to the above rules, or use the Physical Web name and logo only in connection with compliant implementations of Eddystone-URL and compliant implementations of the Physical Web. A compliant implementation of Eddystone-URL is a Bluetooth Low Energy device that broadcasts advertisement packets according to the unmodified Eddystone-URL specification found in the corresponding GitHub repository. A compliant implementation of the Physical Web is software that scans for Eddystone-URL advertisement packets and presents results to the user that directly correspond to these scanned packets.
 
 Use of the Physical Web name or logo in ways not expressly covered by this document is not allowed without written permission. For questions, please file an issue in the public Physical Web GitHub repository: <https://github.com/google/physical-web>.
 

documentation/getting_started.md

@@ -2,13 +2,9 @@
 
 In order to get up and running you need two things:
 
-1. A hardware beacon (or two)
-2. Software on your phone/tablet to see that beacon.
+1. A hardware beacon (or two) that supports [Eddystone-URL](https://github.com/google/eddystone/tree/master/eddystone-url) advertisement packets.
+2. Software on your phone/tablet to scan for Eddystone-URL advertisement packets.
 
-To get a hardware beacon you have two choices. By far the easiest is to just buy a beacon that is ready made. [Blesh](https://www.blesh.com/physical-web/) sells packs of three that are easy to setup and use.
+The software is easy thing to take care of once you have beacons. There is a Physical Web demo app on the [Google Play store](https://play.google.com/store/apps/details?id=physical_web.org.physicalweb) as well as the [Apple App Store](https://itunes.apple.com/us/app/physical-web/id927653608?mt=8).  A walkthrough of the app [is here](http://github.com/google/physical-web/blob/master/documentation/android_client_walkthrough.md).
 
-If you want to hack a bit, there is also a growing list of maker devices that support the broadcasting of URLs in [this directory](https://github.com/google/uribeacon/tree/master/beacons)
-
-The software is the easiest thing to take care of. The app is on the [Google Play store](https://play.google.com/store/apps/details?id=physical_web.org.physicalweb) as well as the [Apple App Store](https://itunes.apple.com/us/app/physical-web/id927653608?mt=8).  A walkthrough of the app [is here](http://github.com/google/physical-web/blob/master/documentation/android_client_walkthrough.md) and will show you how to put your URL into a beacon.
-
-Keep in mind that this software is just a prototype. We are doing it this way to easily and quickly test the concept. Eventually, the goal is to have this Physical Web code rolled into each browser.
+Keep in mind that this software is just a prototype. We are doing it this way to easily and quickly test the concept.

documentation/technical_overview.md

@@ -9,7 +9,7 @@ This has another advantage in that it means that a user can walk through a space
 The current prototype broadcasts once every second, striking a balance between user response time and battery life. There is nothing stopping a device from broadcasting faster if it wishes.
 
 ###BLE Format
-The URL is stored in the advertising packet of a BLE device. The packet identifies itself with a 16-bit Service UUID of 0xFED8 which indicates the beacon is a `URIBeacon`. The exact format of the packet is described in detail at our sister GitHub repo, [URIBeacon](https://github.com/google/uribeacon).
+The URL is stored in the advertising packet of a BLE device. The packet identifies itself with a 16-bit Service UUID of 0xFEAA which indicates the beacon is an [Eddystone beacon](https://github.com/google/eddystone). Additionally, the packet sets the frame type field to 0x10 to specify that it is of the [Eddystone-URL](https://github.com/google/eddystone/tree/master/eddystone-url) format, which is designed to carry URLs.
 
 This small size of the advertising packet does not leave a lot of room for the text of the URL. This is one of tradeoffs that comes from avoiding any connections to the beacon (to reduce tracking and avoid congestion). URLs are encoded so common patterns like 'http://www.' and '.com' can be compressed into a single character. This is very similar to NDEF compression in NFC. In addition, we expect initial testers will use either short domains or a URL shortener. Both the Android and iOS apps do this automatically when a URL is typed in that is too long to fit.
 

web-service/README.md

@@ -11,11 +11,11 @@ applications in this repo.
 
 ## Why do we use a Physical Web Service?
 
-UriBeacon devices have an open but very specific protocol which must be
+[Eddystone-URL](https://github.com/google/eddystone/tree/master/eddystone-url) beacons have an open but very specific protocol which must be
 followed.  Anyone is free to do so.  This is the only requirement for
 participation and interaction with the Physical Web.
 
-Any app/device can read these UriBeacon packets and do with them whatever they
+Any app/device can read these Eddystone-URL packets and do with them whatever they
 wish.  We have provided some example apps (and published them to app stores) to
 make it easier for you to try out the Physical Web.
 
@@ -24,8 +24,8 @@ information about the URLs it finds. Even more so, it wants to protect the
 user and his/her privacy from the many potential misuses of the physical web.  
 We hope every other app will do so, also.
 
-One really nice property of the Physical Web is that UriBeacons cannot
-physically detect when clients scan it and so cannot track passers-by.
+One really nice property of the Physical Web is that Eddystone-URL beacons cannot
+physically detect when clients scan them and so cannot track passers-by.
 However, the web servers backing these URLs can track all requests to them 
 (as is usual on the web).  So our app must be extremely careful with how it 
 uses the URLs it finds.
@@ -43,12 +43,10 @@ Service.
 
 ## What does a Physical Web Service do?
 
-At the very simplest, it fetches, parses, and presents the content of UriBeacon
-URLs on behalf of a client, but without using the client's identity in any way.
+At the very simplest, it fetches, parses, and presents the content of Eddystone-URL packets on behalf of a client, but without using the client's identity in any way.
 It's a middleman added for safety and efficiency.
 
-Unlike a UriBeacon, a Physical Web Service is not a core part of the Physical
-Web, is not mandatory, and does not have a specific protocol that must be
+Unlike an Eddystone-URL beacon, a Physical Web Service is not a core part of the Physical Web, is not mandatory, and does not have a specific protocol that must be
 followed (though perhaps an ad-hoc format will arise one day).  It is an
 auxiliary solution to solve a fundamental problem for Physical Web client
 software (see above).