[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] INFO Framework - one pakage per INFO
HFrom sip-bounces at ietf.org Fri Nov 28 23:04:03 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 E80B53A68E3;
Fri, 28 Nov 2008 23:04:02 -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 BCD403A6AF0
for <sip at core3.amsl.com>; Fri, 28 Nov 2008 23:04:01 -0800 (PST)
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 vqG8QPBV-eVu for <sip at core3.amsl.com>;
Fri, 28 Nov 2008 23:04:00 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
by core3.amsl.com (Postfix) with ESMTP id D15363A68E3
for <SIP at ietf.org>; Fri, 28 Nov 2008 23:04:00 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,686,1220227200"; d="scan'208";a="203464597"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
by sj-iport-6.cisco.com with ESMTP; 29 Nov 2008 07:03:58 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAT73vLC031777;
Fri, 28 Nov 2008 23:03:57 -0800
Received: from [10.21.90.24] (sjc-vpn5-536.cisco.com [10.21.90.24])
by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAT73vZA011155;
Sat, 29 Nov 2008 07:03:57 GMT
Message-ID: <4930E958.5020507 at cisco.com>
Date: Fri, 28 Nov 2008 23:03:52 -0800
From: Anders Kristensen <andersk at cisco.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan at acmepacket.com>
References: <94081CC4-F9BE-4651-BE3D-9D5CEDC3CA8D at standardstrack.com><CA9998CD4A020D418654FCDEF4E707DF05C0F98E at esealmw113.eemea.ericsson.se><F779DAF0-507D-4BB0-BA8C-C687F1C7BB30 at standardstrack.com> <CA9998CD4A020D418654FCDEF4E707DF05C0F9E2 at esealmw113.eemea.ericsson.se> <E6C2E8958BA59A4FB960963D475F7AC31374B1F09C at mail> <CA9998CD4A020D418654FCDEF4E707DF05C0F9E8 at esealmw113.eemea.ericsson.se> <E6C2E8958BA59A4FB960963D475F7AC31374B1F0DE at mail> <CA9998CD4A020D418654FCDEF4E707DF05C0F9EB at esealmw113.eemea.ericsson.se> <5FD627EF-B1CB-4F03-A79B-8D75E9CA0B65 at standardstrack.com> <49306F15.5020905 at cisco.com>
<E6C2E8958BA59A4FB960963D475F7AC31374B1F161 at mail>
<4930AC7C.8040406 at cisco.com>
<E6C2E8958BA59A4FB960963D475F7AC31374B1F189 at mail>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC31374B1F189 at mail>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1742; t=1227942237;
x=1228806237; c=relaxed/simple; s=sjdkim4002;
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]=20INFO=20Framework=20-=20one=20pa
kage=20per=20INFO |Sender:=20;
bh=gGcIcCf3SO340DloQfbTliPOxH32YP1fg3sSaJjR5L0=;
b=IlokR3LUxpe+lyl+AJBWZLGFY8eB92xldbQWxxqUcA6CGoj8VRdY8X0TA5
RN3cGdyPiAsd0rJwO6fzqo6CL4IZhebBsmKDksa5Pty3AgPB99aHQUHXlV65
PKZd9pcsHO;
Authentication-Results: sj-dkim-4; header.From=andersk at cisco.com; dkim=pass (
sig from cisco.com/sjdkim4002 verified; );
Cc: SIP List <SIP at ietf.org>
Subject: Re: [Sip] INFO Framework - one pakage per 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
Hadriel Kadriel Kaplan wrote:
-----Original Message-----
From: Anders Kristensen [mailto:andersk at cisco.com]
Sent: Friday, November 28, 2008 9:44 PM
In any event (no pun intended) I don't think the draft adequately deals
with the implications of this model. If errors occurring at higher
layers aren't reported as failure of the INFO request itself, it pretty
much follows that the 200 response to the INFO must include a payload
that carries info (sorry, pun not intended here either) on the error.
No I think the logic that Eric's arguing for is "you asked for delivery of this package, and I'm responding with 200 ok because it was delivered". In other words treat INFO as a delivery vehicle, like MESSAGE, and as long as the package was delivered you send a 200 ok, with no correlation to if/when the package was opened and read successfully or not by a higher-layer info-package "consumer".
The alternatives would be:
1) Don't report app-level errors. Perhaps OK for simple packages.
2) Report outcome in separate INFO requests going in the opposite
direction. Seems wasteful and requires additional app-level correlation.
Yeah, I think Eric's argument is for (2). If they need it, they pay for it.
Well, in the case of (2) I'd say they'd be overpaying. In my view it's a
non-starter. People will want to be able to send app-level responses and
they won't want to go through a lot of extra trouble to do it. And why
should they? I'm thinking we should allow app-level errors to be
signalled with INFO error codes and/or allow INFO responses to carry
responses along the lines of what CSTA does.
I'll be applying the flame retardant now...
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
aplan wrote:
-----Original Message-----
From: Anders Kristensen [mailto:andersk at cisco.com]
Sent: Friday, November 28, 2008 9:44 PM
In any event (no pun intended) I don't think the draft adequately deals
with the implications of this model. If errors occurring at higher
layers aren't reported as failure of the INFO request itself, it pretty
much follows that the 200 response to the INFO must include a payload
that carries info (sorry, pun not intended here either) on the error.
No I think the logic that Eric's arguing for is "you asked for delivery of this package, and I'm responding with 200 ok because it was delivered". In other words treat INFO as a delivery vehicle, like MESSAGE, and as long as the package was delivered you send a 200 ok, with no correlation to if/when the package was opened and read successfully or not by a higher-layer info-package "consumer".
The alternatives would be:
1) Don't report app-level errors. Perhaps OK for simple packages.
2) Report outcome in separate INFO requests going in the opposite
direction. Seems wasteful and requires additional app-level correlation.
Yeah, I think Eric's argument is for (2). If they need it, they pay for it.
Well, in the case of (2) I'd say they'd be overpaying. In my view it's a
non-starter. People will want to be able to send app-level responses and
they won't want to go through a lot of extra trouble to do it. And why
should they? I'm thinking we should allow app-level errors to be
signalled with INFO error codes and/or allow INFO responses to carry
responses along the lines of what CSTA does.
I'll be applying the flame retardant now...
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