[bfcpbis] Documentation structure for bfcpbis

["DRAGE, Keith (Keith)" <[e-mail]>]

(As WG cochair)

I'd like to initiate some discussion on the documentation structure of what we want produce in the bfcpbis working group.

There have been a couple of comments on rolling into the existing BFCP RFC and we have at least a few options round here. Here at least are a few thoughts:

What
----

As a working group we have at least a couple of issues to address:

-	identify what we want in terms of compatibility with the existing BFCP (at the moment I am assuming that any new implementation would interoperate with the existing BFCP at least using TCP, but we have not had a discussion on that)

-	identify the best way of presenting the material that works for people doing completely new implementations versus thus updating existing implementations. 

If we need to be able to identify differences there are a number of ways of doing this including: 1) rely on the difference tools at tools.ietf.org and ensure that any WG output produces a true difference to the existing RFC, 2) carry forward any differences to the existing RFC in an annex or appendix (with the main body being the full text) and 3) keep the document solely as a difference document. There is of course a fourth option of ignoring identifying any differences at all.

When
----

We also have options in terms of when we change the document to whatever format we decide. We could do it immediately, or we could progress through the working group discussion and WGLC on the existing structure and only make the change at, for example, publication request. Doing the latter would focus the working group on changing only those bits that meet completing the immediate charter of the working group, but may be more difficult to work with. Doing the former may open up the working group to addressing a complete second edition, with any number of miscellaneous enhancements to the existing BFCP. 

RFC 4583
--------

The text we are working on also contains changes to RFC 4583 (currently owned by MMUSIC).

I am assuming that we would probably want to keep the current scope split (because MMUSIC need to review and agree any SDP changes), but would want to handle a bis version in the same manner as the main BFCP document. However the floor is open to discussion.

Discussion
----------

I'd like to give a period of time to discussion of the best way forward on the issues above, with the aim of identifying what options people do want on the table when I start a more formal consensus call in say a weeks time (or however long it takes the discussion to complete). 

So please put your views on the table as regard to what I written above, and also make sure that if you prefer something else, that you have identified it. Also if you think any approach is a non-starter, now would be good to identify it and we'll eliminate it from any consensus call (for reasons of keeping the final call simpler).

Regards

Keith

P.S. And just to repeat - none of this precludes raising any technical discussion on the document (as separate threads please).