RE: [Geopriv] Location in SIP and "retransmission-allowed"

From: Winterbottom, James ^lt;>
Date: Wed May 09 2007 - 01:46:45 EDT

*Ding Dong* I will chime in to the effect that I think the wording in 4119 is very clear on this and that I side with Richard and Ted. On how we solve it I don't have that strong opinion on whether we change 4119 (I think that 4119 could use some other changes too), or we introduce a new header I am agnostic. But I don't think that the current wording in 4119 allows querying of a LoST server by a proxy. Cheers James > -----Original Message----- > From: Ted Hardie [] > Sent: Wednesday, 9 May 2007 2:47 PM > To: Henning Schulzrinne > Cc: 'GEOPRIV'; Marc Linsner > Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed" > > At 9:35 PM -0400 5/8/07, Henning Schulzrinne wrote: > >On May 8, 2007, at 4:36 PM, Ted Hardie wrote: > > > >> > >>And here's the crux of the disagreement; you believe that this > distinction > >>doesn't matter, but I believe (and I think at least Richard believes) > that it does. > >>I also think that it makes a predication about future use cases that is > not > >>justified or justifiable. > >> > > > >Nobody can predict the future, but engineering based on something that we > can't define and have no current use cases seems like a strange way to > define a protocol where we expect to have interoperable and predictable > implementations. The likelihood that we'll get it right in that case is > pretty slim. > > Henning, the fact that you don't believe in the use cases I've put forward > is fine. > People are bound to disagree. But you are predicting the future by saying > that > there never will be a case where it is important for the end user to pass > location > to the end recipient with this header but disallow routing based on it. > > That's a reach. Engineering to allow for it now is trivial; preventing it > now and > re-introducing later is a pita. > > >> > >> A proxy MAY read the Routing-location header and the associated body > and > >> MAY use the contents of the header to make location-based routing > decisions. > >> A proxy SHOULD NOT read the Recipient-location header and its > associated body > >> for the purpose of making location-based routing decisions. > > > >My general pet peeve is that no document should have a SHOULD without > defining when the condition is not met. How would an implementor know? > > I was thinking only emergency service got to ignore the SHOULD, but if you > want > to make it MUST and let emergency services violate that, I'm fine with > that too. > > > > >These aren't really different headers. I'm guessing what you mean is > something like this: > > > >Geolocation: cid:something ;route, > > No, I really meant separating it into two different headers. You could > do it with two Geolocation headers and an indicator of which use case > it is for; frankly, that's a syntax choice about which I don't care a lot. > The semantic of separating the two use cases is what I assumed was > moving us forward. > > > > > >> > >>It's a non-trivial change, but that path forward works, at least in my > opinion. > >> > >>How do other folks feel about making a change like this? > >> > >> Ted > > Again, can I ask other folks to chime in here? Anyone else have strong > views on this path forward? > Ted > > _______________________________________________ > Geopriv mailing list > > ------------------------------------------------------------------------------------------------ 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
Received on Wed, 9 May 2007 00:46:45 -0500

This archive was generated by hypermail 2.1.8 : Wed May 09 2007 - 01:46:56 EDT