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

From: Matt Lepinski ^lt;>
Date: Thu May 10 2007 - 15:26:23 EDT

[Stepping back for a second] From reading this thread I conclude that:

(Please let me know if I'm mis-interpreting the discussion)

1) Everyone agrees with Henning on the following point

> I think the discussion shows that our foundational documents lack
> clarity and motivation, as they don't actually explain the goals and
> provide guidance that corresponds to these goals (presumably, privacy
> from third parties).

2) Performing exegesis on documents that "lack clarity and motivation"
is not a productive use of time.

3) No one is strongly supporting the text currently in the -07 version
of location conveyance which adds the routing-query-allowed element to
the PIDF-LO specification.

[Personally, I don't like the current text of location-conveyance since
it solves a SIP-only problem by adding an element to (potentially all)
PIDF-LO objects]

4) Two reasonable changes have been proposed to the text in

(A) Remove the routing-query-allowed element and process all SIP
messages as though routing-query-allowed were present and set to "yes".
That is, by including location in a SIP message the user is implicitly
providing consent for the location to be used in whatever routing
queries are needed for the message to reach it's designated destination.

[This approach may require normative changes to 4119. However, whether
this approach requires changing 4119 can be discussed after we've come
to consensus on whether this is the perferred approach.]

(B) Remove the routing-query-allowed element and allow a user to mark
[using some reasonable syntax] a conveyed location as either "intended
for routing", "intended for the end-point" or "intended for both" (where
the default behaivor is "intended for both").

[This would add no additional length to the SIP message in the common
case where the location can be used for either routing or by the
end-point, but allows the user to explicitly indicate his desires if

Given my understanding of the discussion, it seems that to move forward
we need to try reach consensus on whether (A) or (B) is the perferred
technical choice [which I believe is possible] and postpone theological
discussions on which there is little hope of reaching consensus.

- Matt Lepinski :->

> Henning
> On May 9, 2007, at 5:29 PM, Richard Barnes wrote:
>> Ok, we're back to this:
>> The difference is in whether the proxy is a Recipient of the LO. If
>> it passes the bits along blindly, without interpreting them, then it
>> has not, for privacy purposes, received the LO. This is why you can
>> pass an LO with retransmission-allowed=no through a
>> store-and-forward network (be it SIP, email, whatever).
>> If the proxy reads and acts on the LO, then it becomes a Location
>> Recipient, and is bound by the privacy rules in the LO (and
>> possibly, as we've discussed, in the SIP header). Then, if
>> retransmission-allowed=no, that indicates that the proxy should not
>> send the LO -- or the LI within it -- to another party. And, as
>> I've discussed before, there's some flexibility in "party", but
>> there's no sensible definition that allows arbitrary LoST queries.
>> The trouble with -conveyance is that it allows both UASs and proxies
>> to be the recipients of the location, even though the UAC might want
>> to send different locations with different privacy rules to these
>> two different sets of recipients. I think indicating destinations
>> (with header fields or tags) is a simple way to disambiguate this.
>> --Richard
> _______________________________________________
> Geopriv mailing list

Geopriv mailing list
Received on Thu, 10 May 2007 15:26:23 -0400

This archive was generated by hypermail 2.1.8 : Wed Jun 27 2007 - 17:01:54 EDT