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

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Tue May 08 2007 - 21:35:08 EDT

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.

>
>> That said, I think a use-this-for-routing tag might actually be
>> useful for a slightly different reason, based on the multiple-
>> location case you mention. The reason it needs to be a header is
>> simple, namely location by reference. You really don't want the
>> proxy to attempt to resolve a reference and then find that the
>> answer is "sorry, not for you". That just adds delay and complexity.
>>
>
> If splitting the current header into two headers can get us to
> group consensus, I'm
> all for it. As I said in my previous message, there are cases
> where you might give
> different locations to the routing infrastructure and the end user
> so there are additional
> justifications here.
>
> To be clear this would eliminate "routing-query-allowed", add a
> header and update
> at least this language:
>
> A proxy MAY read the Geolocation header, and the associated body, if
> not S/MIME protected, in transit if present, and MAY use the
> contents of the header to make location-based routing decisions.
>
> to something like:
>
> 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?

In general, there are also two error cases to consider:

- What if there's no ;route indicator? Does the call have to fail in
all circumstances?

We'll probably disagree on this score.

- What if there are two or more?

I'm guessing the proxy gets to pick.

>
> We would also need to add advice for proxies adding location (for
> which header
> to add it to).

These aren't really different headers. I'm guessing what you mean is
something like this:

Geolocation: cid:something ;route, http://foo.bar

>
> 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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 8 May 2007 21:35:08 -0400

This archive was generated by hypermail 2.1.8 : Tue May 08 2007 - 21:35:20 EDT