Subject: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement)

From: Dean Willis <[email-masked]>
Date: Tue, 16 Jun 2009 01:48:54 -0500

Poxies sometimes replace an incoming request-URI with another 
request-URI. I'll cal this operation a "Request-URI Replacement", or RUR 
for now. Note that this should not be confused with an RUS, or "Rodent 
of Unusal Size", which is an entirely different order of pest, although 
I understand that both are likely to carry the fleas that spread plague.

Some of our discussion threads (and drafts) seem to be bogged down on 
the "whys" and "what kind of URI was that" discussion. For example, was 
that RUR caused by an aliasing operation (replacement of one AOR with 
another) or a contact-routing operation (replacement of an AOR with a 
contact). We also have a "and WHY did we do this" discussion, that 
includes such potential excuses as "The previous number was busy", "the 
previous number forwrded to this number", "I found a registration that 
sort-of matched", and "The devil made me do it." This whole family of 
argument assumes that we have different kinds of URIs, different kinds 
of replacement operations, and different reasons for doing replacements. 
Further, it presumes that each of these sets of things is finite, 
bounded, and definable in a standardized, interoperable way, and that 
the proxy performing the RUR intimately understands the full gamut of 
possibilities and therefore ay encode the new URI, its type, and its 
causality in a universally standard way that will be understood by the UAS.

Although I've previously offered to model wherein RUR operations can be 
classified as "retargeting" vs "rerouting" based on the continuity of 
response-identity across the RUR (retargets change response identity, 
reroutes don't), I'm not sure I believe any of the other above 
presumptions about RUR discriminations to be demonstrably true. And I'm 
not sure we need them anyhow. I'm especially not sure that I believe 
that there is a finite and well-definable set of "why" operations that 
can be used to forward-explain all possible service logics.

But I am certain that there are use-cases for which a UAS supports 
multiple identities and needs to know which identity applies to a 
received request.

One approach is to assign each UAS a discrete URI for each identity. 
Then if an upstream proxy does an RUR, the UAS can work backwards from 
the resulting request-URI in order to figure out which identity is being 
targeted. This is exactly how we have always thought of a multi-user 
UAS, which typiclaly uses a set of URIs where the right-hand-side is the 
host name or address and the left-hand-side is the identity 
discriminator: for example "sip:[email-masked]" vs 
"sip:[email-masked]". or "sip:[email-masked]" vs. 
"sip:[email-masked]"

This model works nicely for lots of cases. For example, it can support 
proxies that do RUR based on configuration tables, dynamic registration, 
business policy matching, TRIP aggregation, etc. All it requires is that 
the UAS support multiple URIs and be able to distinguish between them.

Some people would argue that it 1) requires that each UAS be provisioned 
with the entire possible set of request-URIs, or that this would result 
in very large registration databases. Again, I'm not sure I completely 
buy this.

We could also encode the replaced URI into the new URI in a "You can 
throw this away if you don't understand it" sort of way by using a URI 
parameter appended to the r-URI resulting from the RUR.

For example,

A proxy receiving a request for "sip:[email-masked]" might replace 
that URI with "sip@[email-masked];rur=sip:[email-masked]"

If Alice's UAS (which she might share with Bob) understands the RUR 
header field encoded in the r-URI, it can make up its own mind about the 
translation type and how to render the request URI. A nesting syntax 
should allow quite elaborate constructions.

This approach simplifies proxy operation by taking the proxy out of the 
provisioning and translation loops as much as possible. The proxy 
doens't know whether a given RUR is a retarget or a reroute; all it 
knows is that the pre-RUR URI is appended to the post-RUR URI in a fixed 
manner. The UAS can, if it cares, deal with the implications.

So what else do we really need and understand well enough to quantify 
without arguing about it until the end of time?

--
Dean

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 08:27:36 -0500

Dean,

I do like the idea of using the URI parameter, but I've been
consistently outvoted on that one. 

I think with the latest proposal that Francois posted we capture three
things you identify:
1) why - this is how we'll tag the "old" hi-entry - i.e., the mechanism
by which the new URI was determined.
2) what kind of URI - that's how we'll tag the "new" hi-entry
3) why did we do this  - this is already covered by the reason header

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, June 16, 2009 1:49 AM
To: [email-masked]
Subject: [sipcore] Another approach to preservation of targeting
information on a proxy-rewrite of request URI (Request URI Replacement)

causality in a universally standard way that will be understood by the
UAS.

For example,

--
Dean

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Jun 2009 11:51:18 -0500

> 3) why did we do this  - this is already covered by the reason header

I believe there are instances of 1, 2, and 3 that don't exist in the
current draft, possibly because we  haven't invented them yet. We will
be extending this thing forever.

But do properly constructed applications really need this information
encoded in this way? I have always held that they do not; this is yet
another holdover of PSTN call processing logic, and we do ourselves and
the Internet a disservice by perpetuating it.

