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

["Charles Eckel (eckelcu)" <[e-mail]>]

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
 
> -----Original Message-----
> From: Jonathan Lennox [mailto:[e-mail]]
> Sent: Thursday, October 25, 2012 8:44 AM
> To: Charles Eckel (eckelcu); Tom Kristensen (tomkrist)
> Cc: [e-mail]; Gonzalo Camarillo ([e-mail])
> Robert Sparks ([e-mail])
> Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
> 
> 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:[e-mail]]
> Sent: Wednesday, October 24, 2012 11:07 AM
> To: Jonathan Lennox; Tom Kristensen (tomkrist)
> Cc: [e-mail]; Gonzalo Camarillo ([e-mail])
> Robert Sparks ([e-mail])
> Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
> 
> 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
> 
> > -----Original Message-----
> > From: Jonathan Lennox [mailto:[e-mail]]
> > Sent: Tuesday, October 23, 2012 2:43 PM
> > To: Charles Eckel (eckelcu); Tom Kristensen (tomkrist)
> > Cc: [e-mail]; Gonzalo Camarillo
> > ([e-mail]) Robert Sparks
> ([e-mail])
> > Subject: RE: [bfcpbis] I-D Action:
> > draft-ietf-bfcpbis-rfc4583bis-03.txt
> >
> > 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-im
> > > tc
> > > -
> > > 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/d
> > > > >>> ra
> > > > >>> ft-ietf-
> > > > bfcpbis-
> > > > >>> rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfc
> > > > >>> pb
> > > > >>> 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