>RFC 5606?
><http://tools.ietf.org/html/rfc5606>
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
>Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>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
>>
>>
>>------------------------------------------------------------------------
>>_______________________________________________
>>Geopriv mailing list
>>Geopriv@ietf.org
>>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
