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

From: Ted Hardie ^lt;>
Date: Wed May 09 2007 - 00:47:24 EDT

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?

Geopriv mailing list
Received on Tue, 8 May 2007 21:47:24 -0700

This archive was generated by hypermail 2.1.8 : Wed May 09 2007 - 00:47:46 EDT