James,
I have not been following this discussion closely, so apologies if this
comment doesn't make sense...
It seems like a key issue is understanding *who* will need location
information for routing purposes, and how it is that they would know
that they should do so.
I don't think a UAC will be inserting location information in every
call, so it must have some way of knowing that it will be needed for
some purpose. Has there been any discussion of that? (If I just dial the
number for Pizza Hut, my phone won't know. Either I must press some
special button that says to include location, or else there must a
response from downstream to the first request indicating that location
is needed. If the specification of "recipient" must be included, then
that error response will need to indicate the desired purpose. And then
the UAC will still have to decide if it is ok to include this.
Next, lets take the Pizza Hut case. If I am calling
sip:[EMAIL PROTECTED], then to me pizzahut.com *is* target
destination. It is probably not difficult for me to decide if I want to
give pizzahut my location or not. And it is probably irrelevant to me
whether it is so that the closest branch can be selected for routing, or
if it is so the pizza can be delivered to me. *If* Pizza Hut wants to do
routing based on location of caller then it will be done at or
downstream from pizzahut.com.
The significance of recipient=routing-entity only seems to make sense if
it is used for routing *before* reaching pizzahut.com. But I don't see
that as a very valid or plausible use case - at best it is meddling by
SPs that IMO they ought not be doing.
Perhaps that is more significant and valid if the destination is a
service URN - e.g. urn:service:pizza. The translation from from a
service urn to a URI might be a valid reason to use location
information, and might be done by any routing entity. Its also
predictable by the UAC that location might be needed for this.
But maybe that isn't a real distinction. With the URN, in effect any
node on the route can decide to take on the role of translating the URN.
If it does, then it is in effect the intended recipient of the request.
I don't have a clear suggestion here, but IMO the distinction among
categories of users of location information seems not quite right.
Thanks,
Paul
James M. Polk wrote:
At 11:35 AM 11/22/2007, Hannes Tschofenig wrote:
Hi Daniel,
daniel grotti wrote:
I believe that if a UA puts "recipient=routing-entity" paramenter
into locationValue, the location information should be read only by
Proxy Server for location-based routing. But if a UA wants its own
location information to be known and seen by endusers, then UA have
to insert the "recipient=endpoints" paramenter. In this case Proxy
server, from my view, should only forward the message to the
destination. UA would just like to bring its own location to an
endpoint, and could not interested in location-based routing.
Does this make sense?
Correct and makes sense.
The recipient parameter is just a hint for processing.
Ted's tone doesn't indicate this is "just a hint", he's making this seem
like a mandatory prevention mechanism. That I think is a fool's errand,
and it is not enforceable in cleartext.
That said, "hinting" that proxies SHOULD NOT view location when
"recipient=endpoint" is not a problem. What I am resisting, is that
UA's don't know if a message might need location to route the message to
the endpoint. Contacting a UAS, like Pizza Hut, might need location to
route the message to the nearest store, the user might know this, but
the UA might not. This would result in a rejection of the initial
message (because location isn't readable by a proxy that needs the
location-info). Would the UA understand that the rejection means sent
"recipient=both" in a subsequent request? Or does the implementation of
that UAC need to prompt the user to acknowledge this is necessary to
complete the call set-up? This seems to me to be complicated and
against normal user behavior, and I'm thinking about whether or not this
is being expected to become normal user behavior? I think this might be
preventing calls to any store/service that implements a network routing
plan based on the UAC knowing where it is to route the call to the right
destination. I cannot understand how this would be differentiated by users.
It does not have security properties.
I agree
Ciao
Hannes
Regards,
Daniel
-----------------------------
Daniel Grotti
DEIS - Universita' di Bologna
-----------------------------
Via Venezia, 52
47023 Cesena (FC) - ITALY
-----------------------------
email:[EMAIL PROTECTED]
-----------------------------
-----Messaggio originale-----
Da: Ted Hardie [mailto:[EMAIL PROTECTED]
Inviato: gio 11/22/2007 12:36
A: James M. Polk; daniel grotti; IETF SIP List
Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
At 4:18 PM -0600 11/21/07, James M. Polk wrote:
\
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 think we have fundamentally different ideas of how much
understanding of the
topology this implies. My view is that the header as currently
specified says
either "This is meant for the person answering the call/taking the
session" or
"This is meant to help get the call through/get the session to the
right responder".
Within the latter case, it requires no knowledge at all of topology;
it does
not distinguish among the many different routing elements which might be
trying to make that happen.
A UA that does not care whether it is used for routing can enter "both"
and all is well. A UA that *wants* it to be used this way can enter
"routing-entity".
The availability of "endpoint" as a separate possibility makes sure that
an endpoint can indicate that use by the routing system is not
intended. If the SIP community believes "routing-entity" is too vague
and needs to be broken out, I do not see how the GeoPRIV could object or
why it would want to; certainly this working group should have the
final word
on that. But collapsing things so that entering "endpoint" is
not an indicator to the routing entities that they should just pass
things along
would find opposition (at the very least from me). That would break
a pretty
fundamental assumption that users are in control of the pidf-lo
distributions.
Hope you have a great Thanksgiving,
Ted
_______________________________________________
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
