anchor.diff:  <tr>
     <td>service_id*</td>
     <td>string</td>
  -  <td>An identifier that’s generated by the broker and will be passed to the broker for future unbind requests, it’s really a “handle_id” not a service_id.</td>
  +  <td>An identifier that’s generated by the broker and will be passed to the
  +	broker for future unbind requests, it’s really a "handle_id" not a
  +	service_id.</td>
   </tr>
   <tr>
     <td>configuration*</td>
     <td>object</td>
  -  <td>The configuration used to provision this service, usually a copy of the request attributes</td>
  +  <td>The configuration used to provision this service, usually a copy of the
  +	request attributes</td>
   </tr>
   <tr>
     <td>credentials*</td>
     <td>object</td>
  -  <td>The credentials that were generated as part of this binding. These credentials will be passed to the bound application as part of the VCAP_SERVICES environment variable.</td>
  +  <td>The credentials that were generated as part of this binding.
  +	These credentials will be passed to the bound application as part of the
  +	VCAP_SERVICES environment variable.</td>
   </tr>
   </tbody>
   </table>
   
   ## <a id="unbind"></a>Unbinding ##
   
  -Simply the opposite of bind, unbind is the developer-initiated intention to revoke a specific application’s access to a service instance.
  -The developer makes an API call to the Cloud Controller, which makes an API call to the broker including the GWID of the binding that should be destroyed.
  -If possible, the bound credentials should be destroyed so that application can no longer access the resource.
  +Simply the opposite of bind, unbind is the developer-initiated intention to
  +revoke a specific application’s access to a service instance.
  +The developer makes an API call to the Cloud Controller, which makes an API call
  +to the broker including the GWID of the binding that should be destroyed.
  +If possible, the bound credentials should be destroyed so that application can
  +no longer access the resource.
   
   To delete a binding, the Cloud Controller sends an unbind request to the broker.
  -The full request URL is determined by concatenating the URL in the catalog + the path below.
  +The full request URL is determined by concatenating the URL in the catalog + the
  +path below.
   
   `DELETE /gateway/v1/configurations/:service_id/handles/:handle_id`
   
  -* Note: the `service_id` and `handle_id` exist in both the URL and BODY, see table:
  +* Note: the `service_id` and `handle_id` exist in both the URL and BODY, see
  +table:
   
   <table>
   <thead>
  
positive.code: <tr>
    <td>free*</td>
    <td>bool</td>
    <td>Displayed by frontends, used by quota_definitions to determine whether an org can provision a service</td>
  </tr>
  <tr>
    <td>description*</td>
  
negative.code: title: Writing a v1 Cloud Foundry Service
  ---
  
  There are two versions of the Cloud Foundry Services API. This page documents
  v1.
  
  <strong>DEPRECATED:</strong> We recommend that all new service brokers be
  written against the <a href="writing-service.html">version 2 API</a>.
  
  Writing a service involves writing a service broker that obeys the API contract
  between the Cloud Controller v2 (CC) and a v1 service broker.
  Service brokers were previously called Service Gateways (GW).
  The protocol is entirely RESTful HTTP, with _bidirectional communication_.
  In addition to authentication there are six basic operations that take place,
  described in this document.
  An oversimplified example of making a broker that supports the 3 most basic
  operations can be found here: https://github.com/geapi/cf-service-example.
  
  <%= image_tag("../images/v1services.png", :width =>"960", :height =>"720",
  :style => 'background-color:#fff') %>
  
  ## <a id='authentication'></a>Authentication ##
  
  _The Cloud Controller authenticates to a broker using a shared secret_
  
  The broker must reject all requests not including the shared secret with a 401
  unauthorized response.
  The token is registered into the Cloud Controller by an admin user, usually
  using the cf CLI gem which adds commands like `cf create-service-auth-token`.
  Or one can directly make calls to the Cloud Controller v2 RESTful API to
  register a new shared secret (called auth token).
  
  _A broker authenticates to the Cloud Controller using a UAA token_
  
  Like all API endpoints in the Cloud Controller, the broker must first obtain and
  then include a valid Oauth2 token from UAA.
  This token must include the scope `cloud_controller.admin`, because only this
  scope has permission to modify the services catalog.
  
  ## <a id="catalog"></a>Catalog Management</a> ##
  
  With v2 of the Cloud Controller, a broker is responsible for maintaining its
  catalog of offerings and plans by issuing various RESTful API calls to the Cloud
  Controller.
  Normally the lifecycle is as follows:
  
  1. On startup, the broker communicates with UAA to get an access token with
  sufficient permissions to access the Cloud Controller (currently admin access).
  1. It then downloads the catalog of all available service offerings and plans
  from the Cloud Controller.
  1. It issues POST requests to create missing offerings and plans. Offerings
  include a URL to access the broker responsible for future provision/bind
  requests.
  1. It issues PUT requests to update existing offerings and plans that are not in
  sync.
  1. It issues DELETE requests to remove offerings and plans it no longer wants to
  advertise.
  
  All catalog management APIs are in the CloudController.
  A service is identified by the combination of `[label, provider, version]`,
  which must be unique.
  A plan is identified by `[service_guid, name]`, which must also be unique.
  
  We introduced the `unique_id` field in order to enable service brokers to change
  service labels, providers, and versions, and to change plan names. If a service
  broker sets a `unique_id` for its service in Cloud Controller, then the broker
  can use the `unique_id` to identify the service, even after it has changed the
  service name, etc. The same is true for plans.
  
  To generate a `unique_id`, try this [Online GUID
  Generator](http://www.guidgenerator.com/ "Online GUID Generator").
  
  ### <a id='catalog-create-new'></a>Creating a new service in the catalog ###
  
  