Re: [codec] Format for the codec specification

>>>
   Normally, the decoder should be normative, which the encoder should not
be.
>>>
I think this is an assumption on your part.  Some groups in other SDOs make
the encoder normative as well.

Though I've never heard clear reasons, it seems to me that the
"decoder-only" folks are mostly focused on applications with a massive
encoder/decoder imbalance, while the "encoder and decoder" folks tend to be
focused on applications with equal numbers of encoder and decoders.  That
seems logical, since if there are relatively few encoders, it is easier to
solve any quality problems, and the content providers have very strong
financial incentives to do so.

So I am thinking that making the encoder normative makes sense, given that
this application is centered on VOIP, so we want to ensure consistent
quality in all endpoints.

Regards
Stephen Botzko

On Tue, Sep 28, 2010 at 8:51 PM, Jean-Marc Valin <
jean-marc.valin@usherbrooke.ca> wrote:

> 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
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>