Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

Christer Holmberg <> Wed, 26 October 2016 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C14F9129683 for <>; Wed, 26 Oct 2016 11:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7DdlA7iYR-cM for <>; Wed, 26 Oct 2016 11:17:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C03C129C0F for <>; Wed, 26 Oct 2016 11:17:31 -0700 (PDT)
X-AuditID: c1b4fb25-93fff70000001e3e-70-5810f293fe4a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 43.69.07742.392F0185; Wed, 26 Oct 2016 20:14:44 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 26 Oct 2016 20:14:43 +0200
From: Christer Holmberg <>
To: "Suhas Nandakumar (snandaku)" <>, "Charles Eckel (eckelcu)" <>, Alissa Cooper <>
Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt
Thread-Index: AQHSLs8iIDRpK07DLEqkhcTWQv2V9qC62r6AgAALdACAACXAcA==
Date: Wed, 26 Oct 2016 18:14:43 +0000
Message-ID: <>
References: <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BDF4C41ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7q+6UTwIRBsu3KllsOf6OxWL6mb+M Fv/WHWWy2DTrC5vF4gP3WS2uHPnF5sDmMeX3RlaPL09eMnnsnHWX3WPJkp9MASxRXDYpqTmZ ZalF+nYJXBknr7awFzyaxVKx59oktgbGJz0sXYwcHBICJhK3G9S6GDk5hATWM0qc2pTaxcgF ZC9hlNjzeiEjSA2bgIVE9z9tkLiIQBejxMcDr5lAHGaBNkaJ4yuesIF0Cwu4S5zf2c0OYosI eEgcW9LNCmE7SVy7eRYsziKgKjH90yMmEJtXwFdi3d497BDbdjFJnP15ihEkwSmgI/F85V+w IkYBMYnvp9aA2cwC4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8VwlaSWHt4OwtEfb7Eknsz2SCW CUqcnPmEZQKjyCwko2YhKZuFpGwW0NPMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWj aHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYFwe3PJbdQfj5TeOhxgFOBiVeHgfbBOIEGJNLCuu zD3EKMHBrCTCe/g9UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZ Jg5OqQZGve2xxzPVNFXVLS3Snos/f5j40MRarzrg96bj0p/5cmsZPaR/XPmzh18wM6+6THfW zbb/XlKX3Yv/c0u/Y9eoXHj5tvam5pkvQ5XMnJ0+nZ11X3yf8cf31poW7WddF2/qnMz+/JV9 RHGDj7RvVLaD3/bK3f4LLATv2D+1kJqxOulCaKYrb50SS3FGoqEWc1FxIgCKkdlVxwIAAA==
Archived-At: <>
Cc: "" <>, Tom Kristensen <>, "Tom Kristensen (tomkrist)" <>
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Oct 2016 18:17:36 -0000


I don’t understand how it can be IDENTICAL if we haven’t even defined how to bundle multiple bfcp streams.



From: Suhas Nandakumar (snandaku) []
Sent: 26 October 2016 20:59
To: Charles Eckel (eckelcu) <>; Alissa Cooper <>
Cc: Christer Holmberg <>; Tom Kristensen (tomkrist) <>; Tom Kristensen <>;
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

​Hello Charles

  The mux attributes draft specifies category of IDENTICAL for floorctrl and NORMAL for other RFC4583 attributes. I do think RFC4583bis should reflect the same.



PS: The category IDENTICAL was concluded after having a discussion with you back in 2013 :-) since it enforced common control

From: Charles Eckel (eckelcu)
Sent: Wednesday, October 26, 2016 10:18 AM
To: Alissa Cooper
Cc: Christer Holmberg; Tom Kristensen (tomkrist); Tom Kristensen;<>; Suhas Nandakumar (snandaku)
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

Hi Alissa,

This draft simply states that BUNDLE multiplexing is not supported in this specification and that BFCP m- lines MUST NOT be included in a bundle group. If someone wanted to define how BUNDLE multiplexing could be done or to use the SDP attributes defined here with BUNDLE m lines for something else, they would need to specify this in another draft. Within this working group, we do not have plans for such a draft.

We were going to specify the MUX category as IDENTICAL, but then switched to TBD. I thought this was as advised by Suhas, but I cannot find evidence of that now. IDENTICAL would be fine with me. Suhas, any thoughts?


On 10/25/16, 4:50 PM, "Alissa Cooper" <<>> wrote:

On Aug 22, 2016, at 4:07 PM, Charles Eckel (eckelcu) <<>> wrote:

Thanks Christer.
I don’t think a separate “BUNDLE Considerations” section is warranted. Adding the agreed upon text to section 10 is sufficient.
We can continue to specify the MUX category in the rfc4583bis draft and am okay with TBD.

