Subject: RE: [Sip] B2BUA & Max-Forwards

From: Phil Reynolds <[email-masked]>
Date: Thu, 5 Dec 2002 09:49:38 -0000

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:[email-masked]] 
Sent: 04 December 2002 20:45
To: 'Phil Reynolds'; [email-masked]
Subject: RE: [Sip] B2BUA & Max-Forwards

-----Original Message-----
From: Phil Reynolds [mailto:[email-masked]]

> 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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Dec 2002 15:35:54 -0800

On Thursday, December 5, 2002, at 01:49 AM, Phil Reynolds wrote:
> Our system isn't broken. I would say that this shows that the spec is 
> broken not our system.

That remains to be seen.  If I demonstrated how to satisfy the business 
goal you are trying to solve without violating the spec, then I suspect 
the spec is just fine.

> 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)

... or that you preclude secure customers from using your product.

> 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)

re: end-to-end, check out the datasheet for:

	http://www.marconi.com/html/products/virtualpresencesystem.htm

likewise I believe Pingtel has an implementation.

thanks,
-rohan

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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 6 Dec 2002 18:50:12 -0600

Pardon me while I assert.
 
This thread is non-productive and downloading it is taking forever. I
think we have enough input to make any clarifications on B2BUA in bis
that I think we're going to be able to make.
 
The IESG has decreed that our specs WILL have provisions for security
functions, etc. and that anything that isn't compliant with these
provisions is NOT COMPLIANT with the specification. Enough said. If you
don't like it, talk to the non-com about changing the IESG or take it up
with the iESG.
 
Your can build ANY NON-COMPLIANT SYSTEM YOU WANT TO BUILD. Many such
systems will be USEFUL and WIDELY DEPLOYED. But it would be an error to
say that any such system is "compliant  o RFC ABCD" when that system
does not implement something that RFC ABCD lists as MUST IMPLEMENT. 
 
So if you have a thing you call a SIP proxy that does not implement MUST
IMPLEMENT functions of a SIP proxy as specified in RFC 3261, then it IS
NOT, by definition, a fully compliant SIP proxy. Odds are, it's some
kind of B2BUA that acts mostly but not quite like a proxy, and that's
OK. But DO be advised that anything that is "not a compliant proxy" is
likely to have limitations with some kind of service, extension or usage
of SIP, and that we're NOT going to worry about that a whole lot in the
protocol design.  So be prepared to update the widget occasionally if it
needs it to continue being useful.
 
Thanks.
 
--
Dean Willis
Annoyed Co-Chair, SIP Working Group.