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

[Jonathan Lennox <[e-mail]>]

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