How should we handle person addresses?

From IRC yesterday:

14:39 < wking> hmm, we're keeping the (person|drop)<->(address)
  association outside of the data structures I'm defining in the spec.
  That means creating a new person address is going to look like:
  'POST /address?person=123'.  Or maybe 'POST /address' (returns ID),
  'POST /person/{id}/address' (with an ID payload).  Thoughts?
14:40 < wking> actually, drop.address is in the spec.  Maybe I want to
  put person.addresses in the spec?
14:41 < wking> That means you'd need 'PUT /person/{id}' to update
  addresses, but that's probably fine
14:41 < shofetim> person.address != drop.address
14:42 < wking> How are the data structures different?  It's just an
  address, right?
14:54 < shofetim> ah yes, just that person needs one too. For billing,
  mail, etc.
15:16 < wking> yeah, I think people can have an array of addresses
  (e.g. previous UPS addresses) as well
15:36 < wking> hmm, maybe we need a tag for each person address type
  then?  person.address.billing, person.address.mail,
  person.address.ups-1 ?
15:38 < wking> how do we want to keep that straight?  In Beehive we
  have primary_address, addresses, and sold_to_address ( which is
  primary_address, but falls back to vendor.primary_contact, and falls
  back again to the latest address with a 'billing address' note)
15:38 < wking> do we need an address.type field?
15:55 < shofetim> I think we can avoid an address.type field, but I
  don't really know. Nice not to type things ahead of time unless they
  need it (ie the mailing, billing, and drop address could be the same
  for a drop co-ordinator that has the drop at their house, no need to
  have them enter or save it three times)
15:58 < wking> they probably won't be writing out their API POST body
  by hand ;).  So API-level duplication could be handled by the UI.
15:58 < wking> maybe an optional address.type which would be a list of
  uses
15:58 < wking> and person.get_address(type=mail) would iterate over
  person.addresses until it hit one with 'mail' in the type array?

I'm currently leaning toward an optional person.addresses array and
adding a 'types' array to the address model, because handling
ownership of addresses that are tracked as a separate model would be
too complicated.