|
|
I completely agree with this assessment.
This is a provisioning requirement.
> -----Original Message-----
> From: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] On Behalf
Of
> Roger Marshall
> Sent: Friday, 23 December 2005 10:17 AM
> To: ecrit@xxxxxxxx
> 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
> Ecrit@xxxxxxxx
> 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
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|