Subject: RE: [Sip] GRUU (was Whats wrong with Supported.

From: "Christian Jansson" <[email-masked]>
Date: Fri, 11 Nov 2005 09:13:48 +0100

>I think there are practical difficulties with this.
>
>In a real deployment you would like the common case to be that things
>work on the first try. If you usually have to try twice then you
>effectively double the amount of signaling your network must support,
>and increase the latency as well.
>
>Following your suggestion, if you deploy a "modern" (gruuful) proxy
with
>only gruuless UAs, you would have double the traffic you would have if
>you had the proxy recognize "Supported:gruu".
>
>	Paul

But wouldn't it be better to let the broken things advertise that they
do not follow the specification completely. Let the UAs that do not
insert contact that is globally routable add a "Supported:
not-gruu-contact" if they do not want to have the penalty of the proxy
trying twice. I think we should optimize the performance for those who
do things right according to the spec, instead of having everybody
adding more kludges to their messages. Of course we should also have a
backwards compatible solution, but I think it is very important to have
the additional cost paid by members with the broken implementations,
"Supported: not-gruu-contact" would be my simple suggestion.

/ Christian Jansson

_______________________________________________
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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 11 Nov 2005 08:20:56 -0500

Christian,

Isn't this the equivalent of asking everyone not in the room to please
raise your hand?

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Jansson
> Sent: Friday, November 11, 2005 3:14 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: Sip
> Subject: RE: [Sip] GRUU (was Whats wrong with Supported.
> 
> But wouldn't it be better to let the broken things advertise 
> that they do not follow the specification completely. Let the 
> UAs that do not insert contact that is globally routable add 
> a "Supported:
> not-gruu-contact" if they do not want to have the penalty of 
> the proxy trying twice. I think we should optimize the 
> performance for those who do things right according to the 
> spec, instead of having everybody adding more kludges to 
> their messages. Of course we should also have a backwards 
> compatible solution, but I think it is very important to have 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christian Jansson" <[email-masked]>
Date: Mon, 14 Nov 2005 16:47:58 +0100

So, you think the solution I presented is not enough? 

The implementations that know they are broken can say so to speed up
handling (optional to follow by server). The rest of the broken
implementations will get a penalty when the server first tries to do the
right thing before finally trying any dirty hacks.

I bet someone is going to say something like: "But what if I know that
all my UAs are "broken". Then the server can do the hacks first to speed
things up". My answer to that is that our goal is to standardize and
optimize the correct way of doing things. People can do whatever crazy
things they like and implement other solutions, but it won't be standard
SIP. In this case I even presented a back-up solution that will work
even for those who haven't done everything right. What more could they
ask for? 

Instead, tell me why everybody, from now on, and forever, should pay the
prize because some implementations choose to take a short-cut.
(SIP is already full of those kludges, lets not make another one if we
can avoid it!)

/ Christian Jansson

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 14 Nov 2005 13:56:42 -0500

Could you explain the cost/benefit of some vendor to upgrade their
client just to say they don't support each new feature?

That doesn't mean that the system can not progress, just that it needs
to determine if it is breaking a previous feature where backward
compatibility is worthwhile, or whether the previous feature was broken
to begin with and will remain broken until certain elements get with the
program.

Mike

> From: Christian Jansson [mailto:[email-masked]] 
> Sent: Monday, November 14, 2005 10:48 AM
> To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat)
> Cc: Sip
> The implementations that know they are broken can say so to 
> speed up handling (optional to follow by server). The rest of 
> the broken implementations will get a penalty when the server 
> first tries to do the right thing before finally trying any 
> dirty hacks.
> 
> I bet someone is going to say something like: "But what if I 
> know that all my UAs are "broken". Then the server can do the 
> hacks first to speed things up". My answer to that is that 
> our goal is to standardize and optimize the correct way of 
> doing things. People can do whatever crazy things they like 
> and implement other solutions, but it won't be standard SIP. 
> In this case I even presented a back-up solution that will 
> work even for those who haven't done everything right. What 
> more could they ask for? 
> 
> Instead, tell me why everybody, from now on, and forever, 
> should pay the prize because some implementations choose to 
> take a short-cut.
> (SIP is already full of those kludges, lets not make another 
> one if we can avoid it!)
> 
> / Christian Jansson
> 
> 
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Christian Jansson
> >> But wouldn't it be better to let the broken things advertise that 
> >> they do not follow the specification completely. Let the 
> UAs that do 
> >> not insert contact that is globally routable add a "Supported:
> >> not-gruu-contact" if they do not want to have the penalty of the 
> >> proxy trying twice. I think we should optimize the performance for 
> >> those who do things right according to the spec, instead of having 
> >> everybody adding more kludges to their messages. Of course 
> we should 
> >> also have a backwards compatible solution, but I think it is very 
> >> important to have the additional cost paid by members with 
> the broken 
> >> implementations,
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
>

---

From: "Christian Jansson" <[email-masked]>
Date: Wed, 16 Nov 2005 09:57:34 +0100

>client just to say they don't support each new feature?

As I said, people can do whatever they like, and if you do not like to
upgrade your clients and servers, fine. The SIP WG is here to create and
promote a working standard, from now on, and forever. My point was to
optimize the behavior of the protocol for the ones that have, and for
those who will, implement it in a correct way. I also presented the
back-up plan of how broken implementations will work together with
correct implementations. Your question seems to be "The vendor has a
working system, with broken clients and broken servers, how should I
explain why they should upgrade?)". My answer, don't fix it, if the
system is working for the moment, but don't try to optimize the SIP
standard for that scenario.

>to begin with and will remain broken until certain elements get with
the

This is not a discussion of some additional special feature, it is part
of the core specification. As have been said before, the contact header
should always have been globally routable. Otherwise we could end up
with extension tags for everything that is actually in RFC-3261, just
like I described in my first mail. Are you actually thinking that is a
good idea?

/ Christian Jansson

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 16 Nov 2005 09:17:05 -0500

You keep trying to extrapolate from a very simple comment to some other
undesirable design.  If that leads to uneasiness on your part then don't
do it.  I meant only to say that it is not worthwhile to waste time
inventing a protocol element that would likely never get used.  

Nothing more.

Mike 

> Sent: Wednesday, November 16, 2005 3:58 AM
> As I said, people can do whatever they like, and if you do 
> not like to upgrade your clients and servers, fine. The SIP 
> WG is here to create and promote a working standard, from now 
> on, and forever. My point was to optimize the behavior of the 
> protocol for the ones that have, and for those who will, 
> implement it in a correct way. I also presented the back-up 
> plan of how broken implementations will work together with 
> correct implementations. Your question seems to be "The 
> vendor has a working system, with broken clients and broken 
> servers, how should I explain why they should upgrade?)". My 
> answer, don't fix it, if the system is working for the 
> moment, but don't try to optimize the SIP standard for that scenario.
> 
> >
> This is not a discussion of some additional special feature, 
> it is part of the core specification. As have been said 
> before, the contact header should always have been globally 
> routable. Otherwise we could end up with extension tags for 
> everything that is actually in RFC-3261, just like I 
> described in my first mail. Are you actually thinking that is 
> a good idea?
> 
> / Christian Jansson
>

---

From: "Christian Jansson" <[email-masked]>
Date: Wed, 16 Nov 2005 15:45:20 +0100

>inventing a protocol element that would likely never get used.

Oops, sorry I misinterpreted what you said.

/ Christian