Ted
The "recipient=" within the Geolocation header is a SIP parameter, in
a SIP document. Everything discussed in Geopriv regarding this
document needs to be approved in SIP too. The SIP WG hasn't heard
this part of the discussion because most members of SIP aren't
subscribed to the Geopriv list.
I'm on the agenda right now to present in SIP in Vancouver, and this
is one issue I'd like the SIP WG to comment on, so I'll be asking it there.
the rest of my reply is in-line
At 01:51 PM 11/21/2007, Ted Hardie wrote:
At 6:33 PM -0600 11/20/07, James M. Polk wrote:
>Daniel
>
>wow... you nailed this one quickly.
>
>Neither the SIP WG nor Geopriv WG have a position with regard to
this. I don't like the parameter at all, and have said so from its
introduction into discussions about putting it in the draft. I
don't think it accomplishes much more than confusion or a false
sense of security by implementors.
Well, I think the Geopriv working group discussed this a great deal, and that
there was reasonable (albeit rough) consensus that it be included. Anyone
interested can certainly see a lively debate on the Geopriv list.
and where was the SIP WG discussion on a SIP header parameter? Since
this parameter, from what you state below, has a UA understanding
the topology of a request - all the way to the endpoint - which is
not part of the Geopriv charter to know or make decisions on, where's
that discussion, at least as confirmation that SIP UAC's can know the
full topology of a network enough to make this decision (that can't
be changed)?
For example, Alice calls PizzaHut.com, and Pizza Hut routes her call
to the Pizza Hut store most local to wherever she is to take her
order. Does her UAC understand this type of call well enough to have
"recipient=both"? Or would it just enter "recipient=endpoint", thus
preventing her SIP request from being retargetted?
How does her UAC understand the different from this type of call to
Pizza Hut from merely a complaint to Pizza Hut corporate?
I still can't seem to get over this simple example of a limitation
and assumption created by this header parameter that the caller
doesn't control.
The current text is:
A locationValue has the following independent header parameters,
(snip of other parameters)
the "recipient=" parameter to allow recipients to infer what SIP
element type this locationValue was intended to be for. The
types are
o "endpoint" - meaning the ultimate destination UAS;
o "routing-entity" - meaning SIP servers that route messages
based on the location contents of requests; and
o "both" - meaning this locationValue is to be viewed by both
types of SIP entities.
Not all SIP entities have to read the locationValue within a
Geolocation header, therefore a parameter value of "both" does
not mean "every" SIP element receiving this request, it means all
that care to pay attention to a locationValue. The default
behavior of SIP entities reading the locationValue is that if
this header parameter is NOT present, the intended recipient is
the destination UAS.
A proxy seeing a locationValue with a recipient= tag of
routing-entity or both MAY do location based routing using
the location (as the draft says, it does not have to). A proxy
seeing a locationValue with a recipient=endpoint should understand
that the locationValue was not intended to be used for
location-based routing. The draft is pretty clear that the
privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
Location Recipients MUST obey the privacy and security rules in the
PIDF-LO as described in RFC 4119 regarding retransmission and
retention.
If a proxy is not the intended recipient, as given in this parameter,
it shouldn't be storing or acting on this data, just sending it along.
>That said, a proxy has "ar" capabilities wrt the Geolocation
according to Table 1. (on page 7), and associated text states this
pretty clearly. There is no text (not even a hint) that a proxy
cannot read a location because "recipient=endpoint", therefore it
can. I would take this "recipient=" parameter as a hint to each
type of SIP entity that
>
> + if a UAS receives this parameter (meaning in a SIP request with
> a Geolocation header), and it is set to "recipient", the UAS
> shouldn't ignore the location in the request (like it otherwise
> might).
>
> + If a proxy receives this parameter (meaning in a SIP request with
> a Geolocation header), and it is set to "server", the proxy
> shouldn't ignore the location in the request (like it otherwise
> might).
>
>I don't think either indication *ever* means the other SIP entity
type cannot view the location, based on the parameter.
I don't understand what you mean by "view" here. A proxy putting
this to memory
in order to send it along is doing fine; someone doing
location-based-routing when
recipient=endpoint is not doing the right thing (except in the
Emergency Services
case, where all bets are off).
RFC3261 says proxies can view message bodies that aren't encrypted.
I don't see the text giving an exemption in the emergency case, not
at least in this doc.
>The only exception I can think of is a Location-by-value hidden by
S/MIME means no one save who has the decryption key can view the
contents of what's encrypted.
>
>Does this make sense?
I suggest we continue the conversation in GeoPRIV if we have further
discussion
on this particular point.
But this is a SIP parameter, and a SIP document. Everything
discussed in Geopriv needs to be approved in SIP too. The SIP WG
hasn't heard this part of the discussion because most members of SIP
aren't subscribed to the Geopriv list.
Ted
>James
>
>At 04:59 AM 11/20/2007, Daniel Grotti wrote:
>>Hi all,
>>I'd like to ask a question about
"draft-ietf-sip-location-conveyance-09.txt".
>>
>>How does Proxy Server have to work when a Geolocation Header
contain "recipient=endpoint" parameter ?
>>Does the Proxy server just have to forward the SIP message
(without do anything else) or can it read the information conveyed ?
>>thanks,
>>Regards
>>daniel
>>
>>--
>>
>>---------------------------------------------------
>>Daniel Grotti
>>DEIS - University of Bologna
>>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
>>
>>Contacts
>>e-mail : [EMAIL PROTECTED]
>>Skype name : Daniel Grotti
>>---------------------------------------------------
>>
>>
>>
>>_______________________________________________
>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use [EMAIL PROTECTED] for questions on current sip
>>Use [EMAIL PROTECTED] for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [EMAIL PROTECTED] for questions on current sip
>Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
