Subject: Validation in scope or not (was Re: [Ecrit] Issue)

From: "James M. Polk" <[email-masked]>
Date: Fri, 23 Dec 2005 02:37:43 -0600

Richard

I do not know how a mapping protocol will deal with the interactivity you 
want if the location provided is invalid (during the emergency call).

This is obviously an error condition.

So what type of SIP error is send from the ESRP to the UAC to tell them 
that the location in their INVITE was not valid, and therefore the call 
will not be placed?

Is this a regular error message like a 424 (Bad Location) message (as 
proposed for a different use in
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-01.txt

Do you want UAs to be configured with code to allow for an interactive, 
almost negotiation, to occur between the mapping server (what the ESRP 
communicates with when using whatever mapping protocol ECRIT decides on) 
and the user to figure out where the user really is (before the emergency 
call is routed further into the network)?

At 09:08 AM 12/23/2005 +0100, Stastny Richard wrote:
>James,
>
>I agree with Brian that this is requirement of the protocol and/or 
>behaviour of
>the mapping database, as he explained. Especially the part on responding
>with valifd alternatives and different latency.
>
>We cannot design a database protocol without having all requirements
>on the table.
>
>If this is out of scope, we have a problem with the scope and not
>a requirement out of scope
>
>Richard
>
>
>
>________________________________
>
>Von: [email-masked] im Auftrag von Winterbottom, James
>Gesendet: Fr 23.12.2005 06:01
>An: [email-masked]; James M. Polk; Roger Marshall; [email-masked]
>Betreff: RE: [Ecrit] Issue
>
>
>
>Brian,
>
>No one is arguing that this needs to be done ahead of time. This is why
>it is a provisioning issue and not a call routing issue. So it is out of
>scope.
>
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Friday, 23 December 2005 1:38 PM
> > To: 'James M. Polk'; Winterbottom, James; 'Roger Marshall';
>[email-masked]
> > Subject: RE: [Ecrit] Issue
> >
> > I do not agree, and I'm pretty sure there are a lot of folks who have
> > experience with emergency calls who would be consider it a fundamental
> > characteristic of an emergency call system.
> >
> > You MUST know, before you make a call, that the location you report
>can be
> > used to get you help.  That has two uses:
> >       a) that you can find a valid mapping, which will get your call
>to
> > the proper PSAP
> >       b) that the PSAP can dispatch a responder such that the
>responder
> > can find you
> >
> > To do so, it is required that you validate location before you make
>the
> > call.  This is a mechanism requirement, or, if you like, a mechanism
> > design
> > constraint.
> >
> > An acceptable mechanism is to allow one to determine prior to a call
>that
> > a
> > valid mapping exists.  If the locations used to determine a valid
>mapping
> > are those needed for valid dispatch, for which the data may be
>reasonably
> > made consistent, and you can do the mapping any time (not just when an
> > emergency call is placed), that will be minimally acceptable.
> >
> > Clearly, it would be possible to design the mapping mechanism such
>that it
> > could only be used in the process of routing a call.  That would be
> > unacceptable.  The requirement is necessary to make sure the mechanism
>can
> > be used to validate location prior to a call.
> >
> > The validation is the requirement.
> >
> > Allowing mapping at any time, and using dispatch-quality data for
>mapping
> > input is a solution.
> >
> > We have found it advantageous to provide for additional capability
>that is
> > specific to validation.  For example, it is convenient to allow the
> > validation function to return multiple valid alternatives when queried
> > with
> > an invalid location.  So, if you queried for 100 Main Street, there
>was no
> > 100 Main St, but there was a 100 North Main and a 100 South Main, then
>we
> > would like to return both the alternatives when doing validation.
>That
> > kind
> > of response is generally not appreciated when routing a call.  It
>takes a
> > human to decide which of the alternatives, if any, is the actual
>location.
> >
> > There are some other desirable functions that could differentiate a
> > validation request from a mapping request.  There are also operational
> > differences; one typically re-validates periodically, and every
>location
> > is
> > validated.  This means the volume of operations for validation dwarfs
>the
> > volume of actual emergency calls.  However, mapping does not have the
>same
> > latency or the same reliability constraints.  This may, or may not, be
> > relevant, depending on the mechanism chosen.
> >
> > However, North America, and specifically NENA, has a firm requirement
>for
> > validation.  It is a current capability.  There is a valid and
>important
> > reason for it.  It's clearly implementable.
> >
> > For those reasons, I believe it must stand.  We could reword the
> > requirement
> > and the motivation if that would help.
> >
> > First, let us see if we can get rough consensus on existence of a
> > validation
> > requirement.  Then we can work on the wording.
> >
> > Brian
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
>Of
> > James M. Polk
> > Sent: Thursday, December 22, 2005 7:35 PM
> > To: Winterbottom, James; Roger Marshall; [email-masked]
> > Subject: RE: [Ecrit] Issue
> >
> > At 05:24 PM 12/22/2005 -0600, Winterbottom, James wrote:
> > >I completely agree with this assessment.
> > >This is a provisioning requirement.
> >
> > I agree with James
> >
> >
> >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On
>Behalf
> > >Of
> > > > Roger Marshall
> > > > Sent: Friday, 23 December 2005 10:17 AM
> > > > To: [email-masked]
> > > > Subject: RE: [Ecrit] Issue
> > > >
> > > > Bringing this one back up for discussion in order to resolve the
> > >logged
> > > > issue.
> > > >
> > > > Issue 15: Validation of civic location
> > > >
> > > > Currently written as:
> > > > 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.
> > > >
> > > > The following questions were raised from the list, but never
> > >resolved...
> > > > "Is this a protocol requirement or an architecture requirement?
>When
> > > > should this validation take place?"
> > > >
> > > > My comment:
> > > > This requirement doesn't really say anything about the mapping
> > >protocol.
> > > > We know that all kinds of things are possible prior to an
>emergency
> > > > call.  Additionally, we know that the mapping protocol should have
>a
> > > > valid location as input to the mapping function in order to be
> > > > successful.  Nevertheless, I contend that it is not the job of the
>MP
> > >to
> > > > specify this.  If a "non-valid" address is used, it will either
>map or
> > > > not map to a URI, in which case an error will result.  One
>person's
> > > > architecture may take advantage of this fact, always employ
> > >validation,
> > > > and become more robust than next guy's.
> > > >
> > > >
> > > > I say that we should delete this requirement, Lo1.  Other
>comments?
> > > >
> > > >
> > > > Roger Marshall.
> > > >
> > > >
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> >
> >-----------------------------------------------------------------------
>--
> > --
> > ---------------------
> > >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]
> > >
> > >_______________________________________________
> > >Ecrit mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
>
>------------------------------------------------------------------------------------------------
>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]
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit

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