Re: [Geopriv] Location in SIP and "retransmission-allowed"

From: Richard Barnes ^lt;>
Date: Fri May 04 2007 - 14:31:24 EDT

> Let's try logic again. ... Thus, when a proxy extracts the identity (no
> location) and asks RADIUS or DIAMETER for authorization, this would also
> imply a retransmission and thus be disallowed.

This isn't addressed by 4119 since it's not location, but you're correct
to observe that identity without location is sensitive in much the same
way as location without identity. I imagine that certain
law-enforcement agencies would be very interested if the VSPs would let
them know whenever callers with certain identities use an LBS (i.e.,
send a LO).

> I note that you keep avoiding addressing the actual consequences of
> doing what you propose, given that almost all location-based calls would
> fail without setting the flag to yes. This differs from the
> 'retransmission' flag, in that the whole point was that the desired
> recipient could do what they needed, but no more, even if the flag was
> set to 'no'.

If this was the intent, it is not what was recorded in RFC 4119. I'm
not saying that its correct or incorrect, just that the standard would
have to be changed. I'm curious what language you would use that would
capture "do what they needed, but no more".

> I have repeatedly proposed a solution; please consult the archives for
> details.

I'm sorry, nothing in the archive jumps out at me as a concrete
proposal. Could I request a retransmission?


> Henning
> On May 4, 2007, at 1:27 PM, Richard Barnes wrote:
>> I consulted with corporate counsel, and he observed that RFC 4119 says
>> that if retransmission-allowed=no, then that indicates that the user
>> doesn't want the recipient to retransmit either the LO (with
>> identifiers) or the LI (without). This seems to me very explicit,
>> very common-sense.
>> So Marc/Henning: Either
>> 1) What about this situation allows retransmission for LoST? Or,
>> 2) What modification do you propose?

Geopriv mailing list
Received on Fri, 04 May 2007 14:31:24 -0400

This archive was generated by hypermail 2.1.8 : Fri May 04 2007 - 14:31:37 EDT