Re: [codec] Format for the codec specification

[Marshall Eubanks <[e-mail]>]

On Sep 24, 2010, at 4:37 PM, Jean-Marc Valin wrote:

> On 10-09-24 03:33 PM, Stephan Wenger wrote:
>> I also think we should make the code normative, as the speech codec people
>> commonly do for their bit-exact encoder/decoder specs.  However, someone
>> will have to explain to me how this can be done without requiring
>> bit-exactness.
> 
> There is no need to mandate bit-exactness. Many codecs are actually specified in floating-point. For example, if I'm not mistaken, the following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 (probably others). As far as I know, the spec says how much you can deviate from the float reference (not to mention that it's impossible to always be bit-exact with a float reference in the first place).
> 
>> If we were deciding to use code as the normative description, then I would
>> prefer to have that code ONLY in a single document.  It may be worthwhile to
>> consider zipping the source code directory, coding it in BASE64, and then
>> copy-pasting it into the RFC.  This way we could overcome many of the
>> shortcomings of putting a large software project into a printout format.  We
>> should check with the AD and the RFC editor first, how they view such a
>> submission.
> 
> I'm not against base64 encoding if the IETF will allow it. We could even have a C version of the base64 decoder to make sure that the RFC is "self-contained".
> 
>> Finally, it should be clear that the code RFC (as all RFCs) falls under the
>> IETF's copyright and patent policies.

Correct.

>>  As for the copyright part, people
>> should be aware that the IETF does not allow any other copyright notices but
>> its own in such an RFC.

Correct

>>  In other words, if the code maintainers want to
>> make the code available also under a non-IETF license (one of the open
>> source licenses, for example), they a) have to make sure that this license
>> allows for such dual licensing (GPL, for example, does IMO not),
> 
> The BSD license is compatible with the GPL, which means that it is OK, to take BSD code, modify it, and then slap a GPL license on top of the modified version (without removing the existing BSD license). In general, there are many cases of dual licensing involving the GPL. Also, note that the code we're talking about has been available under the BSD (and not the GPL) right from the start.

You are certainly free to do that on your own, but under the current Trust Legal Provisions

http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

the code on published RFCs has to have the BSD license.

Regards
Marshall


> 
> 	Jean-Marc
> 
>> and b)
>> remove the statements of this license from the code provided to the IETF,
>> and c) (depending on that license) remove the IETF license text from the
>> code provided to the open source repository.  Tedious, but doable, I think.
>> 
>> Stephan
>> 
>> 
>> 
>> 
>> 
>> 
>> On 9.24.2010 12:09 , "Jonathan Rosenberg"<[e-mail]>  wrote:
>> 
>>> One of the open issues we need to close on - and document in the
>>> guidelines specification - is what the format of our codec specification
>>> deliverable will be.
>>> 
>>> Firstly - one thing is clear - whatever the format is (code or textual
>>> descriptions) - it needs to be in an RFC. Including source code into an
>>> RFC is not ideal, but for purposes of IETF process that is the only
>>> thing we can officially produce. Participants can of course place that
>>> code in any repository they like, and we can even include a link to it
>>> in the RFC. However, the formal normative specification of the codec
>>> must be within a standards track RFC.
>>> 
>>> In terms of whether the specification is code, text, or both - we need
>>> to gain consensus on this. It is my understanding that source code is
>>> ultimately the most exact way to specify the codec. A detailed
>>> description is also included, and in case of conflict, the code would
>>> win. In IETF terms this means that the code is actually the normative
>>> specification.
>>> 
>>> iLBC includes the code itself in an appendix. As such, it would seem to
>>> make sense to follow this precedent. Thus, our deliverable would be a
>>> single document, containing a reasonably detailed codec description,
>>> along with an appendix containing the actual code.
>>> 
>>> Comments?
>>> 
>>> -Jonathan R.
>> 
>> 
>> _______________________________________________
>> codec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/codec
>> 
>> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>