From nobody Mon Jan 11 20:15:46 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4A71ACDCC; Mon, 11 Jan 2016 20:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiTDsD54IPCa; Mon, 11 Jan 2016 20:15:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C141ACDCB; Mon, 11 Jan 2016 20:15:43 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0C4FgVE012682 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 11 Jan 2016 22:15:42 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Mon, 11 Jan 2016 22:15:41 -0600 Message-ID: <3C70DFBA-2A88-4C61-9092-BDFC7B50D5BA@nostrum.com> In-Reply-To: <56813271.10309@xiph.org> References: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com> <566B4B47.9010809@xiph.org> <25D8812E-3CEF-41BB-A82D-1A4B0524F439@nostrum.com> <56813271.10309@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: codec@ietf.org, draft-ietf-codec-oggopus.all@ietf.org Subject: Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 04:15:45 -0000 Hi, more comments inline. I deleted sections that do not seem to need further discussion. Thanks! Ben. On 28 Dec 2015, at 7:00, Timothy B. Terriberry wrote: [...] >>>> What does it mean, in context, to "reject" headers? >>> >>> The same thing as rejecting a stream (i.e., don't try to play/decode >>> it). Changed to say that instead. >> >> Which "that"? > > To quote the attached diff: > > -Implementations SHOULD reject ID headers which do not contain enough > data for > - these fields, even if they contain a valid Magic Signature. > +Implementations SHOULD reject streams with ID headers that do not > contain > + enough data for these fields, even if they contain a valid Magic > Signature. I don't find that in the attached diff. > >> Maybe this is a conventional way to say things in the codec >> community, >> but when I see "reject" I usually think that means you generate some >> sort of error back to the source of the thing you reject. (As opposed >> to >> "ignore") > > Well, the most likely behavior here is to tell the user that the file > is not a valid Ogg Opus file, so your sense of "generating some sort > of error back" is in fact correct. But that makes some > application-level assumptions I'm not sure I'm comfortable writing > normative text around. Any ideas for a better way to phrase this? "treat as invalid"? > >> If this spec reserves those values, then people still need to update >> it >> to assign them. If you want to make it extensible, then perhaps it >> needs >> an IANA registry, which, depending on the assignment policy, may not >> require an RFC at all (seems like "expert review" or "specification >> required" might make sense). > > An IANA registry actually does not seem like a terrible idea. Reading > RFC 5226 it doesn't seem too hard to set one up. I attempted to draft > some text. > >> it's what our "UPDATES" process is for. The idea that you might want >> to >> informally experiment with different approaches is more convincing. >> But >> if that is the case, it would be helpful to have a sentence to that >> effect in the text. > > Okay, I will add one. That text looks good, except that I would avoid normative language: s/ "IANA SHALL..."/"IANA is requested to..." s/"All maintenance within and additions to the contents of this name space MUST be according"/"Modifications to this registry follow..." [...] > > >>> For the second, this is the same as the previous comment about >>> excessive allocations. I have no objection to changing this one, >>> either. >> >> I realize now there were 3 SHOULDs in that paragraph. I mean the one >> about avoiding excessive allocations. It sounds like > > You may have forgotten to complete your thought here. Apparently. I think I meant to delete "It sounds like". I think my original thought was about whether the SHOULD in "Demuxers SHOULD avoid attempting to allocate excessive amounts of memory when presented with a very large packet." should be a MUST or otherwise be explained. But on reflection, I think I am okay with that one. > >> Please consider saying something like "For more information on linear >> prediction, see [XXX]." As it's currently stated, it looks like it >> says >> MAY do X, where the reference specified X, which would require a >> normative reference. > > That's a good suggestion. Done. > >> That language is a bit of a problem for a standards track RFC. If >> people > > You mean the current text, or the actual text that wound up in RFC > 6716? Either, really. But obviously the 6716 was accepted, so it would be easier to accept due to precedent. The question I have is whether that precedent applies here. And you will recall that there was some tooth-gnashing over it for 6716 :-) > >> are really attached to it, we can pursue allowing it. But I expect >> objections down the line. Keep in mind "NOTE WELL" says that any >> contributions are subject to the rules of BCP 78 and 79. > > Yes, I think this has more to do with letting people use such > contributions _outside_ the context of the IETF (i.e., it grants > additional rights to those already granted in BCP 78 and 79, which I > understand is allowed). > > You are probably right about people objecting down the line (again), > but I am happy to address those objections when they come, as we did > for RFC 6716. > >> In any case, 6716 is a bit more code centric , so the discussion made >> more sense there. > > Well, from our point of view, the XML source for both RFCs is included > in the repository with libopus, which is distributed in Debian. If we > didn't have some kind of grant like this, they would have to somehow > strip those documents out. So it is not so much the code being in the > RFC as the draft being distributed with the code. I'm curious--are there no other RFCs distributed in Debian? > > In any case, I have attempted to draft an RFC Editor's note requesting > the same text that RFC 6716 used. Since that text grants a license > from the IETF Trust, instead of the authors, I assume that someone > from the Trust will have to approve of it, however (and reading > > it seems that the current opinion of the Trust is that this approach > is legally required). I'll let that (as updated) go to IETF LC. But don't be surprised if there's further discussion to be had here. > > I have also gone through and finished removing the 2119 language for > general Ogg requirements. > > The diff of all changes is attached. If these look good (or if it's > simply helps in reviewing them) I can publish a new version. From nobody Mon Jan 11 20:22:41 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40391ACDD8; Mon, 11 Jan 2016 20:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjL0l3M-3k86; Mon, 11 Jan 2016 20:22:39 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563301ACDD5; Mon, 11 Jan 2016 20:22:39 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0C4MX6x013287 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 11 Jan 2016 22:22:34 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Ron Date: Mon, 11 Jan 2016 22:22:33 -0600 Message-ID: <999EA7D6-FCD4-4E0C-8C0E-BD739B19A1C1@nostrum.com> In-Reply-To: <20151222203147.GY10797@hex.shelbyville.oz> References: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com> <566B4B47.9010809@xiph.org> <20151211235203.GN17678@hex.shelbyville.oz> <3D1E24B4-E9ED-42AF-A580-A024C25C3D2A@nostrum.com> <20151222203147.GY10797@hex.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: codec@ietf.org, draft-ietf-codec-oggopus.all@ietf.org Subject: Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 04:22:41 -0000 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. From nobody Tue Jan 12 12:18:05 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB521A8861; Tue, 12 Jan 2016 12:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL6MYwqSJHs8; Tue, 12 Jan 2016 12:18:00 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8B11A885F; Tue, 12 Jan 2016 12:17:59 -0800 (PST) Received: from ppp14-2-93-56.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.93.56]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Jan 2016 06:47:58 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id C28FEFFC76; Wed, 13 Jan 2016 06:47:57 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HCW5REN0XTGh; Wed, 13 Jan 2016 06:47:56 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id D0AB4FFAB9; Wed, 13 Jan 2016 06:47:56 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id BB5AC80470; Wed, 13 Jan 2016 06:47:56 +1030 (ACDT) Date: Wed, 13 Jan 2016 06:47:56 +1030 From: Ron To: Ben Campbell Message-ID: <20160112201756.GN10797@hex.shelbyville.oz> References: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com> <566B4B47.9010809@xiph.org> <20151211235203.GN17678@hex.shelbyville.oz> <3D1E24B4-E9ED-42AF-A580-A024C25C3D2A@nostrum.com> <20151222203147.GY10797@hex.shelbyville.oz> <999EA7D6-FCD4-4E0C-8C0E-BD739B19A1C1@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <999EA7D6-FCD4-4E0C-8C0E-BD739B19A1C1@nostrum.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: codec@ietf.org, draft-ietf-codec-oggopus.all@ietf.org Subject: Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 20:18:04 -0000 On Mon, Jan 11, 2016 at 10:22:33PM -0600, Ben Campbell wrote: > 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? I think there's sort of two questions embedded in that, both of which are relevant and important, but only one of which is sort of in the scope for this WG to address (which doesn't mean I wouldn't like to also see the other addressed in whatever is the right scope for it :) *What* is different, is that the authors are very conscious of this problem and would very much like to avoid having this RFC caught up in it, in whatever the best way we might do that would be. That seems like a discussion we can reasonably have here (though of course it won't end here, it still needs broader approval too). *How* this is document is different from other RFCs, is a somewhat bigger can of worms. Because I do actually think that a lot of other RFCs would stand to benefit from something like this too. The only ones that maybe wouldn't, would be documents in the mold of "here's some arbitrary proclamation, that's necessary for interop, but that there really isn't any scope at all for further development or research on, unless we find a reason to make an updated arbitrary proclamation on this later". But I'd tend to think they are probably in the minority, and most non-trivial RFCs would be open to further research, possibly initially outside of the IETF before that research is proven enough to then be formalised for wider use on one of the RFC tracks. For things like that, I think the interesting question is why should the IETF prohibit that work by default (or only permit it by everyone turning a blind eye to breaches of the licencing provisions that were granted). That is a discussion I'd like to have, but here doesn't seem to be the right place to have it. Nutting through the details for this particular draft though might be helpful to that process. If only to establish where the right bounds may be, and give everyone some experience that the world doesn't end and chaos doesn't reign if we do this. > Are there no other RFCs that get distributed by Debian or others with > similar requirements? There are some other RFCs which can be and are distributed by people in this position. But what those have in common is they *all* have some extra grant permitted in their text to make that possible. The big difference that occurred with 6716, was that rather than adding an arbitrary clause somewhere in the text (which tends to be a bit different if not substantively similar in each document), IETF legal approved some alternative header boilerplate, which I do think is a big improvement. Having a standard grant for this makes it a lot easier for everyone to know where they stand, and for the IETF itself to issue a later clarification of its position if some unforeseen corner case should ever make that necessary. Debian definitely isn't the only user affected by this, but they do make a reasonably good John Doe that we can discuss specific details around. > 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? I don't think that's actually the important property of 6716 which gave adding this grant to it real value. The important part was that there was a reasonable expectation other users would want to publish all or some of it in contexts which the standard grant would otherwise prohibit. As another example, it might be impossible for me to use parts of that text, or even the whole document, in a GPL licenced work (in any way more than just "mere aggregation"), since the added restrictions could be in conflict with the GPL's licence conditions (which mandate no additional restrictions), and the resulting work would be undistributable by anyone who took respecting licences seriously. There's a big can of worms all its own in that example, so again, it's better considered as a poster child for a class of problems we'd be wise to avoid than a specific individual exception that needs to be singled out for special treatment. In 6716 we just had the added paradox of the normative part of the spec already having a liberal licence grant, while the informative parts of it did not without the extra grant. > (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.) Nod. I quite expect there will be too :) But I think it is a useful thing for us to inch toward some sort of broader consensus on, that takes everyone's concerns and use cases and fears into account. I think in some ways, part of the crux of the problem is that historically many of the participants have come from corporate backgrounds, where the default legal presumption is to prohibit as much as you think you can get away with prohibiting, to the point of actually outlawing things you do expect and want your users to do, but then ignoring widespread breaches of that unless someone crosses some line you don't like, in which case you have the biggest possible bag of ammo for your lawyers to fire at them. But that kind of falls down when you have organisations that do take such licence grants seriously, and don't ignore "inconvenient" parts of them to use them anyway in contravention of what was actually allowed. In the context of this draft, we *want* people to be able to use it. And personally, I'd much rather have them quote parts of it verbatim, modified to fit coherently into their own documentation, than have them paraphrase those parts of it to avoid the legal restriction - possibly introducing new ambiguities or misunderstandings, which may then become quoted even more widely than the original RFC, simply because people are allowed to reproduce that error in their own work, but aren't allowed to quote or redistribute the RFC directly ... That outcome seems fairly directly counterproductive to what we want to achieve by having a formal standard that we'd like everyone to follow. We'd have a kind of SDO version of Gresham's Law undermining the value and currency of the words we worked so hard to choose carefully here. The aim here is not to dilute the IETF's authority over this document, but to give that authority the greatest possible value we can. These are all good questions to ask though, and I would like to see this bubble up into some good answers the IETF can build consensus on. Cheers, Ron From nobody Tue Jan 12 13:17:21 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF31A88D6; Tue, 12 Jan 2016 13:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.292 X-Spam-Level: X-Spam-Status: No, score=-4.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkpgt_6b5qul; Tue, 12 Jan 2016 13:17:16 -0800 (PST) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557CD1A88D5; Tue, 12 Jan 2016 13:17:16 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id CC582C1279; Tue, 12 Jan 2016 21:17:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86UsW7gPGjAe; Tue, 12 Jan 2016 21:17:15 +0000 (UTC) Received: from [10.252.27.21] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id AB872C05EA; Tue, 12 Jan 2016 21:17:15 +0000 (UTC) Message-ID: <56956D5B.4010008@xiph.org> Date: Tue, 12 Jan 2016 13:17:15 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 References: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com> <566B4B47.9010809@xiph.org> <25D8812E-3CEF-41BB-A82D-1A4B0524F439@nostrum.com> <56813271.10309@xiph.org> <3C70DFBA-2A88-4C61-9092-BDFC7B50D5BA@nostrum.com> In-Reply-To: <3C70DFBA-2A88-4C61-9092-BDFC7B50D5BA@nostrum.com> Content-Type: multipart/mixed; boundary="------------030009060302080505000308" Archived-At: Cc: "codec@ietf.org" , draft-ietf-codec-oggopus.all@ietf.org Subject: Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:17:20 -0000 This is a multi-part message in MIME format. --------------030009060302080505000308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Ben Campbell wrote: >> To quote the attached diff: >> >> -Implementations SHOULD reject ID headers which do not contain enough >> data for >> - these fields, even if they contain a valid Magic Signature. >> +Implementations SHOULD reject streams with ID headers that do not >> contain >> + enough data for these fields, even if they contain a valid Magic >> Signature. > > I don't find that in the attached diff. I meant the one that was attached to the e-mail to which you were responding: https://www.ietf.org/mail-archive/web/codec/current/msg03150.html Sorry for being unclear. >> application-level assumptions I'm not sure I'm comfortable writing >> normative text around. Any ideas for a better way to phrase this? > > "treat as invalid"? I can work with that. > That text looks good, except that I would avoid normative language: > > s/ "IANA SHALL..."/"IANA is requested to..." > s/"All maintenance within and additions to the contents of this name > space MUST be according"/"Modifications to this registry follow..." Normative language removed. > Either, really. But obviously the 6716 was accepted, so it would be > easier to accept due to precedent. The question I have is whether that > precedent applies here. And you will recall that there was some > tooth-gnashing over it for 6716 :-) I remember. I think the precedent does apply, since the issue is including the RFC with the code package, not whether or not the RFC itself contains code. > I'm curious--are there no other RFCs distributed in Debian? Ron may have a better idea of real numbers, but it is certainly an issue that has come up before. See , which links to a list of bugreports. As Ron points out, there are a few RFCs that are distributed because they included additional grants (after which the original grants in draft-ietf-codec-opus and this draft were modeled). It does not appear as if that page has been updated since RFC 6716 was published, though. > I'll let that (as updated) go to IETF LC. But don't be surprised if > there's further discussion to be had here. I fully expect it. Additional changes for the above attached. If there are no more comments, I can publish a new version with all of these included. --------------030009060302080505000308 Content-Type: text/x-patch; name="0001-oggopus-Replace-reject-with-treat-as-invalid.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-oggopus-Replace-reject-with-treat-as-invalid.patch" >From 451cc67936db4220038221aff684be8c617c751a Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Tue, 12 Jan 2016 13:08:27 -0800 Subject: [PATCH 1/2] oggopus: Replace 'reject' with 'treat as invalid'. >From AD review. --- doc/draft-ietf-codec-oggopus.xml | 48 ++++++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index 7489c20..b343e42 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -507,27 +507,27 @@ This does not affect the behavior of pre-skip: exactly 'pre-skip' samples initial PCM sample position is greater than zero. On the other hand, a granule position that is smaller than the number of decoded samples prevents a demuxer from working backwards to assign each packet or each individual sample a valid granule position, since granule positions are non-negative. -An implementation MUST reject as invalid any stream where the granule position +An implementation MUST treat any stream as invalid if the granule position is smaller than the number of samples contained in packets that complete on the first audio data page with a completed packet, unless that page has the 'end of stream' flag set. It MAY defer this action until it decodes the last packet completed on that page. -If that page has the 'end of stream' flag set, a demuxer MUST reject as invalid - any stream where its granule position is smaller than the 'pre-skip' amount. +If that page has the 'end of stream' flag set, a demuxer MUST treat any stream + as invalid if its granule position is smaller than the 'pre-skip' amount. This would indicate that there are more samples to be skipped from the initial decoded output than exist in the stream. If the granule position is smaller than the number of decoded samples produced by the packets that complete on that page, then a demuxer MUST use an initial granule position of '0', and can work forwards from '0' to timestamp individual packets. If the granule position is larger than the number of decoded samples available, then the demuxer MUST still work backwards as described above, even if the @@ -751,23 +751,24 @@ Its contents are specified in . All fields in the ID headers are REQUIRED, except for the channel mapping table, which MUST be omitted when the channel mapping family is 0, but is REQUIRED otherwise. -Implementations SHOULD reject streams with ID headers that do not contain - enough data for these fields, even if they contain a valid Magic Signature. +Implementations SHOULD treat a stream as invalid if it contains an ID header + that does not have enough data for these fields, even if it contain a valid + Magic Signature. Future versions of this specification, even backwards-compatible versions, might include additional fields in the ID header. If an ID header has a compatible major version, but a larger minor version, - an implementation MUST NOT reject it for containing additional data not - specified here, provided it still completes on the first page. + an implementation MUST NOT treat it as invalid for containing additional data + not specified here, provided it still completes on the first page.
An Ogg Opus stream allows mapping one number of Opus streams (N) to a possibly larger number of decoded channels (M + N) to yet another number of output channels (C), which might be larger or smaller than the number of decoded channels. @@ -1180,19 +1181,20 @@ This field contains a single user comment string. There is one for each user comment indicated by the 'user comment list length' field. The vendor string length and user comment list length are REQUIRED, and - implementations SHOULD reject comment headers that do not contain enough data - for these fields, or that do not contain enough data for the corresponding - vendor string or user comments they describe. + implementations SHOULD treat a stream as invalid if it contains a comment + header that does not have enough data for these fields, or that does not + contain enough data for the corresponding vendor string or user comments they + describe. Making this check before allocating the associated memory to contain the data helps prevent a possible Denial-of-Service (DoS) attack from small comment headers that claim to contain strings longer than the entire packet or more user comments than than could possibly fit in the packet. Immediately following the user comment list, the comment header MAY @@ -1205,19 +1207,20 @@ This allows informal experimentation with the format of this binary data until it can be specified later. The comment header can be arbitrarily large and might be spread over a large number of Ogg pages. Implementations MUST avoid attempting to allocate excessive amounts of memory when presented with a very large comment header. -To accomplish this, implementations MAY reject a comment header larger than - 125,829,120 octets, and MAY ignore individual comments that are not fully - contained within the first 61,440 octets of the comment header. +To accomplish this, implementations MAY treat a stream as invalid if it has a + comment header larger than 125,829,120 octets, and MAY ignore individual + comments that are not fully contained within the first 61,440 octets of + the comment header.
The user comment strings follow the NAME=value format described by with the same recommended tag names: ARTIST, TITLE, DATE, ALBUM, and so on. @@ -1294,28 +1297,29 @@ In the authors' investigations they were not applied consistently or broadly Technically, valid Opus packets can be arbitrarily large due to the padding format, although the amount of non-padding data they can contain is bounded. These packets might be spread over a similarly enormous number of Ogg pages. When encoding, implementations SHOULD limit the use of padding in audio data packets to no more than is necessary to make a variable bitrate (VBR) stream constant bitrate (CBR), unless they have no reasonable way to determine what is necessary. -Demuxers SHOULD reject audio data packets (treat them as if they were malformed - Opus packets with an invalid TOC sequence) larger than 61,440 octets per - Opus stream, unless they have a specific reason for allowing extra padding. +Demuxers SHOULD treat audio data packets as invalid (treat them as if they were + malformed Opus packets with an invalid TOC sequence) if they are larger than + 61,440 octets per Opus stream, unless they have a specific reason for + allowing extra padding. Such packets necessarily contain more padding than needed to make a stream CBR. Demuxers MUST avoid attempting to allocate excessive amounts of memory when presented with a very large packet. -Demuxers MAY reject or partially process audio data packets larger than - 61,440 octets in an Ogg Opus stream with channel mapping families 0 - or 1. -Demuxers MAY reject or partially process audio data packets in any Ogg Opus - stream if the packet is larger than 61,440 octets and also larger than - 7,680 octets per Opus stream. +Demuxers MAY treat audio data packets as invalid or partially process them if + they are larger than 61,440 octets in an Ogg Opus stream with channel + mapping families 0 or 1. +Demuxers MAY treat audio data packets as invalid or partially process them in + any Ogg Opus stream if the packet is larger than 61,440 octets and also + larger than 7,680 octets per Opus stream. The presence of an extremely large packet in the stream could indicate a memory exhaustion attack or stream corruption. In an Ogg Opus stream, the largest possible valid packet that does not use padding has a size of (61,298*N - 2) octets. With 255 streams, this is 15,630,988 octets and can span up to 61,298 Ogg pages, all but one of which will have a granule -- 1.8.3.2 --------------030009060302080505000308 Content-Type: text/x-patch; name="0002-oggopus-Remove-normative-language-from-IANA-registry.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0002-oggopus-Remove-normative-language-from-IANA-registry.pa"; filename*1="tch" >From db33abdc906978dae74c7b2c54494b4a9c46707f Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Tue, 12 Jan 2016 13:12:22 -0800 Subject: [PATCH 2/2] oggopus: Remove normative language from IANA registry. >From AD review. --- doc/draft-ietf-codec-oggopus.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index b343e42..05bdae1 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -1546,20 +1546,20 @@ This document updates the IANA Media Types registry to add .opus as a file extension for "audio/ogg", and to add itself as a reference alongside for "audio/ogg", "video/ogg", and "application/ogg" Media Types. This document defines a new registry "Opus Channel Mapping Families" to indicate how the semantic meanings of the channels in a multi-channel Opus stream are described. -IANA SHALL create a new name space of "Opus Channel Mapping Families". -All maintenance within and additions to the contents of this name space MUST be - according to the "Specification Requried with Expert Review" registration - policy as defined in . +IANA is requested to create a new name space of "Opus Channel Mapping + Families". +Modifications to this registry follow the "Specification Requried with Expert + Review" registration policy as defined in . Each registry entry consists of a Channel Mapping Family Number, which is specified in decimal in the range 0 to 255, inclusive, and a Reference (or list of references) Each Reference must point to sufficient documentation to describe what information is coded in the Opus identification header for this channel mapping family, how a demuxer determines the Stream Count ('N') and Coupled Stream Count ('M') from this information, and how it determines the proper interpretation of each of the decoded channels. -- 1.8.3.2 --------------030009060302080505000308-- From nobody Tue Jan 12 13:29:17 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241BB1A8987; Tue, 12 Jan 2016 13:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6s6_02OSGMp; Tue, 12 Jan 2016 13:29:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0811A8984; Tue, 12 Jan 2016 13:29:14 -0800 (PST) Received: from [10.10.1.2] ([162.216.46.43]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0CLTAh4070516 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 12 Jan 2016 15:29:12 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.43] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Tue, 12 Jan 2016 15:29:10 -0600 Message-ID: <43A9939D-13B3-478E-84CB-DB56B37793B2@nostrum.com> In-Reply-To: <56956D5B.4010008@xiph.org> References: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com> <566B4B47.9010809@xiph.org> <25D8812E-3CEF-41BB-A82D-1A4B0524F439@nostrum.com> <56813271.10309@xiph.org> <3C70DFBA-2A88-4C61-9092-BDFC7B50D5BA@nostrum.com> <56956D5B.4010008@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "codec@ietf.org" , draft-ietf-codec-oggopus.all@ietf.org Subject: Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:29:16 -0000 There's a typo in "specification required". Otherwise, It think it's probably ready for IETF last call. Please submit when you are ready. Thanks! Ben. On 12 Jan 2016, at 15:17, Timothy B. Terriberry wrote: > Ben Campbell wrote: >>> To quote the attached diff: >>> >>> -Implementations SHOULD reject ID headers which do not contain >>> enough >>> data for >>> - these fields, even if they contain a valid Magic Signature. >>> +Implementations SHOULD reject streams with ID headers that do not >>> contain >>> + enough data for these fields, even if they contain a valid Magic >>> Signature. >> >> I don't find that in the attached diff. > > I meant the one that was attached to the e-mail to which you were > responding: > https://www.ietf.org/mail-archive/web/codec/current/msg03150.html > > Sorry for being unclear. > >>> application-level assumptions I'm not sure I'm comfortable writing >>> normative text around. Any ideas for a better way to phrase this? >> >> "treat as invalid"? > > I can work with that. > >> That text looks good, except that I would avoid normative language: >> >> s/ "IANA SHALL..."/"IANA is requested to..." >> s/"All maintenance within and additions to the contents of this name >> space MUST be according"/"Modifications to this registry follow..." > > Normative language removed. > >> Either, really. But obviously the 6716 was accepted, so it would be >> easier to accept due to precedent. The question I have is whether >> that >> precedent applies here. And you will recall that there was some >> tooth-gnashing over it for 6716 :-) > > I remember. I think the precedent does apply, since the issue is > including the RFC with the code package, not whether or not the RFC > itself contains code. > >> I'm curious--are there no other RFCs distributed in Debian? > > Ron may have a better idea of real numbers, but it is certainly an > issue that has come up before. See > , which links to a list > of bugreports. As Ron points out, there are a few RFCs that are > distributed because they included additional grants (after which the > original grants in draft-ietf-codec-opus and this draft were modeled). > It does not appear as if that page has been updated since RFC 6716 was > published, though. > >> I'll let that (as updated) go to IETF LC. But don't be surprised if >> there's further discussion to be had here. > > I fully expect it. > > Additional changes for the above attached. If there are no more > comments, I can publish a new version with all of these included. From nobody Tue Jan 12 13:41:20 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AF51A8A28; Tue, 12 Jan 2016 13:41:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112214118.6138.71102.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 13:41:18 -0800 Archived-At: Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-10.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:41:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Authors : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-10.txt Pages : 33 Date : 2016-01-12 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-codec-oggopus-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-oggopus-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 13:41:56 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B941A8A4A; Tue, 12 Jan 2016 13:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlAz4RkL6en0; Tue, 12 Jan 2016 13:41:54 -0800 (PST) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F186B1A8A29; Tue, 12 Jan 2016 13:41:53 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 8EABEC26E8; Tue, 12 Jan 2016 21:41:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaniB06gbaDM; Tue, 12 Jan 2016 21:41:53 +0000 (UTC) Received: from [10.252.27.21] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 78E8CC0694; Tue, 12 Jan 2016 21:41:53 +0000 (UTC) Message-ID: <56957321.2050602@xiph.org> Date: Tue, 12 Jan 2016 13:41:53 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Ben Campbell References: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com> <566B4B47.9010809@xiph.org> <25D8812E-3CEF-41BB-A82D-1A4B0524F439@nostrum.com> <56813271.10309@xiph.org> <3C70DFBA-2A88-4C61-9092-BDFC7B50D5BA@nostrum.com> <56956D5B.4010008@xiph.org> <43A9939D-13B3-478E-84CB-DB56B37793B2@nostrum.com> In-Reply-To: <43A9939D-13B3-478E-84CB-DB56B37793B2@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "codec@ietf.org" , draft-ietf-codec-oggopus.all@ietf.org Subject: Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:41:55 -0000 Ben Campbell wrote: > There's a typo in "specification required". Otherwise, It think it's > probably ready for IETF last call. Please submit when you are ready. Thanks. Fixed and posted. From nobody Wed Jan 13 06:15:07 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABED11A8029; Wed, 13 Jan 2016 06:15:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> Date: Wed, 13 Jan 2016 06:15:06 -0800 Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 14:15:06 -0000 The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Ogg Encapsulation for the Opus Audio Codec' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Please note that the document makes normative references to RFCs 3533 and 4732, which are informational. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 27 12:44:52 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F1C1A92AF; Wed, 27 Jan 2016 12:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xDVTt7BiqBR; Wed, 27 Jan 2016 12:44:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74B91A92AE; Wed, 27 Jan 2016 12:44:44 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0RKifMh095157 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 27 Jan 2016 14:44:42 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: ietf@ietf.org References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> From: Robert Sparks Message-ID: <56A92C39.7060206@nostrum.com> Date: Wed, 27 Jan 2016 14:44:41 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020605090608080804020909" Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 20:44:47 -0000 This is a multi-part message in MIME format. --------------020605090608080804020909 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit This document has an unusual feature that I think needs to be highlighted in this last call. Section 13 instructs the RFC editor to: > In the Copyright Notice at the start of the document, the following > paragraph is to be appended after the regular copyright notice text: > > "The licenses granted by the IETF Trust to this RFC under Section 3.c > of the Trust Legal Provisions shall also include the right to extract > text from Sections 1 through 14 of this RFC and create derivative > works from these extracts, and to copy, publish, display, and > distribute such derivative works in any medium and for any purpose, > provided that no such derivative work shall be presented, displayed, > or published in a manner that states or implies that it is part of > this RFC or any other IETF Document." I understand why we did what we did for RFC6716 (the specification for OPUS, where the additional grants were to deal with the code being normative). I do not think it is the right thing to do for this document. It would have been better if the document, or the shepherd's writeup, spelled this issue out. For now, Ron's message at is a good place to start - scroll down to the section starting "The crux here is twofold." RjS On 1/13/16 8:15 AM, The IESG wrote: > The IESG has received a request from the Internet Wideband Audio Codec WG > (codec) to consider the following document: > - 'Ogg Encapsulation for the Opus Audio Codec' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-01-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines the Ogg encapsulation for the Opus interactive > speech and audio codec. This allows data encoded in the Opus format > to be stored in an Ogg logical bitstream. > > Please note that the document makes normative references to RFCs 3533 and 4732, which are informational. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > --------------020605090608080804020909 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit This document has an unusual feature that I think needs to be highlighted in this last call.

Section 13 instructs the RFC editor to:
   In the Copyright Notice at the start of the document, the following
   paragraph is to be appended after the regular copyright notice text:

   "The licenses granted by the IETF Trust to this RFC under Section 3.c
   of the Trust Legal Provisions shall also include the right to extract
   text from Sections 1 through 14 of this RFC and create derivative
   works from these extracts, and to copy, publish, display, and
   distribute such derivative works in any medium and for any purpose,
   provided that no such derivative work shall be presented, displayed,
   or published in a manner that states or implies that it is part of
   this RFC or any other IETF Document."
I understand why we did what we did for RFC6716 (the specification for OPUS, where the additional grants were to deal with the code being normative).

I do not think it is the right thing to do for this document.

It would have been better if the document, or the shepherd's writeup, spelled this issue out. For now, Ron's message at <https://mailarchive.ietf.org/arch/msg/codec/5pl4RhroYqB9vLRnOyeIKOC8lkA> is a good place to start - scroll down to the section starting "The crux here is twofold."

RjS




On 1/13/16 8:15 AM, The IESG wrote:
The IESG has received a request from the Internet Wideband Audio Codec WG
(codec) to consider the following document:
- 'Ogg Encapsulation for the Opus Audio Codec'
  <draft-ietf-codec-oggopus-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-01-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines the Ogg encapsulation for the Opus interactive
   speech and audio codec.  This allows data encoded in the Opus format
   to be stored in an Ogg logical bitstream.

Please note that the document makes normative references to RFCs 3533 and 4732, which are informational.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/


No IPR declarations have been submitted directly on this I-D.

--------------020605090608080804020909-- From nobody Wed Jan 27 13:09:53 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9877C1ACE03; Wed, 27 Jan 2016 13:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSplbYaF2ejH; Wed, 27 Jan 2016 13:09:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA83A1ACDFB; Wed, 27 Jan 2016 13:09:49 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0RL9lwq097400 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2016 15:09:47 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Robert Sparks" Date: Wed, 27 Jan 2016 15:09:47 -0600 Message-ID: In-Reply-To: <56A92C39.7060206@nostrum.com> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, ietf@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 21:09:51 -0000 On 27 Jan 2016, at 14:44, Robert Sparks wrote: > This document has an unusual feature that I think needs to be > highlighted in this last call. > > Section 13 instructs the RFC editor to: >> In the Copyright Notice at the start of the document, the following >> paragraph is to be appended after the regular copyright notice text: >> >> "The licenses granted by the IETF Trust to this RFC under Section 3.c >> of the Trust Legal Provisions shall also include the right to extract >> text from Sections 1 through 14 of this RFC and create derivative >> works from these extracts, and to copy, publish, display, and >> distribute such derivative works in any medium and for any purpose, >> provided that no such derivative work shall be presented, displayed, >> or published in a manner that states or implies that it is part of >> this RFC or any other IETF Document." > I understand why we did what we did for RFC6716 (the specification for > OPUS, where the additional grants were to deal with the code being > normative). For the record, the rights grant in RFC 6716 covered the textual parts in addition to the code parts. Given that the code components are already covered by the BSD licensing option in the TLP, this seems mainly relevant to the textual parts. I don't mean to refer to that as precedent; only to suggest that if people think it's not appropriate now, it might not have been a good idea then either. > > I do not think it is the right thing to do for this document. > > It would have been better if the document, or the shepherd's writeup, > spelled this issue out. For now, Ron's message at > > is a good place to start - scroll down to the section starting "The > crux here is twofold." Thanks for spelling it out now :-) > > RjS > > > > > On 1/13/16 8:15 AM, The IESG wrote: >> The IESG has received a request from the Internet Wideband Audio >> Codec WG >> (codec) to consider the following document: >> - 'Ogg Encapsulation for the Opus Audio Codec' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the >> ietf@ietf.org mailing lists by 2016-01-27. Exceptionally, comments >> may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document defines the Ogg encapsulation for the Opus interactive >> speech and audio codec. This allows data encoded in the Opus format >> to be stored in an Ogg logical bitstream. >> >> Please note that the document makes normative references to RFCs 3533 >> and 4732, which are informational. >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> From nobody Thu Jan 28 10:39:06 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA401B2F6D; Thu, 28 Jan 2016 10:39:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128183904.8076.80585.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 10:39:04 -0800 Archived-At: Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 18:39:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Authors : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-11.txt Pages : 33 Date : 2016-01-28 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-codec-oggopus-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-oggopus-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 28 12:24:00 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542F11ACEBE; Thu, 28 Jan 2016 12:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qcIyun87rMB; Thu, 28 Jan 2016 12:23:56 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3BC1ACE9A; Thu, 28 Jan 2016 12:23:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 30237246737; Thu, 28 Jan 2016 12:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454012636; bh=eglun2p8fvrbr/VtreOtJQAE3piWVC6QRTCsIzeNpL0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UfZUibvd6ZdV92eW0ByILEdF00aQUpoPkLSRo+lV7ILKBPx3SRryUxwFBUGD5nZuv ROLdsfHIezZMYHz71y1cTxSsQ5+4T0A/8A8HnYxKBcWQnK5fXYttgqckQ+w6k+Viyv Y1NAhiaQ6nu7KUW1ladHudhCO6+2HilmTCAmzAXg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6C27C2405F3; Thu, 28 Jan 2016 12:23:55 -0800 (PST) To: Ben Campbell References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> From: "Joel M. Halpern" Message-ID: <56AA78C9.9030304@joelhalpern.com> Date: Thu, 28 Jan 2016 15:23:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-codec-oggopus@ietf.org, codec-chairs@ietf.org, codec@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:23:58 -0000 I think that this is a very bad idea. The point of doing the work to create an RFC is to reach agreements on what the words should be. Saying after that "oh, but anyone else can change these words any way they want" just does not work for me. More generally, I think we need to establish that this is not how we work, rather than letting folks do this more and more often. In terms of documentation, I am actually very concerned with this apparent effort for us to support documenting of protocols and behaviors that do not comply with the RFC. That is not our purpose. Yours, Joel On 1/27/16 4:09 PM, Ben Campbell wrote: > On 27 Jan 2016, at 14:44, Robert Sparks wrote: > >> This document has an unusual feature that I think needs to be >> highlighted in this last call. >> >> Section 13 instructs the RFC editor to: >>> In the Copyright Notice at the start of the document, the following >>> paragraph is to be appended after the regular copyright notice text: >>> >>> "The licenses granted by the IETF Trust to this RFC under Section 3.c >>> of the Trust Legal Provisions shall also include the right to extract >>> text from Sections 1 through 14 of this RFC and create derivative >>> works from these extracts, and to copy, publish, display, and >>> distribute such derivative works in any medium and for any purpose, >>> provided that no such derivative work shall be presented, displayed, >>> or published in a manner that states or implies that it is part of >>> this RFC or any other IETF Document." >> I understand why we did what we did for RFC6716 (the specification for >> OPUS, where the additional grants were to deal with the code being >> normative). > > For the record, the rights grant in RFC 6716 covered the textual parts > in addition to the code parts. Given that the code components are > already covered by the BSD licensing option in the TLP, this seems > mainly relevant to the textual parts. > > I don't mean to refer to that as precedent; only to suggest that if > people think it's not appropriate now, it might not have been a good > idea then either. > >> >> I do not think it is the right thing to do for this document. >> >> It would have been better if the document, or the shepherd's writeup, >> spelled this issue out. For now, Ron's message at >> >> is a good place to start - scroll down to the section starting "The >> crux here is twofold." > > Thanks for spelling it out now :-) > >> >> RjS >> >> >> >> >> On 1/13/16 8:15 AM, The IESG wrote: >>> The IESG has received a request from the Internet Wideband Audio >>> Codec WG >>> (codec) to consider the following document: >>> - 'Ogg Encapsulation for the Opus Audio Codec' >>> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2016-01-27. Exceptionally, comments >>> may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document defines the Ogg encapsulation for the Opus interactive >>> speech and audio codec. This allows data encoded in the Opus format >>> to be stored in an Ogg logical bitstream. >>> >>> Please note that the document makes normative references to RFCs 3533 >>> and 4732, which are informational. >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> > > From nobody Thu Jan 28 12:59:18 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC71AD2C4 for ; Thu, 28 Jan 2016 12:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n149mo1-zFO8 for ; Thu, 28 Jan 2016 12:59:14 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489171AD28D for ; Thu, 28 Jan 2016 12:59:14 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id o6so16546460qkc.2 for ; Thu, 28 Jan 2016 12:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=jkb9q7Nd0lQ7ij4SSyVkdS7NejAM/zhlkMK3mlV6zCU=; b=e0/77VGDeQPyI0d4CWVvitGDwUUqVeX+87xlxSzoeV+/7YMiY8Uz243RdS7EVm4/MX iw41iqoeS2I8isJgNQT91L9WNN0oLmXJwP9yPH7wvXHWWhlIlZyCo4YhHDHrzls3AAuH fyPUamNg1JWfvyShk1Y2xfbffTAdwX0xqf3XmXybtWQYKtBZZoDF6WfEc0XgNDDH4ktG ooaxC7IEOuxWb9NHa1wuIkzL1X2DRlSRd5ic7G1g9o/2hr48/obYB8eyShfOCCmfPWjU Cs67C7Uhla8dj7Vhj/CG7RxLzyMZtulf3I5ukDKnoFhsT/PlEoWafzgEswVXk1hUm8tU I9Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=jkb9q7Nd0lQ7ij4SSyVkdS7NejAM/zhlkMK3mlV6zCU=; b=QU0YV8qQwyAHyy5whN09QpPfOCnoP/lldHA4EXOqbEyKSOu2xtp3JJ0AnfgzVmgBbW eKtx3JwTj9Uy6hgbb48QgBHmfpTPMTAycGfHSIfAKgZ38zvuvjn+S/lp2Y+rBOec7q2/ 4v274PWNbdfMh1Cvaj2mgSDTkkGfapTsrsO2OxhkJmlZmsJTpqvEyaR1hs8Q8KqJ4938 rvlWSS7Zu/Bw6o/U1Nx8LaqAGxxEvenEyRX+QN2y2F5cYqFGkVe8ZRc25towjC55ho4y DU+rLR+JP+1+48bQEm0285rgKEp+CyuvQCvux49leBi2kN3UetKmP0flXbxcc0CZQA7m OWQg== X-Gm-Message-State: AG10YOQA+D1LXuSwvJDOIJZQs4yrKIyBeV8rVuHjD2kDq/ihNuYb5n+ke7dKnEpp+8ut4MD4 X-Received: by 10.55.74.86 with SMTP id x83mr6240956qka.89.1454014753347; Thu, 28 Jan 2016 12:59:13 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id r6sm5259855qhr.28.2016.01.28.12.59.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 12:59:12 -0800 (PST) To: "Joel M. Halpern" , Ben Campbell References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56AA811F.8010201@mozilla.com> Date: Thu, 28 Jan 2016 15:59:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56AA78C9.9030304@joelhalpern.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:59:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/28/2016 03:23 PM, Joel M. Halpern wrote: > I think that this is a very bad idea. The point of doing the work > to create an RFC is to reach agreements on what the words should > be. Saying after that "oh, but anyone else can change these words > any way they want" just does not work for me. The main issue here is not that people would like to change what the RFC says. It's quite the opposite in fact. People would like to be able to reuse parts the RFC text in other contexts (e.g. documentation for a piece of software that relies on several RFCs). Without additional rights, they would have to paraphrase the content of RFCs, which would actually lead to more compatibility problems. Also, the proposed text already includes the condition "provided that no such derivative work shall be presented, displayed, or published in a manner that states or implies that it is part of this RFC or any other IETF Document". Given that, I'm not sure what the problem is. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWqoEbAAoJEJ6/8sItn9q9a1wH+wY6k2UP7iYQjLng6XQ79hgD W7pklezNzSXUlohTcUMK6s9n03fa1rK2jJcslDGgpO/qqzqdUDbEAlqqZhH2H+hc KXac5S6XVp56k0/QGPuyap9Ijshurs5ehvnYvBAuqcWAb9u9HaYlylZtH9/e482c Cretot8m5d2quZ1i3j23HccrfLiyve097OufY2sdgbzL1Xzu5qwcn/xJh27ccFtN 0Cbhigr7r6b8rNM/9VHSIF50shM2EuqULHBj+ABJbGfGIcWq4zRVJOsY0OqMaFcS 42y/974N/Admp6en1kITfdD6ZOn3jJpON6QOpaFRiGCiW3OsGs9AMCjZ+do4KM4= =WfO7 -----END PGP SIGNATURE----- From nobody Thu Jan 28 13:07:49 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702E1AD376; Thu, 28 Jan 2016 13:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-LYhUzCrigc; Thu, 28 Jan 2016 13:07:47 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F141AD375; Thu, 28 Jan 2016 13:07:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D73C7251F41; Thu, 28 Jan 2016 13:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454015266; bh=0kK5OUmvRhW9rBPkgC6K3CNjFD7r7PyYnMZiWaBnOF4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=asIB5Lmrh4cUa2pc+AGuD4IBOW3uiSHuOBPYuI/sr4n53bdCnbhZFhj1QYM0pyIw9 FqfNj5Ys+HesFarQ4MJHk0NSFr75mvTbLYxRk3phBch0aF2gdSoRP1fe+kbZqmIu2G NbiwEf3jhfua8aaYUd7lG9F9wwU1NZ78SZjWxvn8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 33504240A14; Thu, 28 Jan 2016 13:07:46 -0800 (PST) To: Jean-Marc Valin , Ben Campbell References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> From: "Joel M. Halpern" Message-ID: <56AA8310.2010300@joelhalpern.com> Date: Thu, 28 Jan 2016 16:07:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AA811F.8010201@mozilla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:07:48 -0000 We (the IETF) had this discussion regarding our copyright rules. We discussed the tension with reuse by open source documentation where the community could not commit to copying things without changing them (If they could make that promise, there would be no problem as such copying is already permitted.) So either the open source communities needs to be able to change the text, or it does not need to be able to change the text, or it has created rules for itself where it needs to be permitted to change the text even though it does not actually want to change. The first, not changing the text, is already covered. The second, changing the text, is not something I or the IETF community support. The third would seem to be a different problem, and asking the IEtF to change its rules for that seems a VERY strange answer. Yours, Joel On 1/28/16 3:59 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/28/2016 03:23 PM, Joel M. Halpern wrote: >> I think that this is a very bad idea. The point of doing the work >> to create an RFC is to reach agreements on what the words should >> be. Saying after that "oh, but anyone else can change these words >> any way they want" just does not work for me. > > The main issue here is not that people would like to change what the > RFC says. It's quite the opposite in fact. People would like to be > able to reuse parts the RFC text in other contexts (e.g. documentation > for a piece of software that relies on several RFCs). Without > additional rights, they would have to paraphrase the content of RFCs, > which would actually lead to more compatibility problems. Also, the > proposed text already includes the condition "provided that no such > derivative work shall be presented, displayed, or published in a > manner that states or implies that it is part of this RFC or any other > IETF Document". Given that, I'm not sure what the problem is. > > Cheers, > > Jean-Marc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWqoEbAAoJEJ6/8sItn9q9a1wH+wY6k2UP7iYQjLng6XQ79hgD > W7pklezNzSXUlohTcUMK6s9n03fa1rK2jJcslDGgpO/qqzqdUDbEAlqqZhH2H+hc > KXac5S6XVp56k0/QGPuyap9Ijshurs5ehvnYvBAuqcWAb9u9HaYlylZtH9/e482c > Cretot8m5d2quZ1i3j23HccrfLiyve097OufY2sdgbzL1Xzu5qwcn/xJh27ccFtN > 0Cbhigr7r6b8rNM/9VHSIF50shM2EuqULHBj+ABJbGfGIcWq4zRVJOsY0OqMaFcS > 42y/974N/Admp6en1kITfdD6ZOn3jJpON6QOpaFRiGCiW3OsGs9AMCjZ+do4KM4= > =WfO7 > -----END PGP SIGNATURE----- > From nobody Thu Jan 28 13:29:20 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3385D1A9083 for ; Thu, 28 Jan 2016 13:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsysI3bBUE6H for ; Thu, 28 Jan 2016 13:29:17 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CD71A9092 for ; Thu, 28 Jan 2016 13:29:14 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so50812108qgf.3 for ; Thu, 28 Jan 2016 13:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=aesi8DDOW0+XuszbIlqbzberYRys7YAw+ZNUy8Iog+Q=; b=EmNcCTHQTyTmxppg89+pJq8ZM64EGx/mlM9hIiWJVoILIOM3pVKwjBk/mHt0fymg8k FXFHcNKW1wqlzsPDdwRY/VsysYZaYsp2/tPYi1LGylRixbyyzdS1cDvoK2O2wPccqS0l f4r7QMI9zczq0c0ZAn8uGcbDZ0n+VxPJYcFNdLnJLXbrtqsapKoZe9jaXaJa5wnW8EKo OjJGYBnB7zGkwWCbAVcdVJiVz2NU9UMiy7JQTHWnMY5zYusqSKrO8Kp7ujCg4Aw4hG8M C88CsHkw3mSpelo0lDmd5xTWLBbpkj5sJ+02wZfeRrtPnn/e0lMt3mUjYwhQScqT4Ljh EDBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aesi8DDOW0+XuszbIlqbzberYRys7YAw+ZNUy8Iog+Q=; b=keCpIFfupy3MhPHEKapNOzFiA8Xp+N0f7tmKnUnEq9de2diCpRfCZyexHewEoDsRvE 4a1GpLb9/beYkmfl29IQVQv1NW6k9WKTRmqP+FzLRvixwtkiavuimwnSOkvjIqPRFB7C NKV7YJoUirTl5R5wTj7sq3GfkNOqLtJrChTq5nXO/4WwMCuYoPunTfc4MVCc7/9HhT2Q YqBd7aF4dcsTTZD9r6exdkWrhSNeRfj4OzjRRkqPyv1BkNK4mUhb8mSrIs+YQS7WPpXR AXN3qLMX6zGP37juoNqmuqp/aT/nwNKkEnftfq5ETCbYLyYvNuY6/mDlRbZU4QZafiKu k9DA== X-Gm-Message-State: AG10YORKz/m/WaSfxTFeBXHV84nNZZ0zs/d7KwsVwXYR6DErsbMmFpU9eduoANF/vI8fNw== X-Received: by 10.140.217.67 with SMTP id n64mr6965186qhb.26.1454016553818; Thu, 28 Jan 2016 13:29:13 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id r7sm5316559qhc.38.2016.01.28.13.29.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 13:29:13 -0800 (PST) To: "Joel M. Halpern" , Jean-Marc Valin , Ben Campbell References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56AA8828.2050008@jmvalin.ca> Date: Thu, 28 Jan 2016 16:29:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56AA8310.2010300@joelhalpern.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:29:19 -0000 On 01/28/2016 04:07 PM, Joel M. Halpern wrote: > So either the open source communities needs to be able to change the > text, or it does not need to be able to change the text, or it has > created rules for itself where it needs to be permitted to change the > text even though it does not actually want to change. > > The first, not changing the text, is already covered. > The second, changing the text, is not something I or the IETF community > support. It depends on your definition of "changing the text". There's a lot of pretty reasonable changes you can make to get the RFC text to better fit within a new document without changing the meaning. Any of these sure beats "paraphrasing a section of the RFC" from a compatibility point of view. > The third would seem to be a different problem, and asking the IEtF to > change its rules for that seems a VERY strange answer. There's certainly a bit of that as well. But keep in mind there's no "chair of the open source community" who can change all the rules. Cheers, Jean-Marc > Yours, > Joel > > On 1/28/16 3:59 PM, Jean-Marc Valin wrote: > On 01/28/2016 03:23 PM, Joel M. Halpern wrote: >>>> I think that this is a very bad idea. The point of doing the work >>>> to create an RFC is to reach agreements on what the words should >>>> be. Saying after that "oh, but anyone else can change these words >>>> any way they want" just does not work for me. > > The main issue here is not that people would like to change what the > RFC says. It's quite the opposite in fact. People would like to be > able to reuse parts the RFC text in other contexts (e.g. documentation > for a piece of software that relies on several RFCs). Without > additional rights, they would have to paraphrase the content of RFCs, > which would actually lead to more compatibility problems. Also, the > proposed text already includes the condition "provided that no such > derivative work shall be presented, displayed, or published in a > manner that states or implies that it is part of this RFC or any other > IETF Document". Given that, I'm not sure what the problem is. > > Cheers, > > Jean-Marc >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From nobody Thu Jan 28 14:09:50 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE81A92DD; Thu, 28 Jan 2016 14:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl6x5msoZbaE; Thu, 28 Jan 2016 14:09:47 -0800 (PST) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAE21A92BA; Thu, 28 Jan 2016 14:09:47 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id EAE1FC490F; Thu, 28 Jan 2016 22:09:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsS1RZ3DAARZ; Thu, 28 Jan 2016 22:09:46 +0000 (UTC) Received: from [10.252.26.138] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id C99EAC47C3; Thu, 28 Jan 2016 22:09:46 +0000 (UTC) Message-ID: <56AA91AA.3020102@xiph.org> Date: Thu, 28 Jan 2016 14:09:46 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "Joel M. Halpern" , Jean-Marc Valin , Ben Campbell References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com> In-Reply-To: <56AA8310.2010300@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 22:09:49 -0000 Joel M. Halpern wrote: > The second, changing the text, is not something I or the IETF community > support. Well, I don't claim to speak for the whole IETF community, but this is certainly something I support. No one is claiming that someone is going to edit the RFC and claim to have a new, better RFC (without going through the RFC update/errata process), and the grant in question specifically disclaims anyone's right to do that. But, particularly for a document like this, which is defining a codec mapping, I would hope that people would be free to borrow this text for future mappings: either of Opus into another container or another codec into Ogg, or even something totally unrelated to either if it applies. From nobody Thu Jan 28 19:11:40 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62B1B379B; Thu, 28 Jan 2016 19:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd-Zb8XS4vKC; Thu, 28 Jan 2016 19:11:37 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50D1B37A4; Thu, 28 Jan 2016 19:11:34 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail04.adl6.internode.on.net with ESMTP; 29 Jan 2016 13:40:46 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 34182FFC86; Fri, 29 Jan 2016 13:40:45 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zcj7LXbkAGyN; Fri, 29 Jan 2016 13:40:44 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 98A39FF88A; Fri, 29 Jan 2016 13:40:44 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 802FA80470; Fri, 29 Jan 2016 13:40:44 +1030 (ACDT) Date: Fri, 29 Jan 2016 13:40:44 +1030 From: Ron To: Robert Sparks Message-ID: <20160129031044.GB3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A92C39.7060206@nostrum.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: ietf@ietf.org, codec@ietf.org, codec-chairs@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 03:11:39 -0000 Hi Robert, On Wed, Jan 27, 2016 at 02:44:41PM -0600, Robert Sparks wrote: > This document has an unusual feature that I think needs to be highlighted in > this last call. > > Section 13 instructs the RFC editor to: > > In the Copyright Notice at the start of the document, the following > > paragraph is to be appended after the regular copyright notice text: > > > > "The licenses granted by the IETF Trust to this RFC under Section 3.c > > of the Trust Legal Provisions shall also include the right to extract > > text from Sections 1 through 14 of this RFC and create derivative > > works from these extracts, and to copy, publish, display, and > > distribute such derivative works in any medium and for any purpose, > > provided that no such derivative work shall be presented, displayed, > > or published in a manner that states or implies that it is part of > > this RFC or any other IETF Document." > > I understand why we did what we did for RFC6716 (the specification for OPUS, > where the additional grants were to deal with the code being normative). > > I do not think it is the right thing to do for this document. Could you spell out in a bit more detail what you see as being different for this document, and what your concerns are with either (or both!) the letter and the intent in this case. I really would like to understand your concerns, and if necessary have this evolve into language that does cover everyone's needs and fears as comprehensively as we can. We've got nearly 4 years behind us now with no terrible abuse of this grant having occurred for 6716, but if you think it's less than ideal, I'd like us to consider ways we can still improve on that. Cheers, Ron From nobody Thu Jan 28 21:24:54 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029701B3DFB; Thu, 28 Jan 2016 21:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmtsYJNZfD8Q; Thu, 28 Jan 2016 21:24:48 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 058311B3DF7; Thu, 28 Jan 2016 21:24:46 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail04.adl6.internode.on.net with ESMTP; 29 Jan 2016 15:54:45 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 89528FFCCF; Fri, 29 Jan 2016 15:54:44 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tB30zvWaCTGi; Fri, 29 Jan 2016 15:54:42 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 87553FF88A; Fri, 29 Jan 2016 15:54:42 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7694D80470; Fri, 29 Jan 2016 15:54:42 +1030 (ACDT) Date: Fri, 29 Jan 2016 15:54:42 +1030 From: Ron To: "Joel M. Halpern" Message-ID: <20160129052442.GC3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56AA8310.2010300@joelhalpern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-ietf-codec-oggopus@ietf.org, codec@ietf.org, codec-chairs@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 05:24:52 -0000 Hi Joel, On Thu, Jan 28, 2016 at 03:23:37PM -0500, Joel M. Halpern wrote: > The point of doing the work to create an RFC is to reach agreements on > what the words should be. Yes, and we spent a lot of time and put a lot of work into making sure we picked the best words to clearly describe what it was that we wanted to define. Which is exactly why we want as many people as possible to reuse those words *precisely*, rather than having to rewrite them or paraphrase them willy-nilly, when they need them to appear in some other context where reproducing the full document in its entirety would not be appropriate or helpful for perfect understanding. If I want to provide a function in a library which allows the caller to construct or manipulate an OggOpus header structure, it would be much better if I can quote the relevant parts of this document directly, with some surrounding text that talks about the other constraints and return codes of my function, than it would be for me to invent new ways of describing that (for no other reason than I'm not permitted to cut and paste that and manipulate it to fit my documentation coherently without this extra grant). I think you and I are in violent agreement here that we want these words to be preserved as perfectly as possible everywhere they are used in reference to this standard. > Saying after that "oh, but anyone else can change these words any way > they want" just does not work for me. Fortunately, that's not what we are saying. We expressly state that you can not call anything you extracted from this an RFC. We don't want people to misrepresent this, because we already spend enough time correcting people who accidentally made some error in their implementation. We don't think that situation would be improved by *forcing* people to change these words to use them in their own descriptions and library/application documentation. > More generally, I think we need to establish that this is not how we work, > rather than letting folks do this more and more often. > > In terms of documentation, I am actually very concerned with this apparent > effort for us to support documenting of protocols and behaviors that do not > comply with the RFC. That is not our purpose. Again, I think we are in violent agreement with what I *think* is your real concern here. You just appear to be misunderstanding what the "apparent effort" is aimed at doing here - and how by not allowing people to use selected and context appropriate parts of these words verbatim, you are actually forcing them to create precisely the terrible outcome that you fear. Because the only other alternative to that, is they completely ignore the licence grant on this document, and we turn a blind eye to that and pretend they didn't do that and don't prosecute them for it. Which isn't a good outcome either, for lots of reasons. I know a lot of corporate licence grants work that way, but I don't think we win at this by forcing people who do respect licences to act in a way that we seem to agree we all would rather they didn't (and so rewrite this document in their own words which they can then redistribute). On Thu, Jan 28, 2016 at 04:07:28PM -0500, Joel M. Halpern wrote: > We (the IETF) had this discussion regarding our copyright rules. We > discussed the tension with reuse by open source documentation where the > community could not commit to copying things without changing them (If they > could make that promise, there would be no problem as such copying is > already permitted.) I can't extract portions of this document, to copy verbatim just the salient parts of it into a context where that is what needs to be highlighted or explained. At least not without this extra grant, which is why we want it, or something like it, to be part of how these words are licenced for reuse. Doing that is indistinguishable from "modification". We're running on the assumption that people with good intent should be able to misrepresent this document as little as possible in their genuine use of it, with the guarantee that people with bad intent can't misrepresent their corruption of it as an RFC. If you're coming at this with the mindset of it being some sort of ideological war that those evil open source commies are waging on our purity of essence, then I can see how you might be missing or blinded to the real concern that we have about people using and implementing this standard as accurately and correctly as possible. What we'd like to see happen is that we *strengthen* the IETF's authority as the source of the words that everyone uses in their own dissemination of understanding this standard. And you don't do that by saying "you must paste in the entire War And Peace epic, everywhere you want to do that, or you're allowed to use none of it". > So either the open source communities needs to be able to change the text, > or it does not need to be able to change the text, or it has created rules > for itself where it needs to be permitted to change the text even though it > does not actually want to change. ... or they have decided that the only protection they have against abuse of their own licence conditions is to strictly respect the licences that others have given them. Which means they are in a position of not being able to do things which the IETF would probably agree is in its best interests and was its intent, and which it can only otherwise turn a blind eye to when people and companies who don't show that respect do things which the letter of the licence grant did not allow them to do. RFC 3951 was a poster child for the (I believe unintended) consequences of that. I'm sure there are certainly many others. The IETF has shown that it has learnt from that, and improved things somewhat. And what we discussed and did for 6716 shows that there is understanding about how we're still not quite where we really want to be yet ... Unless "where you want us to be" speaking as an individual is for these standards to only be maximally useful to people who ignore the licence granted to use them. Which doesn't seem like a defensible position. Let me quote the explanation I gave before this went to IETF LC, and offer another example of why this is important, and why it is being recognised more broadly by other standards organisations too ... In https://www.ietf.org/mail-archive/web/codec/current/msg03163.html I wrote: > In the context of this draft, we *want* people to be able to use it. > And personally, I'd much rather have them quote parts of it verbatim, > modified to fit coherently into their own documentation, than have them > paraphrase those parts of it to avoid the legal restriction - possibly > introducing new ambiguities or misunderstandings, which may then become > quoted even more widely than the original RFC, simply because people are > allowed to reproduce that error in their own work, but aren't allowed to > quote or redistribute the RFC directly ... > > That outcome seems fairly directly counterproductive to what we want to > achieve by having a formal standard that we'd like everyone to follow. > > We'd have a kind of SDO version of Gresham's Law undermining the value > and currency of the words we worked so hard to choose carefully here. > The aim here is not to dilute the IETF's authority over this document, > but to give that authority the greatest possible value we can. The standing proof of that (though certainly not the only example) is the POSIX manual pages. A lot of programmers love manual pages as a primary source of documentation, but for many years, we faced the same sort of restrictions as we do here without this grant for creating and distributing them. And what was the result of that? An entire shadow standard emerged, of manual pages rewritten from scratch to describe the behaviour of POSIX functions in someone's own words. Which people then used as their primary source of information about them, and all of the errors, and omissions, and small differences became deeply engrained in the body of extant code that people came to depend on. Sometimes those errors would get noticed and fixed, and sometimes it was far too late to put the djinn back in the bottle and the chaos that caused would become the new reality everyone had to deal with. I'm sure there's an awesome April 1 RFC waiting to be written where the history of that happening to standards produced here is dissected as a hilarious yet sad warning to future participants. We can't (always) fix the past, but it is our responsibility to learn from it and try not to stuff up the future. In 2004, the IEEE and The Open Group granted permission to include extracts of their documents in derived works which included manual pages that detailed the known deviations which programmers may really have to deal with in the wild when writing portable code. In 2014, they renewed that grant for their latest publication of them, so it would appear their experience after 10 years, was that the upside benefits had clearly exceeded any downside risk. https://lwn.net/Articles/581858/ If the wording of the extra grant that IETF-legal came up with for 6716 is somehow not optimal, I'd love for us to have that discussion and try to address any substantive concerns people have. But in order to do that, I think those need to be expressed a bit more concretely than "this is not how we do things", or "I'm afraid", or by picturing it as some sort of "them against us" agenda which is only "apparent" to some individual participants. I personally have a strong interest in open source software, not as an ideology, but because as a methodology It Works. I likewise have a strong interest in the success and the strength of the IETF as an SDO, again, because the methodology used here Really Works to produce widely accepted standards that people can really use. I don't think either group can yet claim to be a "solved problem". I think we both have a lot we can learn from each other still, and I think we have enough overlap for that to occur naturally by osmosis. I'd rather we didn't squander that by claiming there is a barrier between us which is impermeable as a matter of dogma. So if there is a real problem here, let's discuss what that is, not handwave it away as some sort of outside conspiracy to destroy our way of life. The IETF is one of the best friends and resources that the developers of openly interoperable systems have. There's no way I'd want it on my permanent record that I'd done anything to harm that in any way. And I don't see how this would. But if we've missed something that we need to pay more attention to, that's where this process excels, so let's use it and fix any actual devil we can see in the details. As an individual participant who helped author this draft, Ron From nobody Thu Jan 28 22:10:37 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE1A1B3EA1; Thu, 28 Jan 2016 22:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElEe5J5HR9Mj; Thu, 28 Jan 2016 22:10:30 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330FB1B3E8B; Thu, 28 Jan 2016 22:10:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F025024BF0A; Thu, 28 Jan 2016 22:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454047829; bh=UJJFFM6H8eXUDc006yD8COZgb26c6dslDzDjaXQZDtk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A9mjX0FFUSqCodbM3SRSh1Jj8QxZEJDTnuTEZWinJrWeT8fK+yEYTyrsd6OU+ShgM lJZqdC0acE318BpjN5wnxXhvrSv4nb2VsH6DHoyRUtQ0D8+J9U5Qkkh4As/Pu3cx9d AeuWiFszSEs2kFtfVWuN1r1cHQdl4ed9plTPnhCY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0F97E246737; Thu, 28 Jan 2016 22:10:28 -0800 (PST) To: Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com> <20160129052442.GC3153@hex.shelbyville.oz> From: "Joel M. Halpern" Message-ID: <56AB0241.5090602@joelhalpern.com> Date: Fri, 29 Jan 2016 01:10:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160129052442.GC3153@hex.shelbyville.oz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-codec-oggopus@ietf.org, codec@ietf.org, codec-chairs@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 06:10:33 -0000 If what is needed is the right to excerpt, with unmodified content (format modification clearly would be allowed) portions of the RFC, I would support that. I understand your reasons, as set forth below, for seeing that as useful. But that is not what the text in the draft asks for. It asks for the right to create derivative works. In copyright terms, that means the right to modify the text. That is where I have trouble. Yours, Joel On 1/29/16 12:24 AM, Ron wrote: > > Hi Joel, > > On Thu, Jan 28, 2016 at 03:23:37PM -0500, Joel M. Halpern wrote: >> The point of doing the work to create an RFC is to reach agreements on >> what the words should be. > > Yes, and we spent a lot of time and put a lot of work into making sure > we picked the best words to clearly describe what it was that we wanted > to define. > > Which is exactly why we want as many people as possible to reuse those > words *precisely*, rather than having to rewrite them or paraphrase them > willy-nilly, when they need them to appear in some other context where > reproducing the full document in its entirety would not be appropriate > or helpful for perfect understanding. > > If I want to provide a function in a library which allows the caller to > construct or manipulate an OggOpus header structure, it would be much > better if I can quote the relevant parts of this document directly, with > some surrounding text that talks about the other constraints and return > codes of my function, than it would be for me to invent new ways of > describing that (for no other reason than I'm not permitted to cut and > paste that and manipulate it to fit my documentation coherently without > this extra grant). > > I think you and I are in violent agreement here that we want these words > to be preserved as perfectly as possible everywhere they are used in > reference to this standard. > > >> Saying after that "oh, but anyone else can change these words any way >> they want" just does not work for me. > > Fortunately, that's not what we are saying. We expressly state that > you can not call anything you extracted from this an RFC. > > We don't want people to misrepresent this, because we already spend > enough time correcting people who accidentally made some error in > their implementation. > > We don't think that situation would be improved by *forcing* people > to change these words to use them in their own descriptions and > library/application documentation. > > >> More generally, I think we need to establish that this is not how we work, >> rather than letting folks do this more and more often. >> >> In terms of documentation, I am actually very concerned with this apparent >> effort for us to support documenting of protocols and behaviors that do not >> comply with the RFC. That is not our purpose. > > Again, I think we are in violent agreement with what I *think* is your > real concern here. You just appear to be misunderstanding what the > "apparent effort" is aimed at doing here - and how by not allowing > people to use selected and context appropriate parts of these words > verbatim, you are actually forcing them to create precisely the terrible > outcome that you fear. > > Because the only other alternative to that, is they completely ignore > the licence grant on this document, and we turn a blind eye to that > and pretend they didn't do that and don't prosecute them for it. > > Which isn't a good outcome either, for lots of reasons. I know a lot > of corporate licence grants work that way, but I don't think we win > at this by forcing people who do respect licences to act in a way that > we seem to agree we all would rather they didn't (and so rewrite this > document in their own words which they can then redistribute). > > > > On Thu, Jan 28, 2016 at 04:07:28PM -0500, Joel M. Halpern wrote: >> We (the IETF) had this discussion regarding our copyright rules. We >> discussed the tension with reuse by open source documentation where the >> community could not commit to copying things without changing them (If they >> could make that promise, there would be no problem as such copying is >> already permitted.) > > I can't extract portions of this document, to copy verbatim just the > salient parts of it into a context where that is what needs to be > highlighted or explained. > > At least not without this extra grant, which is why we want it, or > something like it, to be part of how these words are licenced for > reuse. > > Doing that is indistinguishable from "modification". > > We're running on the assumption that people with good intent should > be able to misrepresent this document as little as possible in their > genuine use of it, with the guarantee that people with bad intent > can't misrepresent their corruption of it as an RFC. > > > If you're coming at this with the mindset of it being some sort of > ideological war that those evil open source commies are waging on > our purity of essence, then I can see how you might be missing or > blinded to the real concern that we have about people using and > implementing this standard as accurately and correctly as possible. > > What we'd like to see happen is that we *strengthen* the IETF's > authority as the source of the words that everyone uses in their > own dissemination of understanding this standard. And you don't > do that by saying "you must paste in the entire War And Peace epic, > everywhere you want to do that, or you're allowed to use none of it". > > >> So either the open source communities needs to be able to change the text, >> or it does not need to be able to change the text, or it has created rules >> for itself where it needs to be permitted to change the text even though it >> does not actually want to change. > > ... or they have decided that the only protection they have against > abuse of their own licence conditions is to strictly respect the > licences that others have given them. > > Which means they are in a position of not being able to do things > which the IETF would probably agree is in its best interests and was > its intent, and which it can only otherwise turn a blind eye to when > people and companies who don't show that respect do things which the > letter of the licence grant did not allow them to do. > > RFC 3951 was a poster child for the (I believe unintended) consequences > of that. I'm sure there are certainly many others. > > The IETF has shown that it has learnt from that, and improved things > somewhat. And what we discussed and did for 6716 shows that there is > understanding about how we're still not quite where we really want to > be yet ... > > Unless "where you want us to be" speaking as an individual is for these > standards to only be maximally useful to people who ignore the licence > granted to use them. Which doesn't seem like a defensible position. > > > Let me quote the explanation I gave before this went to IETF LC, and > offer another example of why this is important, and why it is being > recognised more broadly by other standards organisations too ... > > > In https://www.ietf.org/mail-archive/web/codec/current/msg03163.html > I wrote: >> In the context of this draft, we *want* people to be able to use it. >> And personally, I'd much rather have them quote parts of it verbatim, >> modified to fit coherently into their own documentation, than have them >> paraphrase those parts of it to avoid the legal restriction - possibly >> introducing new ambiguities or misunderstandings, which may then become >> quoted even more widely than the original RFC, simply because people are >> allowed to reproduce that error in their own work, but aren't allowed to >> quote or redistribute the RFC directly ... >> >> That outcome seems fairly directly counterproductive to what we want to >> achieve by having a formal standard that we'd like everyone to follow. >> >> We'd have a kind of SDO version of Gresham's Law undermining the value >> and currency of the words we worked so hard to choose carefully here. >> The aim here is not to dilute the IETF's authority over this document, >> but to give that authority the greatest possible value we can. > > > The standing proof of that (though certainly not the only example) is > the POSIX manual pages. > > A lot of programmers love manual pages as a primary source of > documentation, but for many years, we faced the same sort of > restrictions as we do here without this grant for creating and > distributing them. > > > And what was the result of that? > > An entire shadow standard emerged, of manual pages rewritten from scratch > to describe the behaviour of POSIX functions in someone's own words. > Which people then used as their primary source of information about them, > and all of the errors, and omissions, and small differences became deeply > engrained in the body of extant code that people came to depend on. > > Sometimes those errors would get noticed and fixed, and sometimes it was > far too late to put the djinn back in the bottle and the chaos that > caused would become the new reality everyone had to deal with. > > I'm sure there's an awesome April 1 RFC waiting to be written where the > history of that happening to standards produced here is dissected as a > hilarious yet sad warning to future participants. > > > We can't (always) fix the past, but it is our responsibility to learn > from it and try not to stuff up the future. > > In 2004, the IEEE and The Open Group granted permission to include > extracts of their documents in derived works which included manual pages > that detailed the known deviations which programmers may really have to > deal with in the wild when writing portable code. > > In 2014, they renewed that grant for their latest publication of them, > so it would appear their experience after 10 years, was that the upside > benefits had clearly exceeded any downside risk. > > https://lwn.net/Articles/581858/ > > > If the wording of the extra grant that IETF-legal came up with for 6716 > is somehow not optimal, I'd love for us to have that discussion and try > to address any substantive concerns people have. But in order to do > that, I think those need to be expressed a bit more concretely than > "this is not how we do things", or "I'm afraid", or by picturing it as > some sort of "them against us" agenda which is only "apparent" to some > individual participants. > > > I personally have a strong interest in open source software, not as an > ideology, but because as a methodology It Works. I likewise have a > strong interest in the success and the strength of the IETF as an SDO, > again, because the methodology used here Really Works to produce widely > accepted standards that people can really use. > > I don't think either group can yet claim to be a "solved problem". > I think we both have a lot we can learn from each other still, and I > think we have enough overlap for that to occur naturally by osmosis. > I'd rather we didn't squander that by claiming there is a barrier > between us which is impermeable as a matter of dogma. > > So if there is a real problem here, let's discuss what that is, not > handwave it away as some sort of outside conspiracy to destroy our > way of life. > > The IETF is one of the best friends and resources that the developers > of openly interoperable systems have. There's no way I'd want it on > my permanent record that I'd done anything to harm that in any way. > And I don't see how this would. But if we've missed something that > we need to pay more attention to, that's where this process excels, > so let's use it and fix any actual devil we can see in the details. > > > As an individual participant who helped author this draft, > Ron > > > From nobody Fri Jan 29 00:03:45 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C212B1A03A2; Fri, 29 Jan 2016 00:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d98ghitZv9P; Fri, 29 Jan 2016 00:03:37 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 889F31A036C; Fri, 29 Jan 2016 00:03:35 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail06.adl6.internode.on.net with ESMTP; 29 Jan 2016 18:33:34 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id E55ADFFCCF; Fri, 29 Jan 2016 18:33:32 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QZLhdfPJLP-q; Fri, 29 Jan 2016 18:33:30 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 82820FF96F; Fri, 29 Jan 2016 18:33:30 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 622CB80470; Fri, 29 Jan 2016 18:33:30 +1030 (ACDT) Date: Fri, 29 Jan 2016 18:33:30 +1030 From: Ron To: "Joel M. Halpern" Message-ID: <20160129080330.GE3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com> <20160129052442.GC3153@hex.shelbyville.oz> <56AB0241.5090602@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56AB0241.5090602@joelhalpern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-ietf-codec-oggopus@ietf.org, codec@ietf.org, codec-chairs@ietf.org, ietf@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 08:03:42 -0000 On Fri, Jan 29, 2016 at 01:10:09AM -0500, Joel M. Halpern wrote: > If what is needed is the right to excerpt, with unmodified content (format > modification clearly would be allowed) portions of the RFC, I would support > that. I understand your reasons, as set forth below, for seeing that as > useful. > > But that is not what the text in the draft asks for. It asks for the right > to create derivative works. In copyright terms, that means the right to > modify the text. That is where I have trouble. I think I understand the sort of abuse you'd like to ensure doesn't happen as a result of this, but I think we have that covered by firmly saying that if you do excerpt this in any way, you must remove the IETF header and must not claim your document is an RFC. Otherwise, excerpting it is essentially indistinguishable from modifying it anyway ... To show that as a pathological case, I could excerpt 3 words from it somewhere, insert of a few of my own, skip a few from the RFC and then excerpt some more of it. Which could be a completely reasonable thing to do if I'm explaining how the requirements of calling my function fit together with the requirements of the standard. Or which could be used to excerpt individual sequences of letters from it to create a quote from Shakespeare. And I don't really see how we can sensibly separate those two cases in a way that someone sufficiently crazy couldn't make a joke of. We can however clearly point at someone who is claiming that something is an RFC when it is not a published and unmodified RFC and come down on them like a ton of bricks. And I fully support that we should be able to do that. It's just not clear to me what other case of using some other part of the text would create a problem for us. But if people can describe one we can (and should) consider the best way to mitigate it. > On 1/29/16 12:24 AM, Ron wrote: > > > >Hi Joel, > > > >On Thu, Jan 28, 2016 at 03:23:37PM -0500, Joel M. Halpern wrote: > >>The point of doing the work to create an RFC is to reach agreements on > >>what the words should be. > > > >Yes, and we spent a lot of time and put a lot of work into making sure > >we picked the best words to clearly describe what it was that we wanted > >to define. > > > >Which is exactly why we want as many people as possible to reuse those > >words *precisely*, rather than having to rewrite them or paraphrase them > >willy-nilly, when they need them to appear in some other context where > >reproducing the full document in its entirety would not be appropriate > >or helpful for perfect understanding. > > > >If I want to provide a function in a library which allows the caller to > >construct or manipulate an OggOpus header structure, it would be much > >better if I can quote the relevant parts of this document directly, with > >some surrounding text that talks about the other constraints and return > >codes of my function, than it would be for me to invent new ways of > >describing that (for no other reason than I'm not permitted to cut and > >paste that and manipulate it to fit my documentation coherently without > >this extra grant). > > > >I think you and I are in violent agreement here that we want these words > >to be preserved as perfectly as possible everywhere they are used in > >reference to this standard. > > > > > >>Saying after that "oh, but anyone else can change these words any way > >>they want" just does not work for me. > > > >Fortunately, that's not what we are saying. We expressly state that > >you can not call anything you extracted from this an RFC. > > > >We don't want people to misrepresent this, because we already spend > >enough time correcting people who accidentally made some error in > >their implementation. > > > >We don't think that situation would be improved by *forcing* people > >to change these words to use them in their own descriptions and > >library/application documentation. > > > > > >>More generally, I think we need to establish that this is not how we work, > >>rather than letting folks do this more and more often. > >> > >>In terms of documentation, I am actually very concerned with this apparent > >>effort for us to support documenting of protocols and behaviors that do not > >>comply with the RFC. That is not our purpose. > > > >Again, I think we are in violent agreement with what I *think* is your > >real concern here. You just appear to be misunderstanding what the > >"apparent effort" is aimed at doing here - and how by not allowing > >people to use selected and context appropriate parts of these words > >verbatim, you are actually forcing them to create precisely the terrible > >outcome that you fear. > > > >Because the only other alternative to that, is they completely ignore > >the licence grant on this document, and we turn a blind eye to that > >and pretend they didn't do that and don't prosecute them for it. > > > >Which isn't a good outcome either, for lots of reasons. I know a lot > >of corporate licence grants work that way, but I don't think we win > >at this by forcing people who do respect licences to act in a way that > >we seem to agree we all would rather they didn't (and so rewrite this > >document in their own words which they can then redistribute). > > > > > > > >On Thu, Jan 28, 2016 at 04:07:28PM -0500, Joel M. Halpern wrote: > >>We (the IETF) had this discussion regarding our copyright rules. We > >>discussed the tension with reuse by open source documentation where the > >>community could not commit to copying things without changing them (If they > >>could make that promise, there would be no problem as such copying is > >>already permitted.) > > > >I can't extract portions of this document, to copy verbatim just the > >salient parts of it into a context where that is what needs to be > >highlighted or explained. > > > >At least not without this extra grant, which is why we want it, or > >something like it, to be part of how these words are licenced for > >reuse. > > > >Doing that is indistinguishable from "modification". > > > >We're running on the assumption that people with good intent should > >be able to misrepresent this document as little as possible in their > >genuine use of it, with the guarantee that people with bad intent > >can't misrepresent their corruption of it as an RFC. > > > > > >If you're coming at this with the mindset of it being some sort of > >ideological war that those evil open source commies are waging on > >our purity of essence, then I can see how you might be missing or > >blinded to the real concern that we have about people using and > >implementing this standard as accurately and correctly as possible. > > > >What we'd like to see happen is that we *strengthen* the IETF's > >authority as the source of the words that everyone uses in their > >own dissemination of understanding this standard. And you don't > >do that by saying "you must paste in the entire War And Peace epic, > >everywhere you want to do that, or you're allowed to use none of it". > > > > > >>So either the open source communities needs to be able to change the text, > >>or it does not need to be able to change the text, or it has created rules > >>for itself where it needs to be permitted to change the text even though it > >>does not actually want to change. > > > >... or they have decided that the only protection they have against > >abuse of their own licence conditions is to strictly respect the > >licences that others have given them. > > > >Which means they are in a position of not being able to do things > >which the IETF would probably agree is in its best interests and was > >its intent, and which it can only otherwise turn a blind eye to when > >people and companies who don't show that respect do things which the > >letter of the licence grant did not allow them to do. > > > >RFC 3951 was a poster child for the (I believe unintended) consequences > >of that. I'm sure there are certainly many others. > > > >The IETF has shown that it has learnt from that, and improved things > >somewhat. And what we discussed and did for 6716 shows that there is > >understanding about how we're still not quite where we really want to > >be yet ... > > > >Unless "where you want us to be" speaking as an individual is for these > >standards to only be maximally useful to people who ignore the licence > >granted to use them. Which doesn't seem like a defensible position. > > > > > >Let me quote the explanation I gave before this went to IETF LC, and > >offer another example of why this is important, and why it is being > >recognised more broadly by other standards organisations too ... > > > > > >In https://www.ietf.org/mail-archive/web/codec/current/msg03163.html > >I wrote: > >>In the context of this draft, we *want* people to be able to use it. > >>And personally, I'd much rather have them quote parts of it verbatim, > >>modified to fit coherently into their own documentation, than have them > >>paraphrase those parts of it to avoid the legal restriction - possibly > >>introducing new ambiguities or misunderstandings, which may then become > >>quoted even more widely than the original RFC, simply because people are > >>allowed to reproduce that error in their own work, but aren't allowed to > >>quote or redistribute the RFC directly ... > >> > >>That outcome seems fairly directly counterproductive to what we want to > >>achieve by having a formal standard that we'd like everyone to follow. > >> > >>We'd have a kind of SDO version of Gresham's Law undermining the value > >>and currency of the words we worked so hard to choose carefully here. > >>The aim here is not to dilute the IETF's authority over this document, > >>but to give that authority the greatest possible value we can. > > > > > >The standing proof of that (though certainly not the only example) is > >the POSIX manual pages. > > > >A lot of programmers love manual pages as a primary source of > >documentation, but for many years, we faced the same sort of > >restrictions as we do here without this grant for creating and > >distributing them. > > > > > >And what was the result of that? > > > >An entire shadow standard emerged, of manual pages rewritten from scratch > >to describe the behaviour of POSIX functions in someone's own words. > >Which people then used as their primary source of information about them, > >and all of the errors, and omissions, and small differences became deeply > >engrained in the body of extant code that people came to depend on. > > > >Sometimes those errors would get noticed and fixed, and sometimes it was > >far too late to put the djinn back in the bottle and the chaos that > >caused would become the new reality everyone had to deal with. > > > >I'm sure there's an awesome April 1 RFC waiting to be written where the > >history of that happening to standards produced here is dissected as a > >hilarious yet sad warning to future participants. > > > > > >We can't (always) fix the past, but it is our responsibility to learn > >from it and try not to stuff up the future. > > > >In 2004, the IEEE and The Open Group granted permission to include > >extracts of their documents in derived works which included manual pages > >that detailed the known deviations which programmers may really have to > >deal with in the wild when writing portable code. > > > >In 2014, they renewed that grant for their latest publication of them, > >so it would appear their experience after 10 years, was that the upside > >benefits had clearly exceeded any downside risk. > > > >https://lwn.net/Articles/581858/ > > > > > >If the wording of the extra grant that IETF-legal came up with for 6716 > >is somehow not optimal, I'd love for us to have that discussion and try > >to address any substantive concerns people have. But in order to do > >that, I think those need to be expressed a bit more concretely than > >"this is not how we do things", or "I'm afraid", or by picturing it as > >some sort of "them against us" agenda which is only "apparent" to some > >individual participants. > > > > > >I personally have a strong interest in open source software, not as an > >ideology, but because as a methodology It Works. I likewise have a > >strong interest in the success and the strength of the IETF as an SDO, > >again, because the methodology used here Really Works to produce widely > >accepted standards that people can really use. > > > >I don't think either group can yet claim to be a "solved problem". > >I think we both have a lot we can learn from each other still, and I > >think we have enough overlap for that to occur naturally by osmosis. > >I'd rather we didn't squander that by claiming there is a barrier > >between us which is impermeable as a matter of dogma. > > > >So if there is a real problem here, let's discuss what that is, not > >handwave it away as some sort of outside conspiracy to destroy our > >way of life. > > > >The IETF is one of the best friends and resources that the developers > >of openly interoperable systems have. There's no way I'd want it on > >my permanent record that I'd done anything to harm that in any way. > >And I don't see how this would. But if we've missed something that > >we need to pay more attention to, that's where this process excels, > >so let's use it and fix any actual devil we can see in the details. > > > > > > As an individual participant who helped author this draft, > > Ron From nobody Fri Jan 29 01:16:01 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2721A1BB3 for ; Fri, 29 Jan 2016 01:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJcV375s6Bag for ; Fri, 29 Jan 2016 01:15:58 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BB81A1B84 for ; Fri, 29 Jan 2016 01:15:58 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id f81so82889794iof.0 for ; Fri, 29 Jan 2016 01:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=JB0qWb64vJHc747kj8QkVx3Ggzpmzfza+L5NcMqICYw=; b=eeWwRFMPlafE4Jq9KBgvrBevUHwpOJoDDdPZxMcIAae5T9ZzaAlspyawmZKypBLNAO 0BvP4DUQ6wc0/JVNhmfGpxrvvg6xA/XDZI9jJtp0D9BgRX3K93RCrTGhYA90HZEbKaGg EVOc4bLkE3sLPVOcTb9vvJK2YUY6THwIj7nvhGINtDynqTwJKVdtF1EXBY3aghE+Wbj0 ZOx+DlhzkvXButF+7TD2G26iFx6N/4jnGlK/pyOa9NoJA3Mn4U3jFNcR2p4dbB/B5Z6t mmmwp0Gdx3gS1J/tWaIuTe7v14zqayqUQ2UpUFyzMofZTzMfsFTE70d7h7lowGm/SFDI 1yeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JB0qWb64vJHc747kj8QkVx3Ggzpmzfza+L5NcMqICYw=; b=ZPhdqJhJX9x0p7hoYClh28AmhpJNxVIYOshc63m2X7lPZ6JX23aCW2azdlSsZwVeuF Vr/MF55pf9331cwym+wJ1A3QrwzO+1WxVe+61eSTLVimJK4H5Lqo0Ka49fUbH1UaEAFH yNoMSFI0ShzNArCWZAB6HiD3R+6dbKlKpididFxBNltgEf1+aCWVqLNUH3Z/ZM0bQrYK LIOZaCr5fB9l3vKTJO8JeroPPzBHlV0bFkpzp6Zvg1iU5oRAnNvi6VLUwmMey8cxPnWj rqtP5XIscE3x29g4XR5rfELjqly/33JgkwngHwdJiKAcICcXyiBRmldy9YZ1fR0wxfSi ZU4Q== X-Gm-Message-State: AG10YOTPb8dMh/EA2GbQSp43rFFOHjCksCpD8G3sPinITLhlZcgaTFkvfjPOHqDBarYsyDdE8HsC1DFZgzpoEQ== MIME-Version: 1.0 X-Received: by 10.107.40.148 with SMTP id o142mr9165194ioo.18.1454058957811; Fri, 29 Jan 2016 01:15:57 -0800 (PST) Sender: markh.sj@gmail.com Received: by 10.107.17.158 with HTTP; Fri, 29 Jan 2016 01:15:57 -0800 (PST) In-Reply-To: <20160128183904.8076.80585.idtracker@ietfa.amsl.com> References: <20160128183904.8076.80585.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 01:15:57 -0800 X-Google-Sender-Auth: bD0Nux8N96HAUTvQIKTTU-Z_1bQ Message-ID: From: Mark Harris To: "codec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 09:16:00 -0000 I see a minor issue with a change in the new version -11 of this draft. This version of the draft changes: "It is possible to run an Opus decoder at other sampling rates, but the value in the granule position field always counts samples assuming a 48 kHz decoding rate ..." to: "It is possible to run an Opus decoder at other sampling rates, but all of them evenly divide 48 kHz. Therefore, the value in the granule position field always counts samples assuming a 48 kHz decoding rate ..." Although the reference decoder can only decode at sampling rates that evenly divide 48 kHz, this change inaccurately implies that it is not possible to write an Opus decoder that decodes at another rate. How about this wording: It is possible to run an Opus decoder at other sampling rates, but a sampling rate of 48 kHz is sufficient to capture the full audio bandwidth of any Opus packet. Therefore, the value in the granule position field always counts samples assuming a 48 kHz decoding rate ... - Mark