Re: [Geopriv] Suggested text for Section 3.6 of draft-ietf-geopriv-lo-retransmission

From: James M. Polk ^lt;>
Date: Wed Nov 19 2008 - 16:48:36 EST

At 01:54 PM 11/18/2008, Rosen, Brian wrote:
><note that in the following I use lower case "must". It's advice, we
>cannot use MUST. I think it's acceptable to be strong and use "must",
>rather than weasel-wording "any SIP document should consider
>Back-to-back user agent behavior is often difficult to proscribe. There
>are many uses of B2BUAs and the rules that apply would depend on the
>actual use case. This section suggests what any SIP mechanism arising
>from this document might wish to consider with regard to B2BUA behavior.
>In most uses of B2BUAs, it is a simple intermediary between the nominal
>originating and nominal terminating UAs, that is, a proxy that does
>something proxies aren't allowed to do. In such cases, the B2BUA must
>conform to any new routing-allowed mechanism if it chooses an outgoing
>route. As this document advises proxies, <retransmission-allowed> does
>not apply and the B2BUA must copy the LI, the new routing-allowed and
>existing <retransmission-allowed> values.
>Where the B2BUA in fact does terminate the session, and originate
>another session, <retransmission-allowed> applies to it, and it must not
>copy location if <retransmission-allowed> is "no".

I firmly/strongly/(whatever) do not agree with this use of MUST NOT
(capitalized or not). B2BUAs by definition terminate sessions - so
there is no wiggle room here. But this is *not* the behavior we want
B2BUAs to adhere to here. We want B2BUAs to act like proxies as much
as is possible when copying ruleholder policies downstream (only!),
and yet follow what these policies mean regarding transmitting the
received location to any other parties/entities.

> If it chooses a route
>for the outgoing leg, any new routing-allowed mechanism applies to it.
>Encryption provides additional control to the originator on who is
>allowed to see location including B2BUAs. On the other hand, using
>encryption with LI which is needed for routing is problematic in that it
>is often difficult to know in advance which elements do location based
>routing. Similarly, using location-by-reference instead of
>location-by-value provides additional control to the originator over
>B2BUA behavior by controlling who can dereference. The same limitation
>for routing applies.
>Geopriv mailing list

Geopriv mailing list
Received on Wed, 19 Nov 2008 15:48:36 -0600

This archive was generated by hypermail 2.1.8 : Wed Nov 19 2008 - 16:48:50 EST