Subject: Compatibility (was: RE: [Sip] bis-07.9: proxies are not allowed t o modify message body)

From: "Mark Watson"<[email-masked]>
Date: Tue, 26 Feb 2002 19:40:14 -0000

There is an underlying issue here about the compatibility mechanism in SIP,
which Pete touches on below.

Many of the arguments about proxy modifying SDP breaking things seem to
revolve around Require:

The assumption in (Proxy-)Require: is that all new extensions will fall into
one of the following categories:
(i) extensions which can be freely ignored and silently dropped (no
'(Proxy-)Require')
(ii) extensions where support is required at endpoints only ('Require:')
(iii) extensions where support is required at all proxies ('Proxy-require:')
(iv) extensions where support is required at all elements (both)

On the basis that all elements in the system are either proxies or
endpoints, I think this assumption is valid for completely new protocol
elements (e.g. new Headers with semantics independent of existing headers).

But it is not valid for extensions to existing protocol elements. Suppose an
element X already exists and I define an extension to this. This extension
could be in one of the above classes, or it could be

(v) extensions to existing element X, which can be freely ignored by
elements which do not process X, but which MUST be understood by (proxies
and/or endpoints) which do process X

[Actually, this is really 3 classes because of the 'and/or']
[[By 'process' I mean interpret and/or modify]]

SIP has no way of indicating that an extension is of this type.

The absence of (v) in SIP has led us to make unchangable assumptions about
which entities process existing elements in the protocol. If we assume that
X is *only and always* processed by endpoints, then case (v) is equal to
(ii) and we have no deficiency in the compatibility rules. Only if we make
such assumptions does the compatibility mechanism allow us to make
extensions to X.

Now, this is not a big problem when X is a particular header. The semantics
and scope of a given header are (hopefully) well defined and in many cases
it is quite clear that 'such and such a header is always and only processed
by endpoints' (*), or all elements etc.

The problem arises when we have a large protocol element with no pre-defined
semantics and much scope for extension. 

So, when X=Message Body, there is pressure to require that X cannot be
processed by proxies. But people have used Message Bodies for things which
other people think should be processed by proxies (e.g. SDP).

If we had a compatibility mechanism which could express (v), we would not
need to make any such limiting assumptions and the problem would go away.

Instead, the solution proposed is that the devices which want to process
message bodies must classify themselves as endpoints (for the purposes of
compatibility) when manifestly they are not. But now all our assumptions (*)
about 'such and such a header is always and only processed by endpoints' are
wrong, because we have an 'endpoint' device which does not process most of
these headers. Despite this, this device is required to recognise 'Require:'
tags for extentions it would otherwise have no dealings with (e.g. 100rel),
and even worse, it will choke on future extensions which have been designed
to operate transparently between endpoints.

This all seems rather backwards.

IMHO, addressing the problem of compatibility for extensible protocol
elements, would avoid this rat-hole.

...Mark

> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> Sent: 26 February 2002 11:02
> To: Adam Roach
> Cc: [email-masked]
> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message
> body
> 
> 
> ----- Original Message -----
> From: Adam Roach <[email-masked]>
> 
> > We're getting a bit far off into a meta-discussion here, but I feel
> > compelled to rebut some of your contentions.
> >
> > > -----Original Message-----
> > > From: Pete Cordell [mailto:[email-masked]]
> > > For me the main concern about a back to back UAS / UAC 
> implementation
> > > (perhaps with the two instances joined by something other
> > > than SIP) is tha
> > > they lose feature transparency.  It's the loss of feature
> > > transparency that
> > > is the problem, not that it is a B2BUA.  There are many
> > > devices that are not
> > > pure proxies that do not lose feature transparency
> >
> > They can have feature transparancy *for* *certain* *features*.
> > One of the reasons that "proxy" is defined to be such a narrow
> > term is to allow the protocol to evolve without destroying the
> > functionality of nodes in the middle of the network. For example,
> > let's take the imaginary (if somewhat contrived) extension
> > "ip-reversed," which indicates that IP addresses in the SDP
> > will be in reversed order. Now, you have something you claim
> > to be a proxy in the middle of the network, except it
> > helpfully attempts to tweak the SDP if it thinks I'm coming
> > through a NAT. It thinks it's a proxy, so it doesn't feel
> > bound to obey the "Require: ip-reversed" header present in
> > the message.
> >
> > Boom.
> >
> > This thing, no matter how similar it is to a proxy, has just broken
> > the network by doing something that proxies are "not 
> supposed to do."
> >
> > In order to perform this sort of processing in a way that will work
> > into the future, any node that does something that proxies aren't
> > allowed to do MUST pay attention to the "Require" headers. I don't
> > really care about the semantics of what you end up calling these
> > things, as long as you don't confuse the issue by calling them
> > "proxies."
> >
> 
> Would you prefer that you pushed me into producing a full 
> B2BUA and I bumped
> you because you had a Require: header in there?  Would you be 
> happy when you
> called in to complain when I say "I would liked to have been 
> as transparent
> to your service as I could, but the standard forced me to reject your
> transaction." ?  It wouldn't make me feel a whole lot better.
> 
> And why don't I ring you up and say 'your new service broke 
> my proxy'.....
> 
> This is a protocol design issue and not fundamentally an issue
> about modifying bodies.  For example, you could easily have defined
> Body-Require:, or you could say that if the body no longer 
> means what it
> used to mean, then give it a new Content-Type, e.g. Content-Type:
> application/really-cool-sdp.  Or define: Content-Type:
> application/sdp-with-requires; require=really-cool.
> 
> Actually this is an excellent example of why we should be 
> honest about what
> is going to happen in the real world and say that proxies can 
> change bodies.
> If we don't, then people will design services that will break 
> the system,
> and that helps no one.
> 
> > > Thus people are trying to build innovative products
> > > delivering exciting
> > > services beyond simple call routing, that are good netizens,
> > > but they are
> > > getting tarred as bad implementations by people that have
> > > never seen them
> > > simply because they are not pure proxies.
> >
> > They're not bad implementations. They *are* throttles to effective
> > deployment of new services, since they must process, honor, and
> > understand everything that comes by in a "Require" header. For
> > example, if I and one of my friends got the newest, spiffiest
> > terminals that had a *really* *cool* service -- one that necessarily
> > used a "Require" header -- but one of the nodes that my call was
> > routed thorough didn't support it, I promise you'd have me calling
> > customer service to figure out why my new $800 phone didn't work
> > as advertised. And you can be *darn* sure that I'd be pissed --
> > probably even pissed enough to go shopping for a new provider --
> > when I found out it's because you have a node in your network
> > blocking my spiffy service, and that it'll take several months to
> > a year for you to get an upgrade in place.
> >
> 
> Why should your potentially system breaking service be good, while my
> service is bad.  A good protocol should accommodate both 
> service types.
> 
> (BTW - Surely you paid too much for your phone.  Does it do 
> ISDN also ?!)
> 
> > Is this an intentional smear campaign? No; it's just a statement
> > of the ramifications of nodes pretending to be proxies doing
> > things that proxies are not "supposed" to do.
> 
> But the protocol designers say what a proxy should do.  I'm 
> saying that the
> current situation is not good for the long term.  Between 
> what the standard
> says now, and what people want to do with it, the SIP infrastructure
> will be broken.
> 
> > Are such impacts
> > negative? It depends on whether you want to anger your end users;
> > most people would say yes. But I've been the customer to uncountable
> > companies who have taken the decision to piss of their customers
> > (presumably) for some sort of trade off. It really comes down
> > to a business decision.
> >
> > > After all, wasn't the promise of SIP that it could offer lots
> > > of exciting
> > > new services? Now an intermediary device can only do what I
> > > can already do
> > > on my domestic phone line.
> >
> > Of course, exciting services can *only* come from the *middle* of
> > the network. I can't beleive that, until now, I had considered the
> > possibility that the *endpoints* could provide nifty services.
> > How naive of me (and the others who have been working on SIP for
> > the past four years) to think that the web model of providing
> > services might actually work.
> 
> Typical crap that I would expect from some IETF members: if 
> in trouble -
> manipulate words and flame.
> 
> Calm down and consider the following - where did I say that 
> ALL services had
> to be delivered from the middle.  That's correct, no where.  
> Many services
> will be delivered by end-systems.  BUT many services will hopefully be
> delivered by middle systems also.  Hopefully it's not too much of a
> revelation to you that some services fit better in the 
> end-systems and some
> fit better in the middle.  Blimey, some can even work in both 
> locations !!!!
> 
> Or are you saying that you KNOW for a fact that the routing 
> that proxies
> provide is the only service that can be delivered in the middle?
> 
> ... cut rest as duplicated stuff already covered ...
> 
> >
> > /a
> 
> This is getting us no where.  I have raised the issue that 
> services in the
> middle would like to change bodies.  A number of e-mails in 
> this discussion
> have confirmed this view.  I also pointed out that a number of these
> services are not implemented as full B2BUAs as defined in the 
> standard.
> This e-mail demonstrates that there is a real issue if people 
> are not aware
> that bodies might change.  I've pointed out that the situation is not
> improved if body modifying services are made into compliant 
> B2BUAs (they
> will bump everything that has a Require: header whereas at least body
> modifying Proxies would carry on).
> 
> From these observations I have postulated that, if nothing is 
> done the SIP
> infrastructure will be broken and consequently the services 
> that SIP can
> offer will not be as rich as some had hoped.
> 
> I am prepared to help work on solutions to these problems (I 
> don't think it
> will take much solving), but if the inner circle do not wish 
> to consider
> these issues, then that's fine by me also.
> 
> Pete.
> 
> =============================================
> Pete Cordell
> Tech-Know-Ware
> [email-masked]
> +44 1473 635863
> =============================================
> 
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>