Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck?
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Tue, 19 June 2012 18:58 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793C511E8144 for <bfcpbis@ietfa.amsl.com>; Tue, 19 Jun 2012 11:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+5Mkqha9xXL for <bfcpbis@ietfa.amsl.com>; Tue, 19 Jun 2012 11:58:22 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C93E411E8135 for <bfcpbis@ietf.org>; Tue, 19 Jun 2012 11:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3166; q=dns/txt; s=iport; t=1340132303; x=1341341903; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=rIjREVi/uhkqXius+FWOAifxnY3AlgYm2KWzFwJBUcg=; b=dda2xskDVIw0CUsQMXHkT4TJ70nwWTk7AbEgUSamPYsSjjEd0PMEgCtD 4jwuT9I3JNokBaQwY440anuLL78j/VJF48nJ0f5dGKB0ypkgw69hOuuWs MfdlRmS/H8gLjLrGukO8wS/znOwPUSJgiaaS04jAAJWB+RWoUW10nGJe4 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGHL4E+rRDoG/2dsb2JhbABFtWqBB4IYAQEBBAEBAQ8BHQo0FwYBCBEEAQELBhcBByYfCQkBBAESCBqHaAELmSGgOQSCQYhuhTlgA4hDlg4BhGqBZoMAgTYH
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="46951243"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 19 Jun 2012 18:58:22 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5JIwMvZ029723; Tue, 19 Jun 2012 18:58:22 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 11:58:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Jun 2012 11:58:21 -0700
Message-ID: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C0753D0C8@xmb-sjc-234.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck?
Thread-Index: Ac1OTX9TZCpfQ9MxRY+b6QQ9g+King==
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Horvath, Ernst" <ernst.horvath@siemens-enterprise.com>, bfcpbis@ietf.org
X-OriginalArrivalTime: 19 Jun 2012 18:58:22.0278 (UTC) FILETIME=[7F898660:01CD4E4D]
Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck?
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2012 18:58:23 -0000
(as an individual) Hi Ernst, This is a good question. Looking at RFC 4582, table 1 shows the Error primitive as being for Server to Client/Participant only. The details in section 5.3.1.13 and the rest of the RFC are consistent with this. In all cases, the Error primitive from the server is in response to a client request primitive. Section 13.8 states: 13.8. Error Message Generation Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The changes made to address unreliable transport in draft-ietf-bfcpbis-rfc4582bis-03 add scenarios in which an Error primitive may be sent by either a client or a server. These scenarios include invalid payload length and not being able to parse a BFCP message in general. I believe the tables and corresponding sections in RFC 4582 need to be updated to reflect this change consistently. As for the ErrorAck message, while it could be argued that it is not strictly necessary, the bis draft does consistently state it as being required. The main benefit is that it allows both sides to unambiguously complete the transaction. I believe the corresponding text is okay as is. Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Horvath, Ernst > Sent: Friday, June 15, 2012 5:56 AM > To: bfcpbis@ietf.org > Subject: [bfcpbis] RFC4582bis: What is the transaction model > behindError/ErrorAck? > > Hi, > > I have a problem understanding the use of ErrorAck. > > For unreliable transport RFC4582bis describes two transaction types: > > 1) Client-initiated: A client (chair or participant) sends a request to the > server and receives a Status or an Error message back; the client runs T1 and > retransmits the request if no response arrives in time, but the server does > not run T1 and does not retransmit the response (Status or Error) unless > triggered by receipt of a retransmitted request. The client does not send a > StatusAck for the response. > > 2) Server-initiated: The server sends a notification (i.e. a follow-up status > message) to the client and receives a StatusAck back. The server runs T1 and > retransmits the notification if no StatusAck arrives, but the client does not > retransmit the StatusAck unless triggered by a retransmitted notification. > (Question: Can the client send an Error message instead of StatusAck? Error > seems to be reserved for the direction server to client, but the draft is not > 100% clear about that.) > > Now, how does ErrorAck fit in? Error is the backward message in a two-step > (request/reponse) transaction model, and BFCPbis did not introduce a > three-step (request/response/ack) model, right? Or can Error be used as a > transaction-initiating request, with ErrorAck forming the response? If so, > this is currently not described. > > Regards, > Ernst Horvath > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis
- Re: [bfcpbis] RFC4582bis: What is the transaction… Charles Eckel (eckelcu)
- Re: [bfcpbis] RFC4582bis: What is the transaction… Horvath, Ernst
- Re: [bfcpbis] RFC4582bis: What is the transaction… Charles Eckel (eckelcu)
- Re: [bfcpbis] RFC4582bis: What is the transaction… Tom Kristensen