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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Wed May 09 2007 - 17:29:43 EDT

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

Henning Schulzrinne wrote:
>>
>> And here I thought the burden of proof for someone changing the semantics
>> of a settled, published RFC was on the person proposing the change.
>> RFC 4119
>> is clear on the current semantics, Henning. You're the one arguing
>> for changing
>> the meaning of "no" in a published doc. I'm trying to find a way to
>> get the
>> semantics you need without borking the ones the WG already agreed on.
>>
>
> Since we're now into protocol lawyering, I'll play: The text in 4119 reads
>
> 'retransmission-allowed': When the value of this element is 'no', the
> Recipient of this Location Object is not permitted to share the
> enclosed Location Information, or the object as a whole, with
> other parties. When the value of this element is 'yes',
> distributing this Location is permitted (barring an existing out-
> of-band agreement or obligation to the contrary). By default, the
> value MUST be assumed to be 'no'. Implementations MUST include
> this field, with a value of 'no', if the Rule Maker specifies no
> preference.
>
>
> 'parties' is not defined in RFC 4119, as far as I can tell, as the word
> only appears once. The text certainly makes no distinction based on
> protocols, so that forwarding by SIP is ok, but forwarding by another
> protocol is not. RFC 3693 does not define party in any technical terms,
> either.
>
> The IETF boiler plate uses party in an organizational sense ("invites
> any interested party...").
>
> Wikipedia defines
>
> A party is a person or group of persons that compose a single entity
> which can be identified as one for the purposes of the law.
>
> Again, this makes no distinction based on protocols, or even whether
> this is a single individual. In this case, 'party' could just as well be
> a government agency operating a PSAP or PizzaHut.
>
> Thus, I see no textual basis for your statement.
>
>
> Henning
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 Wed, 09 May 2007 17:29:43 -0400

This archive was generated by hypermail 2.1.8 : Wed May 09 2007 - 17:29:30 EDT