Subject: RE: [Ecrit] Issue 35: Location Validation

From: "Roger Marshall" <[email-masked]>
Date: Wed, 19 Apr 2006 16:33:40 -0700

I think Brian answered most of these, but since I didn't see them
captured individually, here's my take:

[from Hannes, (ref. re-pasted from summary at end)]

What we can do is to be more specific about the type of behavior we want
from the mapping protocol.

Do we want the client to be able to express that the mapping server
should check the civic address for existence?

[RM] - Yes, I think so.  I propose the following new requirements:

LoX'.  The mapping protocol MUST support a mechanism which provides an
indication as to whether a specific civic location exists.

LoX''.  The mapping protocol MUST support a mechanism which provides an
indication that specific civic location does not exist exactly, but does
fall within a acceptable range of (address) values.

LoX'''.  The mapping protocol MUST support a mechanism which provides
alternate location choices, based on matching criteria (e.g., if 123
Main St. DNE, might return "'123 S. Main St.' or '123 N. Main St.'
alternates exist").

LoX''''.  The mapping protocol MUST support a mechanism which provides
an indication of which data elements of a civic location were, and were
not found in the database (e.g., "'123 Main St. Mytown' not found, but
'Main St. Mytown' was found".

Do we want the mapping server to be able to indicate that the civic
address was checked against the database?

[RM] - Yes, and precisely which database.  Here's my suggested
requirement:

LoY.  The mapping protocol MUST support a mechanism which provides an
indication as to a specific "type" of location database used for either
civic or geographic location matching (e.g., USPS, MSAG, GDT, etc.).

I don't think anything needs to be done with regard to geospatial
location info. 

[RM] - I agree that for the requirements draft, geo is probably covered
well enough, but as James pointed out, a subsequent geo-specific draft
would be useful.

Roger Marshall.

>-----Original Message-----
>From: James M. Polk [mailto:[email-masked]] 
>Sent: Wednesday, April 19, 2006 3:23 PM
>To: [email-masked]; Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [Ecrit] Issue 35: Location Validation
>
>I agree with almost everything Brian says (surprise!), 
>especially about how to work out additional info if a match isn't made.
>
>I'm weary about how to pull this off for geo though, due to 
>the rigidity of what doesn't constitute a match.  Given that 
>GPS accuracy is roughly within
>15 ft after a few minutes and within a few feet after a bit 
>longer (you get the idea of increasing accuracry with time), 
>with some reports where they are might fall *just* outside of 
>a valid location match, and return an error.  This might just 
>occur for someone in the middle of the street, say at a car 
>accident or a hurt child next to their bike, and no one wants 
>this not getting through to a PSAP.
>
>Geo almost should have a match to some PSAP if the caller is 
>within a jurisdiction (say a country or state or province or 
>county), and not only when they are at a street address that's 
>nice and neat like civic addresses, but this is an interesting 
>problem we haven't really gotten into to solve for yet, have we.
>
>How does the Phase-II cellular world solve this validation 
>question when presented with GPS coordinates to a wreck down a 
>canyon road that has no
>(housing) lot addresses?
>
>If this isn't solved for in an agreed upon way, this almost 
>begs for a "Geo Considerations" ID to have a specific discussion about.
>
>At 05:02 PM 4/19/2006 -0500, [email-masked] wrote:
>>In North America, validation is a well known, and required step in 
>>processing a civic location.  In the current system, there is no 
>>validation of geo.
>>
>>In the end, validation in the current system means:
>>    Do we know where this location is; can we send someone to help
>>    by giving him this location?
>>
>>To do that, there is presently a database, called the Master Street 
>>Address Guide, which contains a list of all the "known" 
>street addresses.
>>Validation, today, means that before a location is put into the 
>>database that is actually used to determine address when an emergency 
>>call is made (the "ALI" database), the location is looked up in the 
>>MSAG.  If there is a match, the update to the ALI is permitted.  If 
>>there is no match, the update is not allowed and the carrier 
>attempting 
>>to update the ALI has to go figure out what happened.
>>
>>The MSAG database sometimes also is aligned with the database used to 
>>dispatch responders.  A location submitted to the responder Computer 
>>Aided Dispatch system must be "MSAG Valid".
>>
>>The emergency call system in North America is heavily dependent on 
>>validation; many attempts at coming up with a location don't yield 
>>something unique enough to use for locating where someone is 
>>unambiguously so that help can be dispatched correctly to where they 
>>are when they can't answer questions.  This is a firm requirement for 
>>us, and we really, really need to have it.
>>
>>The current MSAG would be the natural beginning source of the mapping 
>>database envisioned by ecrit.  There are a whole host of 
>formatting and 
>>correlation issues.
>>
>>It is essential that validation happen BEFORE an emergency call.  
>>Ideally, it would happen when it happens now; when a location is put 
>>into the database that stores location (the Location Server).
>>
>>Given the current design of the ecrit mechanisms, and accepted 
>>requirements, the minimal way to do validation is to allow a mapping 
>>any time (like when the location is put into the Location 
>Server), and 
>>return some kind of error when the location presented is not in the 
>>database.  So validation means "I have no mapping for that location".
>>
>>A better answer would be to have a mechanism in LoST specifically for 
>>validation that could return more information than just "I have no 
>>mapping".  For example, it would be helpful to return possible 
>>alternative valid mappings.  A typical example is you query for "100 
>>Main St" and the mapping server returns "I don't have a 100 Main St, 
>>but I have a 100 N Main St or 100 S Main St".  You could also 
>return an 
>>indication of which elements in the input location were valid 
>(Country, 
>>State, and City was valid, but Street Name was not).  It 
>would also be 
>>useful to return information not included in the original 
>request (for 
>>example, you query with the postal community name, but leave 
>off county 
>>and jurisdictional community name, if a unique mapping was found, the 
>>missing data was supplied).
>>
>>It would also be good to have a form of validation for geo, which 
>>amounts to "there are no URIs for the service you requested with the 
>><geo> location you provided".  If you ask for police while you are in 
>>the middle of the Atlantic Ocean, you might get that response.
>>
>>
>>Brian
>> > Hi all,
>> >
>> > we need to close issue#35 about location validation. The issue can 
>> > be found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35.
>> >
>> > Note that I provide a summary at the end of my mail.
>> >
>> > 
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06
>> > .txt
>> > says:
>> >
>> > "
>> >     Location validation: A caller location is considered 
>valid if the
>> >        civic or geographic location is recognizable within 
>an acceptable
>> >        location reference systems (e.g., USPS, WGS-84, 
>etc.), and can be
>> >        mapped to one or more PSAPs.  While it is desirable 
>to determine
>> >        that a location exists, validation may not ensure 
>that such a
>> >        location exists.  Location validation ensures that 
>a location is
>> >        able to be referenced for mapping, but makes no 
>assumption about
>> >        the association between the caller and the caller's 
>location.
>> > "
>> >
>> > We had a discussion about this subject during the interim meeting:
>> > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html
>> >
>> > ----------------
>> >
>> > [07:53:24] <anewton> roger: issue 15 re validation of civic 
>> > [07:53:39] <anewton> andy: I thought the list left the issue not 
>> > about not doing it, but how.
>> > [07:53:46] <anewton> roger: need to know about the language in the 
>> > draft [07:54:08] <anewton> brian: something about a way to do it 
>> > [07:54:24] <anewton> jon: related to other req. such as 
>querying it 
>> > anywhere.
>> > [07:54:37] <anewton> james p.: we are no validating [07:54:56] 
>> > <anewton> ted: text in the issue tracker is not the meaning of 
>> > validation in NENA, etc...
>> > [07:55:12] <anewton> ted: this is a valuable piece of 
>protocol machinery.
>> > [07:55:39] <anewton> james: that makes sense, but the text doesn't 
>> > say that [07:56:03] <anewton> brian: if validation is defined as 
>> > succesful mapping to the PSAP, then that is what we want.
>> > [07:56:11] <anewton> james: need other word than "valid"
>> > [07:56:28] <anewton> brian: what we have can be used for NENA view 
>> > of the world [07:57:01] <anewton> james: anything out of this 
>> > building to the proper PSAP, but not floor by floor [07:57:16] 
>> > <anewton> brian: the requirement is to know that you can send a 
>> > responder.
>> > [07:57:32] <anewton> marc: not sure that is the NENA view, re ESN 
>> > [07:58:04] <anewton> brian: the location is knowing we can send a 
>> > responder [07:58:09] <anewton> nadine: agree [07:58:52] <anewton> 
>> > brian: definition of valdiation to be successful mapping to occur 
>> > for the location [07:59:10] <anewton> ted: this requirement needs 
>> > the point brian is making [07:59:49] <anewton> james: 
>concerned with 
>> > people thinking we mean something much more precise [08:00:12] 
>> > <anewton> hannes: the definition does not match the requirmenet 
>> > [08:00:26] <anewton> roger: let's examine the definition first 
>> > [08:01:09] <anewton> nadine & brian: this is a good defintion 
>> > [08:01:15] <anewton> james: no, that is cumbersome [08:03:04] 
>> > <anewton> henning: problem is that this is trying to define 
>> > validation for both civic and geo. first test is syntactic 
>validity. 
>> > the description is not clear if the actual address exists.
>> > [08:03:49] <anewton> henning: second test, is there a 
>valid mapping, 
>> > third, is there a street address that can be routed to.
>> > [08:04:14] <anewton> brian: clarifying this is a good idea.
>> > [08:04:21] <anewton> nadine: agree with 1 and 2, but not 3 
>> > [08:04:27] <anewton> roger: we cannot achieve 3 [08:04:38] 
><anewton> 
>> > henning: then we need to be clear about it [08:05:36] <anewton> 
>> > roger: "but not equivicate to an address" ?
>> > [08:05:58] <anewton> brian: add new sentence to clarify it. "while 
>> > desirable to have the address exist, not guarnateed."
>> > [08:06:46] <anewton> ted: wandering from the protocol requirement. 
>> > an address could be invalid for other purposes but could 
>get mapped 
>> > to a PSAP.
>> > [08:07:46] <anewton> ted: could I give you a PSAP based on the 
>> > location given, if answer is yes then that is the one 
>thing we care 
>> > about [08:08:01] <anewton> henning: just need a qualification of 
>> > what it does not mean [08:08:42] <anewton> brian: agree, see my 
>> > previous wording [08:09:17] <anewton> marc: mentions some use case 
>> > in Texas.
>> > [08:09:25] <anewton> brian: but that is not how it will work 
>> > [08:09:40] <anewton> marc: but if the address does not exist, no 
>> > PSAP [08:09:46] <anewton> brian: that is making an assumption 
>> > [08:10:35] <anewton> brian: current MSAG does address 
>ranges, but we 
>> > should have ability in future to work on single addresses 
>[08:11:07] 
>> > <anewton> marc: do you believe it shouldn't return an answer?
>> > [08:11:10] <anewton> brian: ?
>> > [08:11:41] <anewton> ted: in some administrations, the answer will 
>> > be "here is your PSAP, and btw the address you gave is foobar"
>> > [08:13:18] <anewton> nadine: be able to distinguish if it 
>is the "right"
>> > PSAP vs "default" PSAP?
>> > [08:13:47] <anewton> ted: for validation it would be "right".
>> > [08:14:33] <anewton> henning: this has implication on protocol 
>> > design choices.
>> > [08:15:57] <anewton> henning: difference in use case in validation 
>> > and non-validation (emergency case) and the bits on the 
>wire in the 
>> > protocol [08:16:00] <anabolism> If the case is that the address is 
>> > 125 main street, and 124 and 126 exist but 125 does not, would 
>> > validation indicate that the address is syntactically valid, the 
>> > psap returned would be for 124 and/or 126?
>> > [08:17:19] <anewton> are you asking a question for the room?
>> > [08:17:36] <anabolism> yes, but we've moved on abit [08:18:06] 
>> > <anabolism> I was trying to clarify comments from several people 
>> > [08:19:21] <anewton> brian: answering randy's q: "I can 
>map it, but 
>> > it isn't really valid. But in an emergency, it would send 
>you to the 
>> > closest PSAP."
>> > [08:19:32] <anabolism> Thanks, sounds reasonable to me [08:19:46] 
>> > <anewton> marc: result should be saying there is a problem in XML 
>> > [08:19:51] <anewton> brian: yes [08:20:12] <anewton> brian: it is 
>> > desirable to say you can get a mapping, but there is a 
>problem with 
>> > the address.
>> > [08:21:20] <anewton> henning: even in a real emergency query, this 
>> > is nothing wrong with indicating that the address is 
>foobar as long 
>> > as the PSAP is returned [08:22:11] <anewton> ted: in a real 
>> > emergency only look at the one thing they map on. 
>validation may be 
>> > a different task.
>> > [08:22:47] <anewton> brian: but that work for you [08:22:56] 
>> > <anewton> ted: that is why this is desirable.
>> > [08:23:04] <anewton> nadine: ?
>> > [08:23:17] <anewton> nadine: if you only know that it is a known 
>> > range [08:24:34] <anewton> andy: just need to make sure that 
>> > implementers don't let the error show up in the emergency case 
>> > [08:24:58] <anewton> roger: do we agree that in addition 
>to the URL 
>> > that it is desirable to have a result code?
>> > [08:25:10] <anewton> henning: generally, yup/ [08:25:27] <anewton> 
>> > is the audio being recorded?
>> > [08:26:10] <anewton> henning: it is more than a status code 
>> > [08:26:16] <anewton> roger: additional information?
>> > [08:27:13] <anewton> hannes: Validation Resolution: it MAY be 
>> > possible to return additional information which can be used to 
>> > determine the preceision or resolution of the returned sip 
>uri, for 
>> > example
>> >
>> > ----------------
>> >
>> > The meeting minutes of the interim meeting indicate:
>> > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html
>> >
>> > ----------------
>> >
>> > Issue 15
>> >
>> > Validation of civil location has been hanging around for a while. 
>> > Should it stay in the 02 draft? Andrew thought the issue 
>was how we 
>> > would do validation, not whether. Brian wants to leave the 
>language 
>> > in, but would like to know if people think it's adequate (we're 
>> > using motivations text to describe what validation means). 
>"A successful mapping will work".
>> >
>> > We actually do have other requirements that talk about this (doing 
>> > queries at any time), but we don't describe it anywhere else.
>> >
>> > Are we actually validating? We don't mean NEMA validation, only 
>> > asking whether it's enough to get back a PSAP mapping. 
>Passing back 
>> > "here's the PSAP" would be sufficient. Can we use another word? 
>> > "Validation" has lots of baggage. Brian wants to make sure that we 
>> > can get to NEMA validation - "a location that a responder 
>knows how 
>> > to get to". "A location that can be sucessfully mapped to 
>one or more PSAPs".
>> >
>> > We're trying to encompass both civil location and 
>geolocation in one 
>> > sentence - this is one reason why it's cumbersome. If all of the 
>> > city of Washington goes to one PSAP but the location isn't 
>valid, we 
>> > still have a problem. MSAG values have the same problem, because 
>> > they carry street number ranges and a "valid" street 
>number may not 
>> > exactly exist - and the best MSAG validators today can't 
>guarantee that the address exists.
>> >
>> > An address can be "valid enough" to get to the right PSAP, even if 
>> > it's not valid to respond to. Texas has one PSAP entry - 
>so anything 
>> > would work as long as it's in Texas? No, the current MSAG works on 
>> > address ranges - but the street exists. Brian would like 
>for this to 
>> > work on individual addresses, not ranges.
>> >
>> > Brian thinks that local PSAPs should be determining what 
>happens for 
>> > various values of "invalid", since calls are going to go somewhere!
>> >
>> > Ted thinks that there's a lot of variation in what administrations 
>> > do now and will do in the future.
>> >
>> > Will the protocol allow us to tell that we got to the 
>right PSAP, or 
>> > just got a PSAP?
>> >
>> > Henning - just returning a SIP URI to let someone ask "where the 
>> > heck are you?" isn't sufficient when we're actually 
>routing an emergency call.
>> >
>> > We always get a SIP URI, we're trying to figure out what getting a 
>> > SIP URI actually means for an operational system.
>> >
>> > "I got a match on all the XML tags except this one" would be an 
>> > acceptable response, and this would be desirable. This 
>could happen 
>> > at validation time or at emergency call routing time.
>> >
>> > Validation may mean "I like the only tags that I care about, and 
>> > didn't look at the ones I don't care about".
>> >
>> > Do we agree that we need a result code, in addition to a URI? 
>> > Partial validation may be the common case (public verifiers won't 
>> > know suite numbers/room numbers, for example).
>> >
>> > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism 
>> > (whether it gets used or not is up to the administration).
>> >
>> > And we need to be consistent in our RFC 2119 usage (which 
>is always 
>> > problematic for requirements documents anyway, since the 
>meaning is 
>> > a protocol-mechanism meaning, not a protocol-usage meaning). We're 
>> > making a lot of these requirements MUSTs, and that may make the 
>> > resulting protocols clumsy. If we use 2119, we should be 
>using MUST, 
>> > MAY and SHOULD, not just MUST.
>> >
>> > Tom pointed out that some mechanisms may be provided by 
>extensions, 
>> > but are not required in the base protocol.
>> >
>> > Henning says we're not writing a BCP, so we should consider NOT 
>> > using
>> > 2119 language.
>> >
>> > Randy suggested that we actually spell out "must support", 
>etc. and 
>> > not rely on 2119. Henning - then we should have consistent 
>> > terminology, whether it's upper case or lower case. Randy 
>will audit 
>> > the existing document, but needs input from others.
>> >
>> > What about returning an indicator of the resolution of the mapping 
>> > that is returned?
>> >
>> > Brian suggested text for a mechanism to indicate that a 
>location or 
>> > part of location does not exist, even if it can be mapped. Should 
>> > this point out the invalid pieces? Aren't these 
>> > administration-specific? Tags are roughly self-describing, but we 
>> > can't pick one hierarchy - what gets returned needs to be 
>free-form.
>> >
>> > James - doesn't the text say "location should be sent even if it's 
>> > considered unreliable?" Is this OK?
>> >
>> > We will leave L01 language as is, change "location validation" in 
>> > terminology, and we are adding two new requirements to 
>this section.
>> >
>> > ----------------
>> >
>> > The discussions regarding Issue#15 caused us to change the 
>following 
>> > requirement into two requirements:
>> > http://www.ietf-ecrit.org:8080/ecrit-req/issue15
>> >
>> > "
>> >  >   Lo1.  Validation of Civic Location: It MUST be possible to
>> >  >validate a
>> >  >      civic location prior to its use in an actual 
>emergency call.
>> >  >
>> >  >      Motivation: Location validation provides an 
>opportunity to help
>> >  >      assure ahead of time, whether successful mapping to the
>> >  >      appropriate PSAP will likely occur when it is required.
>> >  >      Validation may also help to avoid delays during 
>emergency call
>> >  >      setup due to invalid locations.
>> >
>> > "
>> >
>> > to:
>> >
>> > "
>> > Lo1X.  Validation Resolution: The mapping protocol MUST 
>support the 
>> > return of additional information which can be used to 
>determine the 
>> > precision or resolution of the data elements used to determine a 
>> > PSAP URI, for example.
>> >
>> > Lo1XX.  Indication of non-existent location: The protocol MUST 
>> > support a mechanism to indicate that a location or a part of a 
>> > location is known to not exist, even if a valid 
>location-to-PSAP uri 
>> > mapping can be provided.
>> > "
>> >
>> > The term validation appears only in the following sections.
>> >
>> > Section 1 (Introduction):
>> >
>> > "
>> >     As used in this document, validation of location does 
>not require to
>> >     ascertain whether the location actually exists.  For example,
>> >     validation might only check that the house number in a 
>civic address
>> >     falls within the assigned range, not whether that 
>building exists at
>> >     that spot.  However, such higher precision validation 
>is desirable.
>> > "
>> >
>> > Section 2 (Terminology):
>> > "
>> >     Location validation: A caller location is considered 
>valid if the
>> >        civic or geographic location is recognizable within 
>an acceptable
>> >        location reference systems (e.g., USPS, WGS-84, 
>etc.), and can be
>> >        mapped to one or more PSAPs.  While it is desirable 
>to determine
>> >        that a location exists, validation may not ensure 
>that such a
>> >        location exists.  Location validation ensures that 
>a location is
>> >        able to be referenced for mapping, but makes no 
>assumption about
>> >        the association between the caller and the caller's 
>location.
>> > "
>> >
>> > Section 7 (Mapping Protocol):
>> >
>> > "
>> >     Ma22.  Validation of civic location: The mapping protocol MUST
>> >        implement a method via a mapping request, that 
>makes it possible
>> >        for a mapping server to validate a civic location 
>prior to that
>> >        location's use in an actual emergency call.
>> >
>> >        Motivation: Location validation provides an 
>opportunity to help
>> >        assure ahead of time, whether successful mapping to the
>> >        appropriate PSAP will likely occur when it is required.
>> >        Validation may also help to avoid delays during 
>emergency call
>> >        setup due to invalid locations.
>> >
>> >     Ma23.  Validation resolution: The mapping protocol MUST support
>> >        (i.e., required to implement, but not required for 
>use) the return
>> >        of additional information which can be used to determine the
>> >        precision or resolution of the data elements used 
>to determine a
>> >        PSAP URI.
>> >
>> >        Motivation: The mapping server may not use all the 
>data elements
>> >        in the provided location information to determine a 
>match, or may
>> >        be able to find a match based on all of the 
>information except for
>> >        some specific data elements.  The uniqueness of 
>this information
>> >        set may be used to differentiate among emergency 
>jurisdictions.
>> >        Precision or resolution in the context of this 
>requirement might
>> >        mean, for example, explicit identification of the 
>data elements
>> >        that were used successfully in the mapping.
>> >
>> >     Ma25.  Limits to validation: Successful validation of a civic
>> >        location MUST NOT be required to place an emergency call.
>> >
>> >        Motivation: In some cases, a civic location may not 
>be considered
>> >        valid.  This fact should not result in the call 
>being dropped or
>> >        rejected by any entity along the signaling path to the PSAP.
>> > "
>> >
>> > I think we need to differentiate civic and geospatial location 
>> > information.
>> >
>> > Geospatial location information:
>> >
>> >   * Can the request be mapped to one or more PSAPs?
>> >
>> >     This is normal mapping protocol operation. Nothing 
>special here.
>> >
>> >   * Does the address exist?
>> >
>> >     There is no question that this address exists
>> >     if the coordinate reference system was understood.
>> >
>> >
>> > Civic location information:
>> >
>> >   * Can the request be mapped to one or more PSAPs?
>> >
>> >     The text from Ma23 is applicable here:
>> >
>> >        Motivation: The mapping server may not use all the 
>data elements
>> >        in the provided location information to determine a 
>match, or may
>> >        be able to find a match based on all of the 
>information except for
>> >        some specific data elements.  The uniqueness of 
>this information
>> >        set may be used to differentiate among emergency 
>jurisdictions.
>> >        Precision or resolution in the context of this 
>requirement might
>> >        mean, for example, explicit identification of the 
>data elements
>> >        that were used successfully in the mapping.
>> >
>> >   * Does the address exist?
>> >
>> >     It is possible that a given civic address does not exist.
>> >     An additional database, which contains the list of existing
>> >     addresses, needs to be available.
>> >
>> >
>> > What we can do is to be more specific about the type of 
>behavior we 
>> > want from the mapping protocol.
>> > Do we want the client to be able to express that the 
>mapping server 
>> > should check the civic address for existence?
>> > Do we want the mapping server to be able to indicate that 
>the civic 
>> > address was checked against the database?
>> > I don't think anything needs to be done with regard to geospatial 
>> > location info.
>> >
>> > Do we need something else?
>> >
>> > Ciao
>> > Hannes
>> >
>> > _______________________________________________
>> > Ecrit mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/ecrit
>> >
>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Apr 2006 22:18:15 +0200

Hi Roger,

> indication as to whether a specific civic location exists.

Fine. Easy.

> fall within a acceptable range of (address) values.

Fine, but complex.

> Main St. DNE, might return "'123 S. Main St.' or '123 N. Main St.'

 From a requirement point of view it looks easy but I would like to see 
concrete proposals how to accomplish this goal. I don't want to turn the 
  mapping protocol into a "SELECT * FROM ...." database retrieval system.

> 'Main St. Mytown' was found".

One could theoretically indicate which attributes matched and which 
attributes didn't (e.g., A1, A2, .... A5 matched but BLD didn't).

> civic or geographic location matching (e.g., USPS, MSAG, GDT, etc.).

Fine; Wouldn't we want to carry this information into a PIDF-LO itself 
to indicate the quality of the returned location information.  As such, 
we would have to tackle it in Geopriv.

> well enough, but as James pointed out, a subsequent geo-specific draft

Maybe. Not sure.

I am concerned about the complexity of all these sophisticated error 
handling mechanisms. I wonder what a client is really going todo about 
them.

Ciao
Hannes