Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt

From: [email-masked]
Date: Fri, 12 Oct 2012 04:54:32 -0700

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  Working Group of the IETF.

	Title           : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
	Author(s)       : Gonzalo Camarillo
                          Tom Kristensen
	Filename        : draft-ietf-bfcpbis-rfc4583bis-03.txt
	Pages           : 15
	Date            : 2012-10-12

Abstract:
   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 12.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 12 Oct 2012 14:02:27 +0200

>     summarized in section 12.

No comments or input received after WGLC. Anyway, this is a short, 
simple draft where the changes follows more or less automatically from 
the extensions in rfc4582bis.

After checking out with the original author of RFC 4583, the ipr 
parameter is changed s/pre5378Trust200902/trust200902/.

Cf. <URL: 
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4583bis-03.txt 

-- Tom

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 15 Oct 2012 16:29:08 +0000

(As co-chair)

For everyone, if there are any outstanding issues of questions you have related to this draft, please share them now.
We plan to proceed with the proto writeup soon. 

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Kristensen (tomkrist)
> Sent: Friday, October 12, 2012 5:02 AM
> To: [email-masked]
> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
> 
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-bfcpbis-
> rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4583bis-
> 03.txt
>  >
> 
> -- Tom
> 
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 15 Oct 2012 18:15:29 -0400

I greatly apologize; I should have sent this earlier.

There are some BFCP usages in the IMTC Role-Based Video Streams work <https://datatracker.ietf.org/liaison/1170/> which have some unusual features -- in particular, it recommends sending an offer with a BFCP stream referencing an mstrm that does not yet exist.  (The intention is that if the SDP answer indicates that the peer understands both BFCP and the SDP content attribute, a re-INVITE can be sent adding an additional BFCP-controlled video stream with "content:slides".)

This document should probably call out that usage, at least to indicate that it's valid for an mstrm to reference an undefined label.

--
Jonathan Lennox
[email-masked]

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 17 Oct 2012 10:44:09 +0200

I'm not sure we should say much about this in rfc4583bis. This is 
similar to existing "best effort encryption" schemes, where different 
vendors historically have had their own interpretation of a best current 
practice.

Anyway, it is not a big deal adding an informational note, if people 
thinks that's a good idea, explaining that one may very well meet an 
mstrm referring to a still undefined label.

(Do we then reference the IMTC document as an informational reference or 
simply state the fact that this behaviour exists in the wild?!)

-- Tom

On 10/16/2012 12:15 AM, Jonathan Lennox wrote:
> There are some BFCP usages in the IMTC Role-Based Video Streams work<https://datatracker.ietf.org/liaison/1170/>  which have some unusual features -- in particular, it recommends sending an offer with a BFCP stream referencing an mstrm that does not yet exist.  (The intention is that if the SDP answer indicates that the peer understands both BFCP and the SDP content attribute, a re-INVITE can be sent adding an additional BFCP-controlled video stream with "content:slides".)
>
>>>> 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  Working
>>>>          
>>> Group of the IETF.
>>>        
>>>> 	Title           : Session Description Protocol (SDP) Format for Binary
>>>>          
>>> Floor Control Protocol (BFCP) Streams
>>>        
>>> Cf.<URL:

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 18 Oct 2012 20:33:25 +0000

I see no harm in adding such a note, and it may help. As for referencing the IMTC best practice document, it is available through a liaison statement at:
https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf

However, I expect this IMTC document to be updated and made available externally once the BFCPBIS work completes, so I am not sure referencing it this way is appropriate.

Thanks,
Charles

> From: Tom Kristensen (tomkrist)
> Sent: Wednesday, October 17, 2012 1:44 AM
> To: Jonathan Lennox
> Cc: Charles Eckel (eckelcu); [email-masked]
> > There are some BFCP usages in the IMTC Role-Based Video Streams
> work<https://datatracker.ietf.org/liaison/1170/>  which have some unusual
> features -- in particular, it recommends sending an offer with a BFCP stream
> referencing an mstrm that does not yet exist.  (The intention is that if the
> SDP answer indicates that the peer understands both BFCP and the SDP
> content attribute, a re-INVITE can be sent adding an additional BFCP-
> controlled video stream with "content:slides".)
> >
> > This document should probably call out that usage, at least to indicate that
> it's valid for an mstrm to reference an undefined label.
> >
> >
> >> For everyone, if there are any outstanding issues of questions you have
> related to this draft, please share them now.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 23 Oct 2012 18:17:05 +0000

