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

From: Rosen, Brian ^lt;Brian.Rosen@neustar.biz>
Date: Tue Nov 18 2008 - 14:54:13 EST

<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
compelling...">

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". 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@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 18 Nov 2008 14:54:13 -0500

This archive was generated by hypermail 2.1.8 : Tue Nov 18 2008 - 14:54:41 EST