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

From: "James M. Polk" <[email-masked]>
Date: Sun, 02 Dec 2007 03:32:00 -0600

At 01:27 PM 11/22/2007, Hannes Tschofenig wrote:
>RFC 2119 language aims to accomplish interoperability.
>The MUST NOT in that sentence does not accomplish interoperability.

which is one of my main points

>It does not do harm for the proxy to still read it.

I'm sure not everyone agrees with this

>I would be fine with a sentence that indicates that it is not useful 
>for the proxy to read the location information if the recipient 
>parameter is set to "endpoint".

I have no problems writing this into the doc, if this is agreeable. 
Should something like, "and a LbyR URI (MUST NOT/SHOULD NOT) to be 
dereferenced"

>Ciao
>Hannes
>
>
>daniel grotti wrote:
>>Hi all,
>>so why don't emphasize this point in the next draft, saying : 
>>"Proxy server MUST not read messages with "recipient=endpoint" 
>>paramenter setted".
>>This is my point of you.
>>
>>What do you think? James?
>>
>>Regards,
>>Daniel
>>
>>----------------------------------
>>        Daniel  Grotti
>>D.E.I.S. - University of Bologna
>>----------------------------------
>>        Via Venezia, 52
>>   47023 Cesena (FC) - ITALY
>>----------------------------------
>>e-mail: [email-masked]
>>----------------------------------
>>
>>
>>-----Messaggio originale-----
>>Da: Hannes Tschofenig [mailto:[email-masked]]
>>Inviato: gio 22/11/2007 18.35
>>A: daniel grotti
>>Cc: Ted Hardie; James M. Polk; IETF SIP List
>>Oggetto: Re: R: [Sip] a question about IETF draft location conveyance 09
>>
>>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. It does not 
>>have security properties.
>>
>>Ciao
>>Hannes
>>
>>
>>
>>
>>>Regards,
>>>Daniel
>>>
>>>
>>>
>>>
>>>-----------------------------
>>>        Daniel  Grotti
>>>DEIS - Universita' di Bologna
>>>-----------------------------
>>>        Via Venezia, 52
>>>   47023 Cesena (FC) - ITALY
>>>-----------------------------
>>>email:[email-masked]
>>>-----------------------------
>>>
>>>
>>>-----Messaggio originale-----
>>>Da: Ted Hardie [mailto:[email-masked]]
>>>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-masked] for questions on current sip
>>>Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 02 Dec 2007 02:58:40 -0600

At 11:35 AM 11/22/2007, Hannes Tschofenig wrote:
>>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 
>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

>>>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.
>>>
>>why it would want to; certainly this working group should have the final word
>>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

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 02 Dec 2007 02:41:35 -0600

At 05:36 PM 11/21/2007, Ted Hardie wrote:
> understand where it is sending a request, including how SIP servers 
> may or may not act upon that request?
> >
>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
>and all is well.  A UA that *wants* it to be used this way can enter 
>"routing-entity".
>an endpoint can indicate that use by the routing system is not intended.

I think this is what we disagree about.  Aside the emergency 
scenario, it is there types of requests that I find it a little hard 
to believe a UA will know that a "routing-entity" will not be needed 
to get the message to the ultimate UAS. How can the UA logic know 
that when calling Pizza Hut or a specific verses nearest garage needs 
to have location used or not?

This almost makes a practical use of this parameter (and this 
RFC(to-be) to RECOMMENDED that "recipient=both" is the default unless 
the UAC _knows_ it doesn't want a server ("routing-entity") to view 
the location.

>If the SIP community believes "routing-entity" is too vague
>fundamental assumption that users are in control of the pidf-lo distributions.
>

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 02 Dec 2007 02:41:35 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Dec 2007 11:30:19 -0500

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-masked], 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:
> 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.
> 
> 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.
> 
>>>> 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.
>>>>
>>>> I believe, if the answer is no, the the "recipient=" parameter is a 
>>>> flawed SIP header parameter.
>>>>