Re: R: [Sip] a question about IETF draft location conveyance 09

["James M. Polk" <[e-mail]>]

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:[e-mail]
>>-----------------------------
>>
>>
>>-----Messaggio originale-----
>>Da: Ted Hardie [mailto:[e-mail]]
>>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 [e-mail] for questions on current sip
>>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip