Subject: [Geopriv] <retransmission-allowed>

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 21 Sep 2009 22:17:53 +0300

Hi Brian, 
Hi James 

if I am the only one still seeing problems with <retransmission-allowed>
in context of SIP location conveyance then I keep my mouth shut. 

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Sep 2009 16:45:00 -0400

RFC 5606?
<http://tools.ietf.org/html/rfc5606>

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Sep 2009 02:46:59 -0500

Hannes

This was the context I asked about if I was missing from your 
"intended recipient" comment in a recent thread.  I don't know if you 
meant the <retransmission-allowed> topic -- which isn't really an 
"intended recipient" but more like a "preventing unintended 
recipient(s)" thread -- or another topic. The idea of intended 
recipient is sufficiently different from <retransmission-allowed> in 
my mind that I had to ask if you were considering the two the same topic.

The <retransmission-allowed> topic (and the subject of RFC 5606, as 
Richard pointed out) is about strongly suggesting an intermediary 
server not look at information it can (i.e., the PIDF-LO or 
dereference the location URI - either of which is contained in a SIP 
request message that server is processing.  There really is not 
anything "intended" about it. We don't ever say "this is for servers" 
or "this is for endpoints" -- although I had that text in earlier 
versions of Conveyance.  Based on the <retransmission-allowed> 
effort, I was forced to remove this "intended recipient" header 
parameter from that doc.

Now, Martin went down a path of saying any location in a SIP request 
is obviously the originator of the request.  But this limitation is 
not allowed in PIDF-LO. At this point, this list (and SIP and 
SIPCORE) got into the differences between the 'entity' attribute in 
the <presence> element vs. the <device ID> element vs. the SIP From: 
header value.

(Does this give you understanding of the confusion I have with your question? )

Ultimately the 'entity' attribute can match the From header value if 
the SIP request contains the PIDF-LO. Martin agrees with this, as 
does Brian. I was after getting the 'entity'/From: linkage for all 
situations. The problem is with the location URI, and being able to 
still maintain this linkage.  I'm willing to concede that there can 
be only 1 location in a SIP request if a location URI is given out, 
if we can agree that if locations values are in the SIP request - 
that more than one target's location (in separate PIDF-LOs) can be 
given out. I'll add text stating that the way to match the SIP 
request originator to a PIDF-LO is if the From: value is the same as 
the 'entity' attribute.  Also, that PIDF-LOs that don't match this 
From/entity linkage can be ignored if the LR doesn't understand what 
to do with that location.

It could easily be the case in which Alice has Carol's location 
(Carol's <retransmission-allowed> set to yes), and Alice sends 
Carol's location to Bob.  If Bob knows Carol, he consumes her 
location. If Bob doesn't know Carol, he ignores that PIDF-LO.  All 
this is separate from Alice including her PIDF-LO in the SIP request 
towards Bob - which he identifies by matching the From/entity linkage.

That said, if Alice were to send Bob her location with a location 
URI, I'll add text that says this must be the only location in that 
SIP request.

Does this make sense to you?  What about anyone else?

Is there something still unsettled in your mind wrt this overall topic?

James

>>Hi Brian, Hi James