At 03:02 PM 11/21/2007, Ted Hardie wrote:
At 2:28 PM -0600 11/21/07, James M. Polk wrote:
>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.
That SIP parameter in a SIP document relates to a PIDF-LO object carried by
SIP; in that context, SIP is a using protocol of the GEOPRIV framework. SIP
folks should certainly understand the work they're reusing, or the
implementations
won't do the right thing. But re-starting the conversation in SIP without
reference to the discussions that have already occurred in GeoPRIV is a
recipe for conflict at IETF Last Call. We might as well start getting people
on the same page now. From my perspective, the right way to do that is
to start the discussion from where it last left off, even if that wasn't in
the same group. That tells people where the consensus of that group was
and informs the rest of the discussion.
Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains
to the SIP WG's expertise in knowing and agreeing with SIP's ability
to foresee the type of topology from UAC to UAS, and each server
(whether there even is one) in between. I'm not so sure the SIP WG
agrees that a UAC can make this determination, and am soliciting
their input here in a broad way.
Can a UAC understand enough about the topology of the Internet to
understand where it is sending a request, including how SIP servers
may or may not act upon that request?
I believe, if the answer is no, the the "recipient=" parameter is a
flawed SIP header parameter.
If the answer is yes, then it stays with no further arguments from me.
>
>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.
I look forward to your presentation.
The above question is what I'll propose to the SIP WG, nothing
more. If they ask for an example, I'll give them the Pizza Hut
example I did on this thread a few messages ago.
Further commments inline.
>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)?
You are making a big leap here. It doesn't have a UA understanding
of the topology;
it has User control over private information. The user gets to say
by whom his or
her location gets used; that's a core aspect of RFC 4119 and
friends, and you don't
get to reuse that work without getting that assumption built in. We've had
exceptions for emergency services (discussed in the ECRIT BCPs), but they're
not general. If a user does not want that private information used by the
SIP routing system but is willing to give it to the SIP entity
receiving the call,
the system has to provide a way of making that clear. We discussed several
ways to achieve that (including changes to 4119), and there was pretty
clear consensus on this way forward. The version with retransmission-allowed
or routing-query-allowed did not see support, nor did redefining
"retransmission=no"
to mean "except for SIP".
Yes, this does mean that a UA that sends a location object with
recipient=end-point
may have a call fail if location-based routing is absolutely
required; so will any
call not containing location, though, and the UA will have to be
able to handle
that case. It may very well be what is wanted, as we discussed in relation to
taxi services at some length (I may be willing to send my location to a local
taxi service so it can send the taxi, but not willing to send my location to
the sip-routing system so it can pick a taxi-service local to me).
>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.
Perhaps I don't see what you mean by "caller doesn't control" here. Can you
elaborate?
>
>>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.
And what does "view" mean here? If it understands it enough to know
how to use a pidf-lo object for location-based routing, it pretty much has
to understand it enough to know that it is not an intended recipient of
such a body, based on the header here and the pidf-lo internal rules.
If it doesn't understand pidf-lo, then "viewing" it means something like
"copying", "forwarding", or similar, no?
>I don't see the text giving an exemption in the emergency case,
not at least in this doc.
The exception is in the ECRIT documents, or was the last I checked
(sorry that I
have no time to confirm now).
>
>> >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.
I'm reluctant to suggest cross-posting, but I do believe that folks
commenting on
this should be aware of the discussion in the Geopriv group prior to
this. I continue
to recommend that folks review the geopriv archive, searching for the document
name, in order to get that context.
Note that deciding to ignore the privacy implications of geopriv's
framework is
simply going to create "confusion and delay", as my son's favorite railroad
director says, and if we actually hope to see this work we need to work within
the framework as much as we can.
regards,
Ted Hardie
>> 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
