Re: [Geopriv] Next steps on -retransmission- (was Re:draft-polk-geopriv-sip-lo-retrans-rec-concerns)

From: Richard Barnes ^lt;>
Date: Wed Nov 05 2008 - 19:25:59 EST

Hey James,

>>> 1) An objection to the way the draft uses authorized recipient while
>>> describing retransmission recommendations.
>> As James's draft notes, S3.2 of -retransmission- note that there is
>> consensus that by sending a SIP message with location in it, a UAC
>> authorizes SIP entities along the path that message will take to
>> access the location in that message. So it seems to me entirely
>> appropriate for SIP entities on the path to be referred to as
>> "authorized recipients".
> part of what I'm getting to is the difference between "authorized
> recipients" in signaling path and freely sending the Location Target's
> LI to every other node on the Internet.


I think we're in violent agreement (with the document, even) on the use
of "authorized recipient".

The disagreement seems to be where the "signaling path" ends -- at the
"ultimate" UAS, or at the "UAS side" of a B2BUA. The retransmission
document takes the former approach, your document (and my argument
below) the latter.

So I'd like to claim that this issue is subsumed by Issue 3.

>>> 2) An objection to the recommendation of a new header preferring a
>>> different syntactic representation.
>> The current draft is contradictory here: It claims to be proposing
>> only an example syntax, but refers to that syntax elsewhere (e.g.,
>> Section 3.6, "failing to copy any "Location-Routing-Allowed" header
>> value").
>> The critical thing here is the proposal for a
>> "Location-Routing-Allowed" *indicator* semantic
> I'm not resisting an *indicator*, I'm resisting the
> "mandatory-to-implement" new SIP header idea.

For clarity, which are you objecting to?
(A) Suggesting the use of a SIP header, or
(B) Making it mandatory to implement.

If it's (A), then I think there's not an issue here, since there are a
few proposals to remove or further minimize the text that suggests a
specific syntax.

If it's (B), then there's a question of scope. You might be able to
argue (but would still need to argue it) that it's not mandatory for
every SIP entity to understand the privacy indicator. However, it has
to be mandatory for some class of SIP entities. It would clearly make
sense for this indicator to be understood by any SIP entity that
implements -location-conveyance-.

>>> 3) An objection to what James feels will be interpreted as
>>> requirements placed on B2BUAs around forwarding location information.
>> The argument that someone walking in off the street might interpret
>> Section 3.6 as normative is bogus. No matter what you write, there's
>> a risk that your text will be interpreted as normative by someone who
>> doesn't know how to distinguish normative from non-normative text.
> I believe you (and others) woefully underestimate the number of folks
> that doesn't understand the difference between informational and
> standards-track when reading a doc.

Ok, still, I think the text does as much as possible to minimize the
probability that it will be mis-interpreted.

That said, given that we (you and I) have agreed on the more lenient
text below, do you think that that's an acceptable risk? I.e., if
someone interprets the guidance as normative, it's not going to be too bad?

Revised text below, including your mods, and some editorial fixes of my
own. W.r.t. LI/LO, changed to "location information (by value or by
If both sides of a B2BUA speak SIP, then the B2BUA is simply another SIP
entity in the routing of the SIP message. Thus, the B2BUA and any
subsequent SIP entities in the signaling path are authorized recipients
of any LI included in a SIP message that the B2BUA receives. In this
case, when a B2BUA receives and processes a SIP message that contains
location information (by value or by reference), it MAY enclose that LI
in the corresponding outbound SIP message. However, if the inbound
message includes a "Location-Routing-Allowed" indicator, the outbound
message MUST include the indicator as well, with the same value as the
inbound message. This ensures that all authorized recipient (before and
after the B2BUA) are informed of the policies of the Rule Maker.

Geopriv mailing list
Received on Wed, 05 Nov 2008 19:25:59 -0500

This archive was generated by hypermail 2.1.8 : Wed Nov 05 2008 - 19:26:24 EST