For specific applications in which the proxy has the relevant
information and for which the UAS has a need for this information, the
rewritten request URI allows us to encode the information from proxy to
UAS without any particular need for standardization. It's arguable as to
whether previous-Request-URI encoding even needs standardization,
although doing so is fairly straightforward.

In other words, History-Info, despite being a clever solution, is
solving the wrong problem and thereby encouraging PSTN-style processing
logic. Yes, we have some general consensus to go that way, but it's
still not an approach I like. We also had general consensus to do a lot
of other PSTN-like things, including early media, reliable provisional
preconditions, etc. almost all of which have turned out to be
implementation and functionality nightmares because they assume an
entirely different operating environment from the Internet. We should
really try to learn from our mistakes.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 13:17:59 -0400

> although doing so is fairly straightforward.

While I like the approach, I think you are over-promising.
It still *does* require standardization:
- the rur parameter would need to be standardized
- that would include when it should be used, and what it
   means if its found in a request you receive.

And then I suppose people would want different parameters to express 
nuances about why the rur url is there.

And it would run up against implementations that can't handle long 
R-URIs. (I don't have much sympathy for them, but they continue to exist.)

Aside from syntax, this is basically just a subset of H-I. But it can 
only encode one path through the tree - 1, 1.1, 1.1.1, ... (Or course 
that is usually the path you care about.)

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 12:24:32 -0500

Dean,

We definitely do not want to extend this forever, which is why the
proposed solution is to completely tag the things now - the 1), which is
actually what we are tagging the new with (I was backwards in my initial
response), is based upon the mechanisms that are currently described in
RFC 3261 in terms of how the new target(s) for the request are
determined.  

The 2) is also not so far from core SIP - we're tagging that the entry
is an aor for the intended recipient user - we know that because we know
how the Proxy handles that incoming request URI - i.e., it belongs to
the domain and the proxy can use a variety of mechanisms to determine
the new Request URI (per the mechanism tag).   

What these tags mean in terms of the end application is out of scope for
4244bis, but would be described in the target-uri document (IF we agree
to the approach - right now both docs have solution proposals).  But,
yes, we are providing the enabler for (ugly) PSTNish applications and
that was the primary reason why there was so much opposition to
History-Info in the first place eons ago. 

Now, I fully agree that the fact that not all of the URIs are of the
form user@domain makes things ugly, but that's an ugliness we are living
with across the board and a fact of (network) life for a while - and
yes, the model is not Internet - this 800 junk and any of the phone
numbers in the URIs and the handling thereof is modeled after the
translations done by PSTN switches.  And, I would absolutely love to be
able to say that the 800 number MUST be converted at the gateway to a
user@domain form with whatever URI parameters are necessary for an end
application to map it to these PSTNish features.  But, I don't think
I'll win that battle, although I do agree it makes things very ugly and
hacky. 

I really, really think this sort of debate would make a great Dr. Phil
show. I can try to arrange something for LA next March - I have some
local connections ;)

Mary. 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 11:51 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: [sipcore] Another approach to preservation of targeting

> things you identify:
> 1) why - this is how we'll tag the "old" hi-entry - i.e., the 
> mechanism by which the new URI was determined.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Jun 2009 15:04:03 -0500

>   means if its found in a request you receive.

As I said, that's arguable; there are presentable reasons for and against.

> nuances about why the rur url is there.

Locally-relevant nuances, I believe, are only locally relevant. I don't
see a strong argument for standardized nuance.

> R-URIs. (I don't have much sympathy for them, but they continue to exist.)

One could trivially express it as a header field that is not formatted
as part of the r-URI.

> that is usually the path you care about.)

Further, that's the only subset required to convey any request-URI
parameters that are relevant to the request as received by the UAS. It
allows for UAC-initiated parameters, as well as the addition or
alteration of parameters by middleboxes. However, it does lack message
integrity, so middleboxes could muddle the parameters. Note that this is
required for a certain range of applications (e2m, anonymizers, etc.),
so it isn't necessarily a bad thing.

In other words, it completely satisfies the "What are the request-URI
parameters" question that was our original requirement for the work.

While I concede that H-I is useful for debugging, it is massive overkill
for parameter passing.

Think of it as grilling a chicken using a plasma torch.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 22:29:39 +0200

Dean,

Isn't your idea more or less what the Target header proposal was all
about? 

Again, we had a long discussion on Target header vs ua-loose-route, and
at some point the people behind the drafts agreed on a HI based
approach. That approach was presented to the WG, which agreed to work on
that. 

So, until the WG decides to re-evaluate that decission (you are free to
propose that), I think we should stick to it.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, June 16, 2009 11:04 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [sipcore] Another approach to preservation of targeting
information on a proxy-rewrite of request URI (Request URI Replacement)

>   means if its found in a request you receive.

As I said, that's arguable; there are presentable reasons for and
against.

--
Dean