RE: OBO (was - RE: [Geopriv] Message Flow, again)

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Nov 27 2007 - 17:11:21 EST

:) Sorry Tatham... Yes - it's On-behalf-of That is, the target isn't making the request itself; the client is making the request "on behalf of" the target. You can see that it was pretty inevitable this would be reduced to OBO if it got it to the universal maximum two syllable target... :) Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 28 November 2007 9:04 AM To: 'Tatham Oddie'; geopriv@ietf.org Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again) "On Behalf Of" > -----Original Message----- > From: Tatham Oddie [mailto:tatham@oddie.com.au] > Sent: Tuesday, November 27, 2007 4:47 PM > To: geopriv@ietf.org > Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again) > Importance: Low > > Um ... For those of us following along at home, can somebody throw in what > OBO stands for? It's not the most unique phrase the Google either. > > > Thanks, > > Tatham Oddie > call:+61414275989, call:+61280113982, skype:tathamoddie, > msn:tatham@oddie.com.au, tatham.oddie.com.au > > > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, 28 November 2007 8:37 AM > To: Marc Linsner; geopriv@ietf.org > Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again) > > Hi Marc, > > The scenario being discussed is an OBO and the need is well recognized. > How do you suggest formalizing the decision that OBO is a valid use > case? > > Once again, Marc, you are not talking about LbyR. Location by reference > involves asking the location server for a reference and then having the > actual location provided as the result of a subsequent dereference. The > scenario you are describing is just an LbyV request (in fact, an OBO > LbyV) with a parameterized URI. > > Cheers, > Martin > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 28 November 2007 1:05 AM > To: Dawson, Martin; geopriv@ietf.org > Subject: OBO (was - RE: [Geopriv] Message Flow, again) > > Martin, > > 1) I believe we need strong consensus that the IETF/Geopriv is going to > support OBO. I don't find or remember the wg agreeing on this, in fact, > I > remember the opposite. > > 2) I was simply trying to show how one might use an aberration of an > accepted mechanism, LbyR, to accomplish the function, saving the pain of > #1. > > -Marc- > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Monday, November 26, 2007 5:57 PM > > To: Marc Linsner; Thomson, Martin; geopriv@ietf.org > > Subject: RE: [Geopriv] Message Flow, again > > > > So - to cut to the chase - you're proposition is that no > > formal specification for performing OBO ever be defined; it > > should forever be informal and be left to mutual convention > > on a per-implementation basis? > > > > In which case, really, we just need to seek consensus on > > whether that is the preferred approach or whether there > > should be a formal specification? > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Tuesday, 27 November 2007 9:09 AM > > To: Thomson, Martin; geopriv@ietf.org > > Subject: RE: [Geopriv] Message Flow, again > > > > Martin, > > > > The omission of protocol is/was on purpose. > > > > -Marc- > > > > > > > > > > Actually Marc, I think that you are mistaking a URI for a location > > > reference. What you are talking about there is an OBO. > > > Alternatively, it's a yet-undefined protocol - that is, the > > protocol > > > indicated by an 'ip:' URI that yields location information. > > > > > > > -----Original Message----- > > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > > Sent: Tuesday, 27 November 2007 12:37 AM > > > > To: 'Hannes Tschofenig'; geopriv@ietf.org > > > > Subject: RE: [Geopriv] Message Flow, again > > > > > > > > Hannes, > > > > > > > > In-line.... > > > > > > > > ....snip...... > > > > > > > > > > > > > > Now, assume that a the proxy does location based > > routing and also > > > > > wants to allow the location recipient to obtain the location > > > > > information. The request contains the HELD identity extension > > > > > containing the IP address of UA sending the SIP INVITE message. > > > > > > > > > > It constructs a HELD request: > > > > > > > > > > <?xml version="1.0"?> > > > > > <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> > > > > > <locationType exact="true"> > > > > > any > > > > > locationURI > > > > > </locationType> > > > > > <heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> > > > > > <uri>ip:IPv4+192.0.2.5</uri> > > > > > </heldDevice> > > > > > </locationRequest> > > > > > > > > > > The LIS returns a response with a civic address and the LbyR. > > > > > > > > ....snip...... > > > > > > > > I'll ask the same question again. Why doesn't a LbyR dereference > > > > provide the same? > > > > > > > > Example: 'IPv4+192.0.2.5@accessprovider.net' > > > > > > > > -Marc- > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > immediately > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 27 Nov 2007 16:11:21 -0600

This archive was generated by hypermail 2.1.8 : Tue Nov 27 2007 - 17:11:31 EST