[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Sip-199-02: majors and nits from Robert
Hadriel Kaplan wrote:
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Monday, November 24, 2008 4:24 PM
If we can't think of any legitimate use for an option-tag in Require,
why should we allow it?
Because there may be a legitimate use for it tomorrow, or next week, or
next year.
It occurs to me maybe we're talking past each other. When I think of the *Require* header, I think of what does any random endpoint/gateway getting this request have to support for this to succeed. I can see no value in having that behavior, and plenty of harm in doing so. I don't want a UAC maker to ever think it can require UAS' to implement 199 in order for its request to succeed.
But maybe what you're talking about is *Proxy-Require*?
Well, we know tht Proxy-Require is way more evil.
Even so, it probably is the thing that a UAC might want to use if it
knew there were proxies doing the forking.
Trouble is - B2BUAs cause a lot of trouble with Require/Proxy-Require. I
suspect that Proxy-Require should have been MiddleBox-Require, and so
applied to B2BUAs.
So if you really need 199 responses any time a forked invite might have
been abandoned, then I think you must use *both* Require and
Proxy-Require. But that is pretty certain to guarantee that your call
will fail.
This has convinced me that there is no valid use of Require / Proxy-Require.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
itiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hadriel Kaplan wrote:
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Monday, November 24, 2008 4:24 PM
If we can't think of any legitimate use for an option-tag in Require,
why should we allow it?
Because there may be a legitimate use for it tomorrow, or next week, or
next year.
It occurs to me maybe we're talking past each other. When I think of the *Require* header, I think of what does any random endpoint/gateway getting this request have to support for this to succeed. I can see no value in having that behavior, and plenty of harm in doing so. I don't want a UAC maker to ever think it can require UAS' to implement 199 in order for its request to succeed.
But maybe what you're talking about is *Proxy-Require*?
Well, we know tht Proxy-Require is way more evil.
Even so, it probably is the thing that a UAC might want to use if it
knew there were proxies doing the forking.
Trouble is - B2BUAs cause a lot of trouble with Require/Proxy-Require. I
suspect that Proxy-Require should have been MiddleBox-Require, and so
applied to B2BUAs.
So if you really need 199 responses any time a forked invite might have
been abandoned, then I think you must use *both* Require and
Proxy-Require. But that is pretty certain to guarantee that your call
will fail.
This has convinced me that there is no valid use of Require / Proxy-Require.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip