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

From: Matt Lepinski <[email-masked]>
Date: Thu, 10 May 2007 15:26:23 -0400

[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 weFrom [email-masked] Wed Jun 27 17:01:45 2007
Date: Thu, 10 May 2007 15:26:23 -0400
From: Matt Lepinski <[email-masked]>
Organization: BBN
To: Henning Schulzrinne <[email-masked]>
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"
Cc: GEOPRIV <[email-masked]>

[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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv