Our system isn't broken. I would say that this shows that the spec is broken not our system.
Our system provides facilities for some (and we hope "most") users. We don't provide these facilities for all users because: A) We don't think they are important for most users, B) The spec precludes us from doing so (e.g. end-to-end security)
But because the spec says we MUST do end-to-end security we can't be sanctioned as compliant, despite the fact that "most" of our users don't want that. (BTW I have yet to see a endpoint that does end-to-end security so it appears that these are all broken as well)
-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: 04 December 2002 20:45
To: 'Phil Reynolds'; sip@ietf.org
Subject: RE: [Sip] B2BUA & Max-Forwards
-----Original Message-----
From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com]
> Now your back to restricting what I can and can't do in an
> intermediary. It can't be a B2BUA 'cos it doesn't need to honour
> require headers (the UA at the other end does that, if they were meant
> for my intermediary then they would be proxy-require?), and it can't
> be a proxy 'cos of the rules about not changing the body so what is
> it?
Broken.
The restrictions placed on nodes by 3261 (which I'm merely reiterating, not imposing) aren't an authoritarian attempt at unnecessary proscription. They serve a purpose.
I'll describe one of the (several) purposes that applies
to the situation you propose.
One of the things that UAs are required to be able to do is sign and/or encrypt the bodies and/or some subset of the headers to ensure confidentiality and/or integrity. The protocol places restrictions on various nodes to ensure that this can be done. Your box is broken precisely because it interferes with these abilities (or, more precisely, these abilities interfere with it).
/a