ecrit@ietf.org
[Top] [All Lists]

RE: AW: [Ecrit] Location Hiding -- State of the Art

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
From: "Winterbottom, James"
Date: Mon, 10 Dec 2007 13:25:52 -0600
Ted inline.

> 
> I really don't think you do need that.  It may be handy, but the
billing
> problem is really quiet different.  In case one, you want something
> that can be handed back to a phone with no per-dip charge.  I've
> already mentioned some ways of dealing with that at a billing level,
> and I'm trying to suggest that if those don't work going to Brian's
> method does.  The location delivered will not be sufficient for
> anything other than discovering the right PSAP.
> 

If the device is simply given a PSAP URI, a service URN, and a location
URI, what more does it need?

> For non-emergency cases, you are dealing instead with the
> case where you have a concern that selling someone location
> for purpose X gets them location for purpose Y.  That's both
> a different problem and it falls into an area where there are
> enough other problems that it is, honestly, probably the least
> of your worries.  It's also way out of the charter of this group.
>

I would argue that location hiding is not in the charter of this WG at
all. How to route to a PSAP is the current charter, so if the end-point
is given all it needs to route to the PSAP then we are done aren't we?

 
> >So in short answer, I am very unhappy with any solution that requires
> >the LIS to do service boundary mappings on-platform.
> >
> 
> Some warm cocoa may help with your unhappiness.  But I'm not too
> happy when people raise issues and then reject solutions which
> require them to spend effort; especially when their proposals are
> fundamentally more fragile for delivery of critical services.
> 
Umm, how is providing the end point with where it needs to go more
fragile than giving it a bodgey location?


Cheers
James
------------------------------------------------------------------------------------------------
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

<Prev in Thread] Current Thread [Next in Thread>