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