[bfcpbis] Version Negotiation

"Alan Ford (alanford)" <alanford@cisco.com> Wed, 27 February 2013 12:09 UTC

Return-Path: <alanford@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 C97E321F854D for <bfcpbis@ietfa.amsl.com>; Wed, 27 Feb 2013 04:09:31 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgbaU0KzXtWt for <bfcpbis@ietfa.amsl.com>; Wed, 27 Feb 2013 04:09:31 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1894C21F8484 for <bfcpbis@ietf.org>; Wed, 27 Feb 2013 04:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1361966971; x=1363176571; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=LcSu63wRBGbfsMHVGL9MO9fhFw6MKsKDCGxwA35lzQQ=; b=dh2Gw09/mzlt+QWjgfH8SHa0nMzoRIFcocQaQ3+LXlvPajR0Cp1Wy66p P9oc/0GxbGob02nyEheAH0dm08eNY03VVGUCsux53Wcbb7rwn2IZ5n6NE q2giVCsHpV1L7RgMf2lzDn3RiO9Yf9IuhnOhV2uw+qy2QLDpeM/KcWJm/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAK/2LVGtJXHA/2dsb2JhbABEwhZ5FnOCIQEEOlEBKhRCJwQbiAudMKEDjmODF2EDpyuDCIIn
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; d="scan'208";a="181765779"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2013 12:09:30 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1RC9UYL011670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <bfcpbis@ietf.org>; Wed, 27 Feb 2013 12:09:30 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 06:09:30 -0600
From: "Alan Ford (alanford)" <alanford@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: Version Negotiation
Thread-Index: AQHOFONLpaHXxZhH30ueQXkyHk5lCQ==
Date: Wed, 27 Feb 2013 12:09:29 +0000
Message-ID: <B8A9B6587D9897498E7F967D5F8E98791338A80D@xmb-rcd-x08.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [10.147.93.94]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8340A795A6C79E4FB0EFEEDEC26F3494@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [bfcpbis] Version Negotiation
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: Wed, 27 Feb 2013 12:09:31 -0000

Hi all,

Some recent interop testing and discussions has raised concerns over how
we determine the BFCP version to use, for both now and for future versions.

At the moment, we don't say much about this in the drafts. We define an
"Unsupported Version" error, but that's about it. The implication
therefore is that a UA would try sending BFCP version=2, and if no
response is received, it would try again with version=1 if it supported
it. This is unreliable and slow.

It would seem much better to declare supported versions in an SDP
attribute. I propose something in 4583bis that specifies an attribute like
this:

  bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version)
  bfcp-version           = token

Which can then be responded to in the answer, much like RTP payload types.
(At the moment that's not restricted to numeric values only, so we don't
restrict future things here.) Essentially by declaring support for a
version in the SDP, a sender is saying they are willing to speak this
version if it is received.

I also think we also need to tighten the text in the drafts slightly. In
S13.7 of 4582bis, we should say that a HelloAck MUST echo the version
presented in a Hello message (otherwise Unsupported Version MUST be sent).

Thoughts?

Regards,
Alan