Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <1ED2B368DFDC024DA153CCA4511D66F7095048@DDTI050>
Date: Mon, 15 Nov 2010 09:45:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBA7B405-A71F-4EE7-A236-F9816C4CC855@brianrosen.net>
References: <2DBD8E0B-C68B-4E9D-9EB9-8E0EBEFC90A2@brianrosen.net>
 <1ED2B368DFDC024DA153CCA4511D66F7095048@DDTI050>
To: Marc Berryman <mberryman@ddti.net>
Cc: "geopriv@ietf.org" <geopriv@ietf.org>
Subject: Re: [Geopriv] Extending PIDF (-local-civic)
Precedence: list

Sure.

You could also parse 100% of the U.S. addresses by having "Address Line =
1" instead of all those pesky prefix/suffix/directional/... fields.  But =
when you parse "A Avenue" into two elements, and "Avenue A" into one, =
something is wrong.  Either the suffix is extraneous, or the prefix is =
needed.   Mostly, this is English bias.  If you looked at Spanish street =
names, you would have a bigger problem than with U.S. names.  I believe =
the same is true of French street naming and several other languages.

Brian

On Nov 15, 2010, at 9:19 AM, Marc Berryman wrote:

> Brian,
> Re: However, I am unhappy about promising that we will never update =
the schema for PIDF-LO or LoST.  We are not that good.  Mistakes have =
been made. =20
>=20
> I have tested RFC 5139 on millions of street names across the US. I =
challenge you or anyone to illustrate to me a single street name, or =
complete street name, that I cannot parse into the street name elements =
within RFC 5139.
>=20
> Your example of=20
> <newns:extCAtype name=3D"STP">Avenue</newns:extCAtype>=20
> seems to me a fix to something that is not a problem.=20
>=20
> Granted there is a very small fraction of a single percent of house =
numbers that I cannot parse into the namespace, but your example was =
implying a "fix" was needed due to the street name elements.
>=20
> Marc B.
>=20
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On =
Behalf Of Brian Rosen
> Sent: Thursday, November 11, 2010 7:47 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Extending PIDF (-local-civic)
>=20
> As I wait for the geopriv meeting to start, I wanted to summarize my =
thoughts on extending PIDF (-local-civic).
>=20
> First of all, I agree that we need to do something.  The current =
mechanisms we have for extending are not adequate.  The fundamental =
problem is that to add a CAtype (or anything else), one needs to create =
a new namespace, which effectively wipes out backwards compatibility. =20=

>=20
> -local civic correctly points out that one can add a new namespace, =
and define any new element in that namespace.  It proposes to do that =
without any constraint - anyone who wants to add an element would be =
free to define a new namespace and create a new element.  The issue =
several of us have with that is that it will be very difficult to =
maintain interoperability.  Since the threshold to add new namespaces =
with uncontrolled elements will be low, we would expect a great many =
such namespaces, with all kinds of elements that may have a local name =
which is very similar to another element in another namespace, but be =
different, or alternatively have two (local) names for the same thing.  =
While this is not strictly speaking a problem, because of the uniqueness =
of the namespace, it seems very hard to do something like create a =
parser which could parse "Address Line 1" into a PIDF that would be =
likely to be acceptable to a server.
>=20
> The basic idea that Martin and James want to push out is that 5139, =
which added CAtypes and fixed some problems with 4119 contains the LAST =
official IETF PIDF-LO namespace, and the schema is hereby considered =
inviolate.  Now, that's probably an overstatement, but they really do =
want to lock down any further changes, and confine them to some new =
namespace, and never change the schema in 5139.
>=20
> There is a compromise proposal on the table, which would work as =
follows:
> We would create a new namespace in a new RFC.  In that namespace, we =
would define two new CAtypes: extCAtype and localExtCAtype.  These =
CAtypes would have a parameter "name".  There would be two registries, =
the existing CAtype registry created by 5139 and a new one.  New entries =
in the existing registry would be used with extCAtype as:
>  <newns:extCAtype name=3D"STP">Avenue</newns:extCAtype>
> The intention is that address elements with general use (like a street =
type prefix) would be defined in the existing registry with the existing =
management policy.
>=20
> Entries in the new registry would be used with localExtCAtype.  The =
management for the policy with localExtCAtype would be expert review, =
with the instructions to seek to avoid clear duplication or spelling but =
otherwise to be liberal in allowing new definitions.  The registry ONLY =
intends to foster re-use, not become a barrier to actual new address =
elements.  The option to define a new namespace would remain as is.
>=20
> There is a problem with validation of location information using LoST. =
 The proposal on the table is to extend the definition of the items in =
the <valid>, <invalid> and <unchecked> lists to allow a name like =
newns:extCAtype+STP (ie behave as if newns defined an element =
extCAtype+STP.
>=20
> I am not thrilled with the LoST hack.  I would prefer to actually fix =
the problem, but I recognize that means updating the schema, and thus =
the namespace for LoST, and we're back to the same issue.  I can live =
with it if that is the consensus of the work group.
>=20
> However, I am unhappy about promising that we will never update the =
schema for PIDF-LO or LoST.  We are not that good.  Mistakes have been =
made.  New features will arise that won't be able to be done with new =
namespaces.  For example, I would like to change the part of the schema =
that contains the CAtype elements from what is now SEQUENCE, because =
SEQUENCE implies a fixed order, and there have been suggestions for =
things where SEQUENCE is problematic (INT).  Now, actually, if INT was =
done with extCAtype, SEQUENCE would work, because there is only repeated =
instances of extCAtype (and localExtCAtype), and they are in a different =
namespace from the 5139 namespace, so just consider this an example.  I =
don't know what problems we will find, only that history suggests that =
will happen.
>=20
> We should not make such promises.  We may be able to avoid updating =
the schema this time, we might not the next time.
>=20
> Brian
>=20
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv