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

From: Matt Lepinski ^lt;mlepinsk@bbn.com>
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
location-conveyance:

(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
necessary.]

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@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
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