On 22 Dec 2015, at 14:31, Ron wrote:
Yes, I think this probably needs to be changed to something more like
what IETF legal suggested for RFC 6716, granting "the right to
extract
sections 1 - 14 ...". This allows people to make liberal use of the
details in this document, but ensures they can't misrepresent any
such
use as somehow being an RFC.
Using the modified boilerplate from RFC 6716 would make more sense,
if this
document really needs it. But why does this document need it? It
doesn't
include code (normative or otherwise) like 6716. Or more to the
point, why
does this document need the extra grants more than any other
standards-track
RFC?
The crux here is twofold. We have organisations including, but not
limited to, Debian, who cannot distribute this included with an
implementation of it, unless it also grants people the right to
redistribute potentially modified versions of it. A restriction
which prevents people from claiming that a modified version is an
RFC is fine, but people need to be able to cut selected parts out
of it (possibly to include just selected parts in the documentation
of their own library or applications), and/or adapt them for other
purposes too.
But beyond that, this document itself cribbed as much as we could
from the work of other previous Ogg mappings, and includes things
which are more generally useful, like the channel mapping definitions
and the downmixing matrices, just to pick two.
So it's not unreasonable to think this may in turn be a base which
future work is built on, and in fact we'd encourage that, because
it's definitely good not to change things that aren't broken and
don't need changing for other future mappings.
We'd also encourage that work to ultimately end up in an IETF working
group too - but any initial work at least is quite likely to start
outside of one until things are proven enough to take that next step.
Ultimately, the rationale for this is actually almost identical to
6716, the only difference is 6716 created the weird situation where
the normative part *was* the code, and it was already covered by a
grant even more liberal than what we'd like for the descriptive text.
The alternative (which we discussed with Robert Sparks for 6716) is
the authors could publish a separate "this is not an RFC" version
outside of the IETF with the extra grants - but that didn't seem like
it would create less confusion than the solution IETF legal arrived
at - which seems pretty close to ideal for any document that might
be the basis for future or continuing work.
We don't want people to be claiming that modified versions are an RFC,
but we would like them to be able to reuse anything out of this that
it makes sense to, as freely as we can allow them to. Otherwise we
just artificially stifle further progress (or force everyone to turn
a blind eye when people do things we didn't explicitly grant them
the right to do - and that is the part I think we all share the desire
to avoid).
My question here is, why is this different for this draft than for any
other RFC? Are there no other RFCs that get distributed by Debian or
others with similar requirements? As you mention, RFC 6716 was unique in
the fact that the code _was_ the spec. This draft does not share that
property--so how is it different from any other standards-track RFC?
(As I just responded to Tim, I will not block IETF last call over this
particular issue, but I expect that there is more discussion to be had
before all is said and done.)
Thanks!
Ben.
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