Hi Jonathan,

I revisited this section of the draft, and on closer inspection, I noticed it currently reads as follows:

   The 'floorid' attribute is used in the SDP media description for BFCP
   media.  It defines a floor identifier and, possibly, associates it
   with one or more media streams. 

I interpret this to already account for the possibility of a floorid that is not yet associated with an existing media stream. Do you think we need to be more explicit? How about we extend the next paragraph as follows:

   Endpoints that use the offer/answer model to establish BFCP
   connections MUST support the 'floorid' and the 'label' attributes.  A
   floor control server acting as an offerer or as an answerer SHOULD
   include these attributes in its session descriptions.

Is extended as follows:

   Endpoints that use the offer/answer model to establish BFCP
   connections MUST support the 'floorid' and the 'label' attributes.  A
   floor control server acting as an offerer or as an answerer SHOULD
   include these attributes in its session descriptions. In some scenarios,
   a "floorid" may be specified in an initial offer/answer exchange with 
   any associated media streams being identified in subsequent
   exchanges.

Cheers,
Charles

> Behalf Of Charles Eckel (eckelcu)
> Sent: Thursday, October 18, 2012 1:33 PM
> To: Tom Kristensen (tomkrist); Jonathan Lennox
> Cc: [email-masked]; Gonzalo Camarillo ([email-masked]);
> Robert Sparks ([email-masked])
> I see no harm in adding such a note, and it may help. As for referencing the
> IMTC best practice document, it is available through a liaison statement at:
> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-
> the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf
> 
> However, I expect this IMTC document to be updated and made available
> externally once the BFCPBIS work completes, so I am not sure referencing it
> this way is appropriate.
> 
> Thanks,
> Charles
>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 23 Oct 2012 17:43:11 -0400

Hi Charles,

I agree that description makes sense.  I thought I had recalled the IMTC document recommending that the floorid include a dangling mstrm, rather than no mstrm, but now I can't find it.

Making the text more explicit couldn't hurt, but it's also not particularly necessary I think.

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2012 2:17 PM
To: Tom Kristensen (tomkrist); Jonathan Lennox
Cc: [email-masked]; Gonzalo Camarillo ([email-masked]); Robert Sparks ([email-masked])
Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt

Hi Jonathan,

Is extended as follows:

Cheers,
Charles

