[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Proposal for multiple INFO bodies in an INFO
Eric Burger wrote:
...
I would also offer that since INFO does not change SIP state, which
means there is not even a concept of a message succeeding but the INFO
body doing something that "fails", the objection that it would be hard
for a UA to report on one body "failing" with another body "succeeding"
is a non-issue. Yes, this does mean that you cannot use INFO to tunnel
IP. See RFC 3252 for more on this. I do not see this as a problem.
Not sure I follow this. If an INFO carries bodies for info packages A
and B and the one for A is fine but the one for B is malformed, then is
the INFO rejected or not?
Thanks,
Anders
_____From sip-bounces at ietf.org Thu Oct 30 18:56:23 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 A38ED3A6A34;
Thu, 30 Oct 2008 18:56:23 -0700 (PDT)
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 488B63A6B13
for <sip at core3.amsl.com>; Thu, 30 Oct 2008 18:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 2WNeLZnr++l8 for <sip at core3.amsl.com>;
Thu, 30 Oct 2008 18:56:21 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70])
by core3.amsl.com (Postfix) with ESMTP id 86DD73A6A34
for <SIP at ietf.org>; Thu, 30 Oct 2008 18:56:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,519,1220227200"; d="scan'208";a="98395932"
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
by sj-iport-1.cisco.com with ESMTP; 31 Oct 2008 01:56:20 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id m9V1uKR7016622;
Thu, 30 Oct 2008 18:56:20 -0700
Received: from [10.21.76.130] ([10.21.76.130])
by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9V1uKJP009702;
Fri, 31 Oct 2008 01:56:20 GMT
Message-ID: <490A65C4.1090109 at cisco.com>
Date: Thu, 30 Oct 2008 18:56:20 -0700
From: Anders Kristensen <andersk at cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Eric Burger <eburger at standardstrack.com>
References: <322862FF-3683-465F-B1A0-8C619A5D60E1 at standardstrack.com>
In-Reply-To: <322862FF-3683-465F-B1A0-8C619A5D60E1 at standardstrack.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=673; t=1225418180; x=1226282180;
c=relaxed/simple; s=sjdkim7002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=andersk at cisco.com;
z=From:=20Anders=20Kristensen=20<andersk at cisco.com>
|Subject:=20Re=3A=20[Sip]=20Proposal=20for=20multiple=20INF
O=20bodies=20in=20an=20INFO |Sender:=20;
bh=tEGKD8h2SGf+BSHjczKxwnBDaiPTzzEKW5+ejJYgbho=;
b=JM1N6GW/xsaq2dcBUm5J3meCaQ9baqylWymfhxhP06Or2bVVSY5XZRYxQp
/zT3O7mruZf9iloBakJWNhbutzA01+GH5Gj7ZHF03n8EZq+olkzwSlK2g34S
GBiXAz0J99;
Authentication-Results: sj-dkim-7; header.From=andersk at cisco.com; dkim=pass (
sig from cisco.com/sjdkim7002 verified; );
Cc: IETF SIP List <SIP at ietf.org>
Subject: Re: [Sip] Proposal for multiple INFO bodies in an INFO
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-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
Eric Burger wrote:
...
I would also offer that since INFO does not change SIP state, which
means there is not even a concept of a message succeeding but the INFO
body doing something that "fails", the objection that it would be hard
for a UA to report on one body "failing" with another body "succeeding"
is a non-issue. Yes, this does mean that you cannot use INFO to tunnel
IP. See RFC 3252 for more on this. I do not see this as a problem.
Not sure I follow this. If an INFO carries bodies for info packages A
and B and the one for A is fine but the one for B is malformed, then is
the INFO rejected or not?
Thanks,
Anders
_______________________________________________________
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
__________________________________
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