Re: [codec] Format for the codec specification

[Jean-Marc Valin <[e-mail]>]

On 10-09-28 09:00 AM, Jonas Svedberg wrote:
> "  5.  In accordance with BCP 78 [TRUST], the source code for the
> reference implementation must be made available under a BSD-style
> license (or whatever license is defined as acceptable by the IETF
> Trust when the Internet-Draft defining the reference implementation
> is published)."
>
> To me it seems as the final point Marshall made: "the code on
> published RFCs has to have the BSD license."
>
> ,is a clearer and stricter wording than what is present in the
> current proposed guidelines, which uses the looser term "BSD-style",
> and further leaves other options open (in the parenthesis), and
> therefore makes the publishing directions in the guidelines quite
> unclear, to the developers.

I believe the current wording is based on Stephen Wenger's argument 
about "what if BCP78 were to specify a different license?" I don't have 
a strong opinion on this detail, you two can sort this out :-)

> With regard to  formats and publishing in general, is there any
> precedence in IETF of having, the WG output split into several
> entities/specs ? (e.g sending side/receiving side or
> impl.A-fix/impl.B-Float)
>
> e.g. One could imagine having the receiving side definitions
> specified in one RFC, and the sending side definitions as another
> RFC, or even leave the sending side unspecified within IETF(e.g. as
> a separate open source project, which would then mainly take care of
> sending side code maintenance, assuming that maintenance issues on
> the sending side are much more frequent than on the receiving side).

Normally, the decoder should be normative, which the encoder should not 
be. Technically, the RFC could contain only the decoder, though 
practically we need an encoder reference implementation. Since the 
encoder would likely not be normative, it would probably not be 
necessary to update the RFC for encoder-side improvements and the 
decoder is unlikely to change too much. Also, note that there's quite a 
bit of code that is shared between the encoder and decoder, fixed-point 
and floating point, so it would seem logical/simpler to have a single 
document here. But again, I don't have a strong opinion at this point.

Cheers,

	Jean-Marc