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

[Jonathan Lennox <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, October 23, 2012 2:17 PM
To: Tom Kristensen (tomkrist); Jonathan Lennox
Cc: [e-mail]; Gonzalo Camarillo ([e-mail]) Robert Sparks ([e-mail])
Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Charles Eckel (eckelcu)
> Sent: Thursday, October 18, 2012 1:33 PM
> To: Tom Kristensen (tomkrist); Jonathan Lennox
> Cc: [e-mail]; Gonzalo Camarillo 
> ([e-mail]) Robert Sparks ([e-mail])
> Subject: Re: [bfcpbis] I-D Action: 
> draft-ietf-bfcpbis-rfc4583bis-03.txt
> 
> 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
> 
> > -----Original Message-----
> > From: Tom Kristensen (tomkrist)
> > Sent: Wednesday, October 17, 2012 1:44 AM
> > To: Jonathan Lennox
> > Cc: Charles Eckel (eckelcu); [e-mail]
> > Subject: Re: [bfcpbis] I-D Action: 
> > draft-ietf-bfcpbis-rfc4583bis-03.txt
> >
> > 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:
> > > 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.
> > >
> > >
> > > On Oct 15, 2012, at 12:29 PM, Charles Eckel (eckelcu) wrote:
> > >
> > >
> > >> (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: [e-mail] [mailto:[e-mail]]
> On
> > >>> Behalf Of Tom Kristensen (tomkrist)
> > >>> Sent: Friday, October 12, 2012 5:02 AM
> > >>> To: [e-mail]
> > >>> Subject: Re: [bfcpbis] I-D Action: 
> > >>> draft-ietf-bfcpbis-rfc4583bis-03.txt
> > >>>
> > >>> On 10/12/2012 01:54 PM, [e-mail] 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
> > 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.
> > >>>>
> > >>>>
> > >>> 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/dra
> > >>> ft-ietf-
> > bfcpbis-
> > >>> rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpb
> > >>> is-
> > rfc4583bis-
> > >>> 03.txt
> > >>>
> > >>>>
> > >>> -- Tom
> > >>>
> > >>> _______________________________________________
> > >>> bfcpbis mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/bfcpbis
> > >>>
> > >> _______________________________________________
> > >> bfcpbis mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/bfcpbis
> > >>
> > >>
> > > --
> > > Jonathan Lennox
> > > [e-mail]
> > >
> > >
> > >
> 
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis