Re: [codec] Format for the codec specification

[Jonas Svedberg <[e-mail]>]

Hi all

 If I understand Marshall's point correctly, the Trust Legal Provisions indicates something regarding publishing,   which is not completely clear in the current guidelines draft.

 
In the proposed guidelines <http://www.ietf.org/id/draft-valin-codec-guidelines-06.txt> page 10, it is now stated:

"  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. 
 
With this observation in mind it seems as the Guidelines publishing related section should be updated. 

--
 
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).  



//BR Jonas


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Marshall Eubanks
Sent: den 25 september 2010 21:52
To: Jean-Marc Valin
Cc: [e-mail]
Subject: Re: [codec] Format for the codec specification


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
> 

_______________________________________________
codec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/codec