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

From: Henning Schulzrinne ^lt;>
Date: Wed May 09 2007 - 13:35:01 EDT

On May 9, 2007, at 10:42 AM, Richard Barnes wrote:

> Henning,
> I agree that it's simpler to tag individual locations within a
> Geolocation header, although I would do it a little differently
> (echoing inserted-by),
> Geolocation: <>;recipient=server,
> <>;recipient=endpoint
> ... with the stipulation that if it's marked for one recipient,
> then the other SHOULD NOT read/use it.

That seems longer (bad for mobile systems) and has the disadvantage I
mentioned earlier: for the common case of one location, there will be
two URLs, both the same. This would yield

Geolocation: uri --> single URI, use for end system
Geolocation: uri;routable -> routing or end system
Geolocation: uri1;routable, uri2 -> uri1 for routing (and end
system), uri2 for end system

> 1. What is the concrete exception to the SHOULD?
> I can't think of any outside the emergency case. Perhaps it should
> be a MUST, to be overridden by phonebcp (or any other application-
> specific documents).

Since it's a normative change, then the phone-bcp would have to be an
'Update for RFC LocationConveyance'. Seems a bit strange, but
obviously can be done. (You can't just say MUST and then have random
unidentified documents make changes in normative language.)

> 2. What if there's no ;route (;recipient=server) indicator?
> This could be handled as the routing-query-allowed value is handled
> in location-conveyance: If it's not present, then then the value of
> the retransmission-allowed element takes over (and that's default-
> deny if not present). However, I could probably also be persuaded
> that inclusion in a Geolocation header indicates consent, unless de-
> authorized by ;recipient=endpoint.

In general, it seems to make sense to have the common option be the
shorter one. SIP messages are already more than long enough.

> 3. What if there are two or more?
> Yeah, like you say, proxy can pick. As with other multiple-
> location issues, we probably want to say "don't put this in". And
> if we say that no tag means consent, then tagged might be preferred
> over not-tagged.
> In any case, these approaches seem appealing because they uses SIP
> markings (headers, URI parameters) for SIP semantics (routing
> permission). However, by using information in headers, you
> potentially expose it to messing around by proxies. So you would
> need to say that a proxy MUST NOT modify the value of any existing
> "recipient" parameter, or its presence or absence on any given URI.

Evil proxies will presumably happily ignore the don't-touch-that-body

> With that caveat, though, this seems like a decent compromise.
> --Richard

Geopriv mailing list
Received on Wed, 9 May 2007 13:35:01 -0400

This archive was generated by hypermail 2.1.8 : Wed May 09 2007 - 13:33:32 EDT