[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] INFO Framework: Tags
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Sunday, November 23, 2008 11:21 PM
>
> DRAGE, Keith (Keith) wrote:
> > But now you are making the assumption that all info-packages require the
> > call to fail if I do not support the info package.
>
> No, I'm not. I'm saying that SOME non-standards-track INFO packages will
> need the call to fail if the far end does not support INFO packages. If
> they don't need it to fail, they shouldn't use the options tag in a
> RequireFrom sip-bounces at ietf.org Sun Nov 23 21:55:56 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1835C3A691B;
Sun, 23 Nov 2008 21:55:56 -0800 (PST)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C34A43A691B
for <sip at core3.amsl.com>; Sun, 23 Nov 2008 21:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level:
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id f09YhRNIY8el for <sip at core3.amsl.com>;
Sun, 23 Nov 2008 21:55:54 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6])
by core3.amsl.com (Postfix) with ESMTP id C6DA83A68B1
for <SIP at ietf.org>; Sun, 23 Nov 2008 21:55:53 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1;
Mon, 24 Nov 2008 00:54:24 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with
mapi; Mon, 24 Nov 2008 00:54:22 -0500
From: Hadriel Kaplan <HKaplan at acmepacket.com>
To: Dean Willis <dean.willis at softarmor.com>, "DRAGE, Keith (Keith)"
<drage at alcatel-lucent.com>
Date: Mon, 24 Nov 2008 00:56:02 -0500
Thread-Topic: [Sip] INFO Framework: Tags
Thread-Index: AclN6+xVW+0W4nuTRH2eaRuTEUb0GgACuhCg
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31374154703 at mail>
References: <8BF9D1D9-DD57-47E9-AC73-3F96E1F35AEC at standardstrack.com><5F753F1B-1FDA-4ADB-9BCA-8445D1363F40 at softarmor.com><4925DFE5.7000700 at cisco.com><6AA8F84D-8061-446F-A7BB-52C6163163E8 at softarmor.com><5D1A7985295922448D5550C94DE2918002513272 at DEEXC1U01.de.lucent.com>A<CA9998CD4A020D418654FCDEF4E707DF05C0F997 at esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D0014836E5 at GBNTHT12009MSX.gb002.siemens.net>A
<CA9998CD4A020D418654FCDEF4E707DF05C0F9A9 at esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D0014839FD at GBNTHT12009MSX.gb002.siemens.net><E6C2E8958BA59A!
! ! 4FB960963D! 475F7AC31 374153D33 at ma
il><C2530165-D7F2-4696-B941-624956F033F8 at softarmor.com><E6C2E8958BA59A4FB960963D475F7AC31374153DDC at mail><DD76C31F-74EA-4529-8183-8898C620BF47 at softarmor.com><E6C2E8958BA59A4FB960963D475F7AC31374154168 at mail>
<5B218FC4-34B2-409C-9D53-93ED8BB99BFB at softarmor.com>
<5D1A7985295922448D5550C94DE291800251349F at DEEXC1U01.de.lucent.com>
<492A2BC1.1000006 at softarmor.com>
In-Reply-To: <492A2BC1.1000006 at softarmor.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: SIP List <SIP at ietf.org>
Subject: Re: [Sip] INFO Framework: Tags
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation 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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Sunday, November 23, 2008 11:21 PM
>
> DRAGE, Keith (Keith) wrote:
> > But now you are making the assumption that all info-packages require the
> > call to fail if I do not support the info package.
>
> No, I'm not. I'm saying that SOME non-standards-track INFO packages will
> need the call to fail if the far end does not support INFO packages. If
> they don't need it to fail, they shouldn't use the options tag in a
> Require directive.
Again, if a non-standards-track INFO package needs its info package, they'll do non-standard things to get the behavior they need, by putting their non-standard package name in Require, and it works. It is not necessary for us to help them. And again doing a check for the generic info-package draft support is not sufficient to accomplish their goal anyway, because as soon as another device supports the draft but not their specific non-standard one, they're back to square one. So it's neither necessary nor sufficient. What is there to debate over?
> This is pretty basic stuff, kids. Why are you making it so darned hard?
Because it's easier (and cheaper) to debate this now than to handle the tech-support calls later.
> > By default, we must make the ordinary assumption we make for all
> > extensions, i.e. that we can discard the information if it is not
> > understood.
>
> Don't even get me started on explaining the blatant hypocrisy in that
> statement when compared to the extensions driven from 3GPP ;-).
But that's why we're in the IETF and not 3GPP.
-hadriel
_______________________________________________
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
directive.
Again, if a non-standards-track INFO package needs its info package, they'll do non-standard things to get the behavior they need, by putting their non-standard package name in Require, and it works. It is not necessary for us to help them. And again doing a check for the generic info-package draft support is not sufficient to accomplish their goal anyway, because as soon as another device supports the draft but not their specific non-standard one, they're back to square one. So it's neither necessary nor sufficient. What is there to debate over?
> This is pretty basic stuff, kids. Why are you making it so darned hard?
Because it's easier (and cheaper) to debate this now than to handle the tech-support calls later.
> > By default, we must make the ordinary assumption we make for all
> > extensions, i.e. that we can discard the information if it is not
> > understood.
>
> Don't even get me started on explaining the blatant hypocrisy in that
> statement when compared to the extensions driven from 3GPP ;-).
But that's why we're in the IETF and not 3GPP.
-hadriel
_______________________________________________
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