That's a simplification, not a complication.
I am trying to achieve a couple of reasonable goals:
a) Given a PIDF, pretty print the location matching the local signage and plans
b) Given a pretty printed location, create a valid PIDF
The address considerations document only works where there is an established pattern, and a document that describes how to encode a location using the pattern. The example of Austrian addresses is certainly a good example.
Interior location doesn't have a pattern (it has many, many patterns), and there isn't, and couldn't reasonably be, a document for each pattern. Address considerations also relies on the fact that the value of the country code element tells you which pattern (and document), and there is no corresponding way to know which pattern goes with which address.
The DHCP encoding comment is apt, and I'll cover it in the next version.
Brian
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Tuesday, July 14, 2009 7:51 PM
> To: Rosen, Brian; geopriv@ietf.org
> Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> a) no
> b) mu, but mostly no
> c) no
>
> This document is symptomatic of an inclination to solve any addressing
> problem by adding elements, without regard to cost and complexity.
>
> There are already 30+ elements; and we're experiencing difficulty
> selling folks on the need for numbers larger than 5. By adding
> complexity, we only continue to alienate those people and decrease the
> relevance of the existing product.
>
> The civic address considerations document describes a number of
> techniques that can be used to deal with each of the specific problems
> that you've raised. The semantics of the existing types are flexible
> enough to accommodate most, if not all of your use cases.
>
> The document does not adequately describe how this might be conveyed in
> DHCP.
>
> --Martin
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of Rosen, Brian
> > Sent: Wednesday, 15 July 2009 7:07 AM
> > To: geopriv@ietf.org
> > Subject: [Geopriv] draft-rosen-geopriv-pidf-interior
> >
> > I would appreciate some comments on this draft:
> > a) Does it makes sense to you to do it this way instead of how we
> > currently support "interior" location?
> > b) Do the specifics look right (basically, it's an ordered list of
> > name/value pairs with no registry and a flag that suggests how to
> > pretty
> > print the result)
> > c) Should we deprecate the existing mechanism in favor of this, or
> just
> > let the old one lie there?
> >
> > Several groups that tried to do interior addressing ran into the kind
> > of
> > problems the existing mechanism couldn't handle and went for the open
> > ended name/value pair idea.
> >
> > Brian
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
> -----------------------------------------------------------------------
> -------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> -----------------------------------------------------------------------
> -------------------------
> [mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