Having just reviewed draft-ietf-mmusic-sdp-mux-attributes again, I’m wondering why TBD would be specified here rather than choosing a value. Is there some future document where the WG would expect to specify the value or some implementation experience that people feel is necessary before the value can be specified? If not, then 4583bis seems like the right place to specify the value.


Thank s again,

From: Christer Holmberg <<>>
Date: Friday, August 19, 2016 at 12:39 PM
To: Charles Eckel <<>>, Tom Kristensen <<>>, Tom Kristensen <<>>, "<>" <<>>
Cc: "Suhas Nandakumar (snandaku)" <<>>
Subject: RE: SV: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt


I agree that we should say that BUNDLE multiplexing is not supported  in this specification, and that BFCP m- lines MUST NOT be included in a bundle group.

Perhaps you could put that text in a small “BUNDLE Considerations” chapter, or something similar?

Regarding where to define the MUX category for the new attribute, I suggest we do it in this draft, since that is part of the information you need to specify when registering a new attribute.

Regarding the mux category value, I guess IDENTICAL would work – eventhough it’s a little strange considering we don’t define BFCP multiplexing to begin with. Would TBD be more suitable?



From: Charles Eckel (eckelcu) []
Sent: 02 August 2016 17:43
To: Tom Kristensen (tomkrist) <<>>; Tom Kristensen <<>>;<>
Cc: Suhas Nandakumar (snandaku) <<>>; Christer Holmberg <<>>
Subject: Re: SV: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

Thanks Tom.
Suhas, Christer, any thoughts?


From: Tom Kristensen <<>>
Date: Monday, August 1, 2016 at 4:49 AM
To: Charles Eckel <<>>, Tom Kristensen <<>>, "<>" <<>>
Cc: "Suhas Nandakumar (snandaku)" <<>>, Christer Holmberg <<>>
Subject: SV: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

It would be ideal to treat bfcpver the same way as the other, existing attributes. Hopefully, the authors of  draft-ietf-mmusic-sdp-mux-attributes​ will add them to this draft.

I do like to move the BUNDLE reference to informational, so I support Charles' text proposal in his last paragraph below.

-- Tom
Fra: Charles Eckel (eckelcu)
Sendt: 8. juli 2016 23:39
Til: Tom Kristensen;<>
Kopi: Tom Kristensen (tomkrist); Suhas Nandakumar (snandaku); Christer Holmberg
Emne: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

Hi Tom,

Thanks for incorporating the changes. The dtls-id change looks good. Unfortunately, the MUX category change suffers from the fact we are chasing a moving target. draft-ietf-mmusic-sdp-mux-attributes was updated recently and the NOT RECOMMENDED category was replaced with the CAUTION category.

Upon taking another look at draft-ietf-mmusic-sdp-mux-attributes, my previous suggestion was not good. draft-ietf-mmusic-sdp-mux-attributes already defines the Mux category for all SDP attribute defined in rfc4583bis except the newly added bfcpver SDP attribute. For this, I think the Mux category should be IDENTICAL. However, I’m not sure if it should be added to rfc4583bis or to draft-ietf-mmusic-sdp-mux-attributes directly. I have cc’d Suhas to Christer to get their input, both on the mux category selected and where it should be specified.

As for multiplexing of BFCP lines, perhaps rfc4583bis should simply say, "Multiplexing of BFCP ‘m' lines, as defined in BUNDLE [16], is not defined by this specification.”
If we agree to this, the reference to BUNDLE should be Informational instead of Normative.


From: bfcpbis <<>> on behalf of Tom Kristensen <<>>
Date: Wednesday, July 6, 2016 at 11:13 PM
To: "<>" <<>>
Cc: Tom Kristensen <<>>
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-15.txt

Incorporates the two issues spotted by Charles in the -14 version. The draft should most likely and hopefully be ready to proceed through the next stages now.

-- Tom

On 7 July 2016 at 08:10, <<>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Binary Floor Control Protocol Bis  of the IETF.

        Title           : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
        Authors         : Gonzalo Camarillo
                          Tom Kristensen
                          Paul E. Jones
        Filename        : draft-ietf-bfcpbis-rfc4583bis-15.txt
        Pages           : 21
        Date            : 2016-07-06

   This document specifies how to describe Binary Floor Control Protocol
   (BFCP) streams in Session Description Protocol (SDP) descriptions.
   User agents using the offer/answer model to establish BFCP streams
   use this format in their offers and answers.

   This document obsoletes RFC 4583.  Changes from RFC 4583 are
   summarized in Section 14.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

Internet-Drafts are also available by anonymous FTP at:

bfcpbis mailing list<>

# Cisco                         |
##<>  |<>
###                               |
bfcpbis mailing list<>