> Cc: [email-masked]; Gonzalo Camarillo 
> ([email-masked]); Robert Sparks ([email-masked])
> I see no harm in adding such a note, and it may help. As for 
> referencing the IMTC best practice document, it is available through a liaison statement at:
> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc
> - the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf
> 
> externally once the BFCPBIS work completes, so I am not sure 
> referencing it this way is appropriate.
> 
> Thanks,
> Charles
> 
> > similar to existing "best effort encryption" schemes, where 
> > different vendors historically have had their own interpretation of 
> > a best current practice.
> >
> > (Do we then reference the IMTC document as an informational 
> > reference
> or
> > features -- in particular, it recommends sending an offer with a 
> > BFCP
> stream
> > referencing an mstrm that does not yet exist.  (The intention is 
> > that if the SDP answer indicates that the peer understands both BFCP 
> > and the SDP content attribute, a re-INVITE can be sent adding an 
> > additional BFCP- controlled video stream with "content:slides".)
> > >
> > > This document should probably call out that usage, at least to 
> > > indicate
> that
> > >>>>   This draft is a work item of the Binary Floor Control 
> > >>>> Protocol Bis
> > Working
> > >>>>
> > >>> Group of the IETF.
> > >>>
> > >>>>     This document specifies how to describe Binary Floor 
> > >>>> Control
> > Protocol
> > >>> No comments or input received after WGLC. Anyway, this is a 
> > >>> short, simple draft where the changes follows more or less 
> > >>> automatically
> from
> > >>> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/dra
> > >>> ft-ietf-
> > bfcpbis-
> > >>> rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpb
> > >>> is-
> > rfc4583bis-
> > >>> 03.txt
> > >>>
> > >>>>
> > >>> -- Tom
> > >>>

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 24 Oct 2012 07:47:36 +0200

Charles,

The additional text is good. However, I don't think it's necessary to 
include.

-- Tom

On 10/23/2012 11:43 PM, Jonathan Lennox wrote:
>>> work<https://datatracker.ietf.org/liaison/1170/>   which have some
>>>        
>> unusual
>>      
>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>              
>> On
>>      
>>>>>>>      User agents using the offer/answer model to establish BFCP
>>>>>>>                
>> streams
>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 24 Oct 2012 15:07:11 +0000

Your recollection is correct. Figure 5.2 of the IMTC document contains a call flow illustrating that exact usage; however, I see that figure 5.2 did not survive the MS Word to PDF conversion process and is therefore missing from the version of the document included in the liaison statement.

Cheers,
Charles

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 2:43 PM
> To: Charles Eckel (eckelcu); Tom Kristensen (tomkrist)
> I agree that description makes sense.  I thought I had recalled the IMTC
> document recommending that the floorid include a dangling mstrm, rather
> than no mstrm, but now I can't find it.
> 
> I interpret this to already account for the possibility of a floorid that is not
> yet associated with an existing media stream. Do you think we need to be
> more explicit? How about we extend the next paragraph as follows:
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 25 Oct 2012 11:43:54 -0400

Ah, that makes sense -- I noticed that figure was blank.

Presumably IMTC is going to update their documents once BFCPbis is done?  Hopefully they could update their recommendation to suggest an omitted mstrm rather than a dangling one.

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: Wednesday, October 24, 2012 11:07 AM
To: Jonathan Lennox; Tom Kristensen (tomkrist)
Cc: [email-masked]; Gonzalo Camarillo ([email-masked]); Robert Sparks ([email-masked])
Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt

Cheers,
Charles

> I agree that description makes sense.  I thought I had recalled the 
> IMTC document recommending that the floorid include a dangling mstrm, 
> rather than no mstrm, but now I can't find it.
> 
> I interpret this to already account for the possibility of a floorid 
> that is not yet associated with an existing media stream. Do you think 
> we need to be more explicit? How about we extend the next paragraph as follows:
> 
> > referencing the IMTC best practice document, it is available through 
> > a
> liaison statement at:
> > - 
> > However, I expect this IMTC document to be updated and made 
> > available externally once the BFCPBIS work completes, so I am not 
> > sure referencing it this way is appropriate.
> >
> > Thanks,
> > Charles
> >
> > > different vendors historically have had their own interpretation 
> > > of a best current practice.
> > >
> > > Anyway, it is not a big deal adding an informational note, if 
> > > people thinks that's a good idea, explaining that one may very 
> > > well meet an mstrm referring to a still undefined label.
> > >
> > > that if the SDP answer indicates that the peer understands both 
> > > BFCP and the SDP content attribute, a re-INVITE can be sent adding 
> > > an additional BFCP- controlled video stream with 
> > > "content:slides".)
> > > >
> > > >>> After checking out with the original author of RFC 4583, the 
> > > >>> ipr parameter is changed s/pre5378Trust200902/trust200902/.
> > > >>>
> > > >>> Cf.<URL:

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 25 Oct 2012 16:50:06 +0000

Yes, the plan is to update the document and make it publicly available following IETF standardization of the updated BFCP RFCs. 
As for removing the dangling mstrm, I will add it to the list of potential changes to incorporate into the update.

Cheers,
Charles
 
> Sent: Thursday, October 25, 2012 8:44 AM
> Presumably IMTC is going to update their documents once BFCPbis is done?
> Hopefully they could update their recommendation to suggest an omitted
> mstrm rather than a dangling one.
> 
> Your recollection is correct. Figure 5.2 of the IMTC document contains a call
> flow illustrating that exact usage; however, I see that figure 5.2 did not
> survive the MS Word to PDF conversion process and is therefore missing
> from the version of the document included in the liaison statement.
> 
> Cheers,
> Charles
>