From nobody Fri Jan 4 05:36:36 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1081294D0 for ; Fri, 4 Jan 2019 05:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org 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 3vTuHKQDHS4N for ; Fri, 4 Jan 2019 05:36:32 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 C15A0128D0C for ; Fri, 4 Jan 2019 05:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=7IMR/cKZouPQyUa927nawiwI/6tlZOTWVLtFusLIPiQ=; b=BNrCAS3vGEqZRqRqPwg7C/al5/4jwIc8+mTZgaKc+DWBxAMp6BtedoSLu4+TX6aelr32RishbV72HYMnE6LorYtS34/56IVpdUg/biMAI33mqqIdHRiseHI2rNHGCkfUwJhrSS+CGRVCeurSWXmE77/s14ZoyaCBBELtrrwrgwQ=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:41858) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gfPeB-0001JJ-2A; Fri, 04 Jan 2019 14:36:25 +0100 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id D17D865409FB; Fri, 4 Jan 2019 14:36:14 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 0CCE25504BA2; Fri, 4 Jan 2019 14:36:14 +0100 (CET) X-CTCH-RefID: str=0001.0A0B0213.5C2F6159.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: help Questions , Cellar list Date: Fri, 04 Jan 2019 14:36:13 +0100 Message-ID: <87y380h7ea.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v30.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 13:36:34 -0000 Hey, 2019 is here along with the first release of MKVToolNix for the year, v30.0.0. It's on the smaller side wrt. the number of user-visible changes. It does contain a couple of usability enhancements for the GUI, though, that folks will hopefully appreciate. Nothing has changed for package managers since v29.0.0. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 30.0.0 "Interstellar" 2019-01-04 ## New features and enhancements * mkvextract: WAV extractor: mkvextract will now write W64 files instead of WAV files if the file name extension is `.w64` or if the final file size = is bigger than 4 GB, the file size limit for WAV files. Implements #2458. * MKVToolNix GUI: multiplexer: a new button was added next to the "destinat= ion file" controls. Clicking it shows a menu with the ten most recently used output directories. Selecting one of them will change the destination file to the selected directory keeping the file name. Implements #2468. * MKVToolNix GUI: multiplexer (preferences): the ten most recently used val= ues for the "relative output directory" and "fixed output directory" settings are now saved. The corresponding settings have been changed into combo bo= xes allowing quick access to those recent values. * MKVToolNix GUI: multiplexer (preferences): the predefined split sizes and durations can now be customized in the preferences. * MKVToolNix GUI: chapter editor: added an option in the "Chapter editor" m= enu for appending chapters from an existing file to the currently open editor tab. Part of the implementation of #2439. * MKVToolNix GUI: chapter editor: added an action in the context menu for copying the selected entry and all of its children to another open editor tab. Part of the implementation of #2439. ## Bug fixes * mkvmerge: all files opened for writing will now be flushed once before they're closed. This ensures the operating system actually writes all cac= hed data to disk preventing data loss in certain situations such as power outages or buggy drivers in combination with suspending the computer. Fix= es #2469. * mkvmerge: AAC: under certain conditions 8 channel audio files were taken = for 7 channel ones. * MKVToolNix GUI: multiplexer: removing a file added as an "additional part" will no longer cause a crash. Fixes #2461. * source code: fixed compilation with Boost 1.69.0 after API-breaking change to the `boost::tribool` class. Fixes #2460. ------------------------------------------------------------ Have fun :) mosu From nobody Sat Jan 5 08:43:55 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA42130DDB for ; Sat, 5 Jan 2019 08:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org 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 l0TOLJ5sr7Zs for ; Sat, 5 Jan 2019 08:43:52 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 1C16B130DE2 for ; Sat, 5 Jan 2019 08:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To:From:References; bh=ji2Prea3pbfA9j1cmh921VpPJb/PCIgLFKoo2mJ6cl0=; b=l4xEiF6JwLSNX7ENeThNjQJDssdwbPw6ZXlq/G1U1QB7AeHYEkH9FAIptsERwwD3e85pDeOxDN3BD0redQHAuIky3FyR0OFRXpOsf2ZkpptjfD+/x1NslAt/+XRxR36XC4+fy2iFjzHYH91CXIAQjjkIjVuboDDm5kWfCFxYFMM=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:53598) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gfp30-0004ik-1H; Sat, 05 Jan 2019 17:43:42 +0100 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 44C0D65409FB; Sat, 5 Jan 2019 17:43:35 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 865CA5531856; Sat, 5 Jan 2019 17:43:34 +0100 (CET) X-CTCH-RefID: str=0001.0A0B020D.5C30DEBE.0021, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 References: <87y380h7ea.fsf@bunkus.org> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: help Questions , Cellar list In-reply-to: <87y380h7ea.fsf@bunkus.org> Date: Sat, 05 Jan 2019 17:43:34 +0100 Message-ID: <87r2drgimh.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] MKVToolNix v30.1.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 16:43:54 -0000 Hey, due to an unfortunate bug in v30.0.0 that caused the GUI's chapter editor to truncate Matroska/WebM files to a few KB, I have to release v30.1.0 today. This release also implements a workaround for dragging & dropping not working on macOS with Qt 5.12 (due to a bug in Qt). Nothing has changed for package managers since v29.0.0. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 30.1.0 "Forever And More" 2019-01-05 ## Bug fixes * build system: fixed building on non-UTF-8 locales. Fixes #2474. * MKVToolNix GUI: multiplexer: implemented a workaround for drag & drop not working on macOS with Qt 5.12 due to a bug in Qt 5.12. Fixes #2472. * MKVToolNix GUI: chapter editor: when opening a Matroska/WebM file that doesn't contain chapters and later saving chapters back to them, the edit= or was truncating the file down to a couple of KB in size. This was a regression introduced with the implementation of #2439 in v30.0.0 Fixes #2476. ------------------------------------------------------------ Have fun :) mosu From nobody Mon Jan 7 13:15:09 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843A512D7F8; Mon, 7 Jan 2019 13:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, WEIRD_QUOTING=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 KmmVOXJrnvDJ; Mon, 7 Jan 2019 13:15:05 -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 CF51A12D7EA; Mon, 7 Jan 2019 13:15:02 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x07LExV8004617 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Jan 2019 15:15:00 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546895701; bh=JJ73mhQXDDSjZ3p9apHzNmU03ozkJc2Lp1nrhCLwNFw=; h=From:Subject:Date:To; b=M/l4Q2DzzgZeUhvCB/EhIW0RxJaKV958eS6kdOol9Xerc3HE2WhSWhGwox5ASSUIM A2JVQ65QDHvTWVYYqsxfoNRvHp1PdfWScK8vLP9Dzo5aMLtc9QxWBcwcf6jO8PG80M lCHCtNTouyjy7xqBMp3bgEJpzn1HBaincDtqBatw= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_70D7F719-C93D-452C-A5CD-B15CED78D315"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> Date: Mon, 7 Jan 2019 15:14:58 -0600 To: draft-ietf-cellar-ebml.all@ietf.org, cellar@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 21:15:08 -0000 --Apple-Mail=_70D7F719-C93D-452C-A5CD-B15CED78D315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-cellar-ebml-08. Thanks for this work. It's generally on the right track, but I have a = number of comments that I would like to discuss prior progressing. Thanks! Ben. *** Substantive Comments *** - The Shepherd Report says "There are minor nits to be resolved (adding = one RFC 2119 keyword and some schema attributes which are = mentioned but not defined." Do that comment still apply? To be clear, those are more than nits. = Adding a 2119 keyword is substantive change that needs to be agreed to = but the working group. Undefined attributes suggest that the draft is = incomplete. If the comment is still accurate, then these need to be = fixed prior to progressing the draft. If it is not accurate, then I ask = the shepherd to please update the shepherd report. - I'm a little surprised to see the draft describe EBML as a general = purpose markup language format, as opposed to one designed to be used by = Matroska and similar technologies. I suspect others will also be = surprised during the IETF LC and IESG review. The review bar is higher = for the IETF to recommend EBML as a general purpose markup language than = it is to recommend it for specific purposes. I also note that the CELLAR = charter talks about EBML in terms of being used by Matroska and FFV1. Would it be acceptable to add some scoping language to the effect of = "EBML is used by Matroska[citation] and FFV1[citation]. It MAY be used = for use cases similar to those. The applicability of EBML for other use = cases is beyond the scope of this document". - There are several defined elements/attributes related to versioning, = but I don't find an explanation of how they all work together. Please = add a section describing versioning in general. =C2=A72: Please use the newer boilerplate from RFC 8174. =C2=A73: Can you offer guidance on the specific impacts of the mentioned = attacks, and how to mitigate them? (If there is no way to mitigate an = attack, it's okay to say that.) =C2=A75: Please elaborate on how this is similar to UTF8. I assume this = refers to using prefix bits to indicate the field length. UTF8 does that = to maintain backwards compatibility with Ascii. What is the design = motivation for using that approach for EBML, which I presume doesn't = have such a requirement? =C2=A75.3: "If the number of bits required for "VINT_DATA" are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be zero-padded to the left to a size that fits." Why not MUST? What happens if this is violated? =C2=A76: - "The "VINT_DATA" component of the "Element ID" MUST NOT be either defined or written as either all zero values or all one values." Why? =C2=A78.7: "In this case, the "EBML Reader" should skip data until a valid..." Should that be a normative statement? If so, why should and not MUST? =C2=A78.8: If the EBML reader does not interpret Binary Elements, why = add them at all? What does interpret them? is the point that the EBML = reader treats Binary Elements as opaque, and just hands them to the = application? =C2=A710.1.3: "NOT RECOMMENDED" seems overly strong, especially in light = of the MAY in the first paragraph. Is the point to say "MUST NOT... = except when the implementation needs to update an element without = rewriting the entire document"? =C2=A711: "An "EBML Document" consists of "EBML Elements" and MUST NOT contain any data that is not part of an "EBML Element"." That contradicts text in =C2=A78.7 that says you can do this in = streaming use cases. =C2=A713.1: "The "DocType" value for an "EBML Document Type" SHOULD be unique and persistent." What is the scope of uniqueness? How should it be achieved? Is there an = expectation to register Document Types? (Also, why not MUST)? =C2=A713.1.4.1: Are there uniqueness requirements for name? =C2=A713.1.4.2: - The idea behind "path" needs elaboration. I'd like to see some = high-level discussion of how you indicate where an element is allowed, = and how you encode the structure. An example (local to the section) = would be helpful. =C2=A713.1.4.4: - "The "minOccurs" value MUST be equal to the "EBMLMinOccurrence" value of the "path"." Why have both if they have to be the same? (Same question for = =C2=A713.1.4.5) =C2=A713.1.4.12: - "If the "recurring" attribute is not present then the "EBML Element" MUST be considered to NOT be an "Identically Recurring Element"." "be considered to" is vague for a MUST. What concrete action must = implementations take in this case? =C2=A713.1.6.2: - It seems likely readers will confuse "type" with "data type". Would it = be reasonable to call this "document-type" or something similar? =C2=A713.1.10: - Please state (and cite) which XML schema format is used here. - Has the schema been mechanically verified? =C2=A713.3.1: - "The CRC value MUST be computed on a little endian bitstream and MUST use little endian storage." Please elaborate. Most elements have been big-endian so far. Do there = have to be converted to calculate the CRC? =C2=A715.1: - "The numbers 0x3FFF and 0x4000 are RESERVED.", "The numbers 0x1FFFFF = and 0x200000 are RESERVED.", and "The numbers 0xFFFFFFF and 0x1000000 = are RESERVED." What is the purpose of reserving them? - "Four octet Element IDs whose lower three octets (as encoded) would make printable 7-bit ASCII values may be allocated only Specification Required." Can you state a range or a list? Don't make IANA judge which values are = printable. =C2=A715.2: - "The strings may be allocated according to First Come First Served" Is there a requirement to register them, or is this optional? *** Editorial Comments and Nits *** - General: The draft puts double quotes around every mention of terms = that it defines. That is unconventional for IETF documents. I personally = find that it makes the draft harder to read. I suggest quoting them on = the first mention, then just capitalizing them in subsequent mentions. - General (style comment): Please consider removing most instances of = the word "considered". When the text says "X is considered to be equal = to Y", that sounds like a weaker (and harder to read) statement than "X = is equal to Y". Along the same lines, "considered" is rarely appropriate = to use in a normative statement. For example, instead of saying = "Implementations MUST consider X to be an error", it is better to state = what concrete actions you expect the implementation to take when X = occurs. =C2=A73: - The Security Considerations are required to be one of the last two = sections in the body of the document (that is, before the references). = More precisely, Security Considerations and IANA considerations should = be the last two sections in the documents. - first paragraph: Please expand CRC on first mention. (Which may or may = not be this instance once the Security Considerations are moved to the = proper place.) =C2=A75.2: "The "VINT_MARKER" MUST be one bit in length and contain a bit with a value of one." That's really more of a definition or statement of fact than a normative = requirement. Please consider replacing MUST with "is". =C2=A75.3: - "The bits required for the "VINT_WIDTH" and the "VINT_MARKER" combined use one out of eight bits" Consider "use one out of every eight bits" =C2=A75.4, paragraph after first table: "Data encoded as a "Variable = Size Integer" MAY be rendered at octet lengths larger than needed to store the data." Is that intended as permission, or a statement of fact? If the latter, = then the normative keyword is not appropriate. =C2=A76: - "The "Element ID" MUST be encoded as a "Variable Size Integer"." That seems like a definition. Consider s/MUST/is - "MUST NOT be considered an error in the "EBML Document"." "be considered" is vague for a normative requirement. What concrete = action is being prohibited (or required)? =C2=A77: - "The "Element Data Size" itself MUST be encoded as a "Variable Size Integer"." Consider s/MUST/is - 'Only "Master Elements" SHALL be "Unknown-Sized Elements".' The use of "only" in normative statements can be ambiguous. In this case = it can be read that non-master elements MUST NOT be of unknown size, or = that the SHALL only applies to master elements, and there is no rule for = non-master elements. Please consider formulating this as "MUST NOT". - "For example, an "EBML Element" with an octet length of 127 MUST NOT be encoded in an "Element Data Size" encoding with a one octet length." Examples are not normative, therefore they should not include normative = keywords. =C2=A78.1: "Signed Integers MUST be stored with two=E2=80=99s complement notation" Please consider s/MUST/are =C2=A710.1.2: "This method is only RECOMMENDED for reducing "Element = Data" by a single octet..." Please avoid using "only" in normative requirements (see previous = comment for explanation). =C2=A711.1 - 'that uses an"EBMLVersion" of "1" MUST only contain "EBML Elements"' Please avoid "only" on normative statements. - last paragraph: Please consider dropping "All" from the beginning of = each sentence. =C2=A711.1: - Is the concept of a file concrete (in the sense of a unit of = persistent storage) or abstract (as in any stream of data)? I had = assumed the latter, but with the different rules about data outside of = EBML elements for "files" and "streaming applications", I am not so = sure. If you mean "file" concretely, does there need to be additional = text in this section describing the structure for streaming = applications? - "The "EBML Body" MUST consist only of "EBML Elements"" Please avoid "only" on normative statements. - 'what "EBML Elements"' (several occurances). s/what/which =C2=A713.1: - "one or many" (several times throughout draft): Should this be "one or = more"? Some people do not tend to think of numbers like 2 or 3 as = counting as "many". - "An "EBML Schema" must be expressed as well-formed XML." Normative? - "An "EBML Schema" MUST declare exactly one "EBML Element" at "Root Level" (referred to as the "Root Element") that MUST occur exactly once within an "EBML Document"." The second "MUST" seems like a statement of fact. - If an "EBML Schema" adopts the "EBML Header Element" as-is, then it is not REQUIRED to document that Element within the "EBML Schema"." "REQUIRED" is not used normatively, and therefore should not be = capitalized. =C2=A713.1.1.2: - "The "version" lists an incremental non-negative integer..." I'm not sure what it means for a single integer to be "incremental". = (But see substantive comment concerning versioning.) =C2=A713.4.1.2: - The ""*"", ""("" and "")"" symbols MUST be interpreted as they are defined in the ABNF." This _is_ the ABNF. Do you mean "as defined in RFC 5234? Also, the = normative MUST is not appropriate here; it's a matter of definition, not = a normative requirement. - "The "EBMLElementOccurrence" part is interpreted as an ABNF Variable Repetition. I don't understand what that means. There won't be ABNF in an actual = schema, will there? (Same for "VariableParentOccurrence") - ""EBML Elements" with "EBMLMinOccurrence" set to "1" that also have a "default" value (see Section 13.1.4.8) declared are not REQUIRED to be stored but are REQUIRED to be interpreted," Statement of fact? =C2=A713.1.4.7 - The attribute is called "size" but defined to be "length". Why not = call it length? (Or describe it as "size")? =C2=A713.1.4.10: - "A boolean to express if an "EBML Element" MAY be used as an "Unknown- Sized Element"" Statement of fact. =C2=A713.1.11: It would be helpful to have the example closer to the = element descriptions. I suggesting putting this section before the = schema section. =C2=A713.1.13: Why is the material is this section separate from the = range element description? =C2=A713.1.14: - "When a float value is represented textually in an "EBML Schema", such as within a "default" or "range" value,..." The examples only talk about ranges. Can there be an example for a = default value? =C2=A713.1.15: - "In this case, the default value of the "Mandatory EBML Element" MUST be interpreted by the "EBML Reader" although the "EBML Element" is not present within its "Parent Element"." I'm not sure the intent here. Is "interpreted" the correct word choice? =C2=A713.3.2: - "Used to void damaged data, to avoid unexpected behaviors when using damaged data." Comma splice. =C2=A714 - "If a "Master Element" contains a "CRC-32 Element" that doesn=E2=80=99t validate, then the "EBML Reader" MAY ignore all contained data except for "Descendant Elements" which contain their own valid "CRC-32 Element"." s/ ", which" / " that" =C2=A715.1: - "Values from 1 to 126 are to be allocated according to RFC Required." I suggest '... allocated according to the "RFC Required" policy.' (Note: = This pattern occurs several times in the RFC considerations section.) = Also, please cite 8126 on the first mention of each policy (or state in = advance that all registration policies mentioned herein are defined in = 8126). - "Numbers MAY be allocated within this range according to Specification Required." s/MAY/are --Apple-Mail=_70D7F719-C93D-452C-A5CD-B15CED78D315 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwzwVIACgkQgFZKbJXz 1A3d5Q//SodDIYqqPkJLN8/Ecm6D7FZU71NXDsWaqq+7ELxt7Kyp0xbKXVR2vOpC oqi+XtDcFGI7aIjR3CfYVsVI9oQO1PMhb+OTPDJx5KDPb88qEqKoRxzHafSqV9c5 6R90wYnqOxKZaCejPJftF2Gwraql1IX8P6B+bueIaCbCWKYq9QsH8xn2tzkJVNs1 02UlhL5oNSlNtj47UGzbFFW3Yeaek2wOd8ZNbiajvBFpJLLhdzvXc6iOfNvn39yH RLp+1hkJkwZtmh8P2moYXd8Ni4PpA241cveNvRkwZ59xtW55qE7kr8ivNiJNUDkn 2MkEtmdJ28ybw4H854NI6CNNUNimmeizFVMS2g3lQls4XQxD0NjgCCvEwxmzSS8/ FXEe6MXvWfmHf05sPX8VX9//TvsGB8hVmNE2LwWgkNaxLkakUg1/1Bvob86IZQvK /jmguLTj5M9gbKVNVDQZi5Hiij/S0QBLO7jr8aIQxaBLnvdaLTS6u3mRO25ox2PB 38rRZR6+IIn7hBeqZiK6SOzsgJH2ldVvZcujSZ2FXVghI+dCfMHAVBDzovzn4FbT PlE/JH8wtUjdUIzVDChKbapAjpsxAu5mAAfFJjzHfZw+lK2NWTkuU1FMuxO9ifJI qnV3Z53dYEJnymQJMo+fQOYlb9oANB3eBWjzDqv+o8og/PQe+Yk= =LGkp -----END PGP SIGNATURE----- --Apple-Mail=_70D7F719-C93D-452C-A5CD-B15CED78D315-- From nobody Tue Jan 8 09:29:45 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778B7130F1F for ; Tue, 8 Jan 2019 09:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6AXGZ7mO-5g9 for ; Tue, 8 Jan 2019 09:29:41 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 AABD4130F0F for ; Tue, 8 Jan 2019 09:29:41 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id j21so3964380oii.8 for ; Tue, 08 Jan 2019 09:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7I+UYJme2+BLAWvFNe9Gp3F/vJZ/6sII35/Skx2++rc=; b=XWc28CBOhixPrE6/C3lngrKH/TdbrgbhOuquM1L6GRsy+dpGQrhJjb0wFdPXqQU1Ng FjgCigKat41srYDS/6ikL3UcvMtNOh9K4jH4bQUw907x9AyhZmqQMNr5R5I0zYAq8kGF Q2LdtpjiAqC4eD4lmv3QYcThUKI9ZVzmxwR0GXP2rbUEIJUtorfp7nKRj+3Q1oVAtK05 vvoIw2FDcLdHhaOIlYQ5fjtcEKYbf+li4o5gby+TS93B5vgTHNR/uDAPb+6un552HteS l4JSg3Rtsf83LnNhzgXFZfj7ts43VNBrI6FNheL7jbK1i6kXYY+MzGaoob+tmjk6+KqE CC9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7I+UYJme2+BLAWvFNe9Gp3F/vJZ/6sII35/Skx2++rc=; b=Vc7AoltOTPTDNOegnS/Aq8/SNwqxLNCqS8FuydVJif6RuSQHGwaXTE7zSP7wnFlMKy GEVoUfZOlDk4FgoTyaxqBMD+Kg+eGanEs/7R35Sg+UnslejVeah0IOnSCx1YxaWPnMv/ G8actozdXmUy4sVBa7duT4D5PooOmTbM1bKrrG574MJGAON2LL80c+ClZum7dMTuj0um LIIOZ9455F2eOK0U1GDcWU4kpV7t6Q+FL81k5G26EV6VEBjTnDgEp+6zJFaXkPe3uOoQ u8eWpfSHqcdSPvs+Z8q2GG7mtysiGoKQmnlrWZxcw0zYt/B0CvkO3qYaqMrz05d7u7Xp P0OA== X-Gm-Message-State: AJcUukc7EsY2AIDCZMATR9FpgyUhO6AGlX/e7Adgv5etgc3b2GMuVfUN stCSmCocNAwwyKVm3zP4vfLEXOIbcOkOBempIgMjyrNg X-Google-Smtp-Source: ALg8bN6ksNcgWSgvn9eGnYVxEgvljJZv0CMv6z8U/EPBcI4MsjfX01xi5egmzEuqsg5HRXYX5on9iWNspQpTAPMfo80= X-Received: by 2002:aca:b184:: with SMTP id a126mr1752224oif.187.1546968580612; Tue, 08 Jan 2019 09:29:40 -0800 (PST) MIME-Version: 1.0 From: Andrew Weaver Date: Tue, 8 Jan 2019 09:29:29 -0800 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000b9e74c057ef5b035" Archived-At: Subject: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:29:43 -0000 --000000000000b9e74c057ef5b035 Content-Type: text/plain; charset="UTF-8" Hello All, I wanted to float the idea again of the creation of a new more centralized/obviously CELLAR affiliated repository for the continuation of the work on FLAC. This came up at the IETF meeting in 2017, where it was thought that moving the work to date out of its current location on my personal github ( https://github.com/privatezero/flac_markdown) would facilitate participation and visibility for the efforts. This should also allow a little better management of permissions etc. If there was consensus about this vis-a-vis name etc, I would be happy to set this up. All the best, Andrew --000000000000b9e74c057ef5b035 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,

I wanted to float the idea again of the creation of a new = more centralized/obviously CELLAR affiliated repository for the continuatio= n of the work on FLAC.

This came up at the IET= F meeting in 2017, where it was thought that moving the work to date out of= its current location on my personal github (https://github.com/privatezero/flac_markdown= ) would facilitate participation and visibility for the efforts. This shoul= d also allow a little better management of permissions etc.

<= /div>
If there was consensus about this vis-a-vis name etc, I would be = happy to set this up.

All the best,
Andr= ew




--000000000000b9e74c057ef5b035-- From nobody Tue Jan 8 09:34:58 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C612130F27 for ; Tue, 8 Jan 2019 09:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hZ_Z0Jp0qGvh for ; Tue, 8 Jan 2019 09:34:54 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 2FB9A130F25 for ; Tue, 8 Jan 2019 09:34:54 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id g76so7427028itg.2 for ; Tue, 08 Jan 2019 09:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=glyEuQQXSZPk+ziN5kXoj57pf5OFiKXmNuK4XgcJ3CE=; b=Z2i+Fz0/ZJivTOgjaRMI0odrgZUmS9c5vOgjqyqyt6nynR5z6Cothnp8p/7VWyY0jI zcCOc/oVPob+vpeMLan8L0OAnx64MELhKthER1W5OyrrlIDZiwt4tHbA30ve2M6d5JeL OClwPu5ZVaGs/QfSETbtnFUSG7Mndz9GRkB7ozRyeCnSapbbQ/fM3Jjym96xS7wz3m9p 4ZnL/ZwHRrUe6iiPASZm9dfNS7Sm3AgPrby3LHwgcEu0lSAKnl0YxZwEut11KQrBHMMG kkHn7qDQewM0JkwwKpRRKbbN4d6XhEwWCipNV/QgZgsdVjjkrI/GGlDSeliD9onAeSBy PPeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=glyEuQQXSZPk+ziN5kXoj57pf5OFiKXmNuK4XgcJ3CE=; b=oncCsBk2KtRHzxf5QieMBsq+aIgjyJZSRby8nj0GCll4iUphPPddZxCKs6lDq6kzj4 AN2efncCV+eQSz8Zgzve91fFsjGsZQ2CezS2udg8WXuD21ehp0gQBpHhYiF+arSbrKWX UiyK3fY58/q3f+upZl5Xcbsz/bNpxCjOfxmVQEvyxv8GNwMrdrFIsAFaRXKWbyFULaWm 8H1TJUHJ+z0QvBmsyil2hVj71r12HHDU6btJCKg+htA2QDuPF3k7ChwLQ4SEhE4I5wsi D84g4JmZ+MkUNFMDQWKShWkcGK4hEHQxPjlRCJU9s0X5gzbHwBqayJREK8mo8y+nuK1F ijkQ== X-Gm-Message-State: AJcUukchypmIDnuNhUKbWDSHGA5oQnVJcRY3tJmJ23/ZpNVNCwIbNCKR gSMxYs/a4aI+FV5iHyDPTs3DFs4pfSbnsqrYf9k= X-Google-Smtp-Source: ALg8bN6BsJzIxc2ORtUAWJI95qUfP/3qYstdqoveznvG0B7dfCLlftw8AiT6jwtfGjCe1XoeR1Ndrb9dzCy8aOohYJc= X-Received: by 2002:a24:99c5:: with SMTP id a188mr1825900ite.110.1546968893488; Tue, 08 Jan 2019 09:34:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ashley Blewer Date: Tue, 8 Jan 2019 12:34:42 -0500 Message-ID: To: Andrew Weaver Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000600431057ef5c35e" Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:34:56 -0000 --000000000000600431057ef5c35e Content-Type: text/plain; charset="UTF-8" +1, I agree with this. It is probably worth hitting up the FLAC listserv with some reminders about this too, and keeping them up to date with the work that happens here. Ashley On Tue, Jan 8, 2019 at 12:29 PM Andrew Weaver wrote: > Hello All, > > I wanted to float the idea again of the creation of a new more > centralized/obviously CELLAR affiliated repository for the continuation of > the work on FLAC. > > This came up at the IETF meeting in 2017, where it was thought that moving > the work to date out of its current location on my personal github ( > https://github.com/privatezero/flac_markdown) would facilitate > participation and visibility for the efforts. This should also allow a > little better management of permissions etc. > > If there was consensus about this vis-a-vis name etc, I would be happy to > set this up. > > All the best, > Andrew > > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --000000000000600431057ef5c35e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1, I agree with this. It is probably worth hitting u= p the FLAC listserv with some reminders about this too, and keeping them up= to date with the work that happens here.

Ashley

On Tue, Jan 8= , 2019 at 12:29 PM Andrew Weaver <theandrewjw@gmail.com> wrote:
=
Hello All,

I wanted to float the idea again o= f the creation of a new more centralized/obviously CELLAR affiliated reposi= tory for the continuation of the work on FLAC.

This came up at the IETF meeting in 2017, where it was thought that moving= the work to date out of its current location on my personal github (https:= //github.com/privatezero/flac_markdown) would facilitate participation = and visibility for the efforts. This should also allow a little better mana= gement of permissions etc.

If there was consensus = about this vis-a-vis name etc, I would be happy to set this up.
<= br>
All the best,
Andrew

<= br>


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--000000000000600431057ef5c35e-- From nobody Tue Jan 8 11:25:02 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92E312426E for ; Tue, 8 Jan 2019 11:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 lmzXegjLeSqC for ; Tue, 8 Jan 2019 11:24:58 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 F2894130FB7 for ; Tue, 8 Jan 2019 11:24:57 -0800 (PST) Received: from [146.96.19.240] (port=57724 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ggwzb-003Ett-RI; Tue, 08 Jan 2019 14:24:53 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_729A54C3-835A-40AC-A1F4-C18C90700128" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 8 Jan 2019 14:24:50 -0500 In-Reply-To: Cc: Andrew Weaver , Codec Encoding for LossLess Archiving and Realtime transmission To: Ashley Blewer References: X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 19:25:00 -0000 --Apple-Mail=_729A54C3-835A-40AC-A1F4-C18C90700128 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Uncertain if the IETF provides specific guidance with this, but I=E2=80=99= m okay with the markdown work happening in either your repo or an = organization account as long as the repo=E2=80=99s maintainer is active = in the group and in the management of pull requests and issues. The = working group data tracker is where official versioning will happen, so = the github repo is a bit more behind the scenes. Dave > On Jan 8, 2019, at 12:34 PM, Ashley Blewer = wrote: >=20 > +1, I agree with this. It is probably worth hitting up the FLAC = listserv with some reminders about this too, and keeping them up to date = with the work that happens here. >=20 > Ashley >=20 > On Tue, Jan 8, 2019 at 12:29 PM Andrew Weaver > wrote: > Hello All, >=20 > I wanted to float the idea again of the creation of a new more = centralized/obviously CELLAR affiliated repository for the continuation = of the work on FLAC. >=20 > This came up at the IETF meeting in 2017, where it was thought that = moving the work to date out of its current location on my personal = github (https://github.com/privatezero/flac_markdown = ) would facilitate = participation and visibility for the efforts. This should also allow a = little better management of permissions etc. >=20 > If there was consensus about this vis-a-vis name etc, I would be happy = to set this up. >=20 > All the best, > Andrew >=20 >=20 >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_729A54C3-835A-40AC-A1F4-C18C90700128 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Uncertain if the IETF provides specific guidance with this, = but I=E2=80=99m okay with the markdown work happening in either your = repo or an organization account as long as the repo=E2=80=99s maintainer = is active in the group and in the management of pull requests and = issues. The working group data tracker is where official versioning will = happen, so the github repo is a bit more behind the scenes.
Dave

On Jan 8, 2019, at 12:34 PM, = Ashley Blewer <ashley.blewer@gmail.com> wrote:

+1, I agree with this. It is probably worth = hitting up the FLAC listserv with some reminders about this too, and = keeping them up to date with the work that happens here.

Ashley

On Tue, Jan 8, 2019 at 12:29 PM Andrew Weaver = <theandrewjw@gmail.com> wrote:
Hello = All,

I wanted = to float the idea again of the creation of a new more = centralized/obviously CELLAR affiliated repository for the continuation = of the work on FLAC.

This came up at the IETF meeting in = 2017, where it was thought that moving the work to date out of its = current location on my personal github (https://github.com/privatezero/flac_markdown) would = facilitate participation and visibility for the efforts. This should = also allow a little better management of permissions etc.

If there was consensus = about this vis-a-vis name etc, I would be happy to set this = up.

All the = best,
Andrew




_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
=
_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_729A54C3-835A-40AC-A1F4-C18C90700128-- From nobody Tue Jan 8 11:36:06 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9161E130FD6 for ; Tue, 8 Jan 2019 11:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Oky3PnYUxLjm for ; Tue, 8 Jan 2019 11:36:03 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 3578212426E for ; Tue, 8 Jan 2019 11:36:03 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id 81so4585444otj.2 for ; Tue, 08 Jan 2019 11:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D+9j9ZTgfoE+mcTyEZVqSrFcUqY86QCrt7RRDjfeDYw=; b=ghj+Elf3w443SSJDMXuB9R/PKM/c5tDarvY7vnzFfE2qSLI8zLG0wJu30iOFrAoKVN u5dSumpsBFV6wkpUP/4BXkKBvFCYo5ylYvD+tyspQl/GqtaMqQiSyUsHSxoTDv+IpjSV FwxyK3pFiXG4rltUs+J/UcNurTnr6qPTQM/rFWAFbQomuGLmS0lCNGlAHHpgGfOnOYqn bIjVtlEXrNA+wNgH7P45oR44J92XS/AipqplPtYq954jKg//noqKGx5qSxvCMjoy1cfU lBz0pVNjrubU7KgqGWl1kqAnQYHiRe2OatGCPHRkiZTWQuagmyJMIIqGc5uSABuDi1LM t4xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D+9j9ZTgfoE+mcTyEZVqSrFcUqY86QCrt7RRDjfeDYw=; b=cScUmI9vM1yNeSlXikZgIL7QioV95tbo3hSPfsnXKBUS3VwI8Xrj12S+X2i1n4UtFN DCs+2e3pJuSMvEFqwxE+hGjAeURc2+BWIYmagAREMjhskEPFtM95SYGcwPI3uReA95qC wYIln6eTGDt7ZCYNRf27FhRMcEiXtbyMOreHuhIROXPIHyrwA4m4tq70Kk6i4+bIk3HY WL698aqIocANgRCyn7GJ+J4XoCsbN8/aUohlSU+9amJUjhycnHa784ntktKzwmArykQD B2XH2sbXzGC+wSN0Ax+1czuIB7w/bClmBZ4WAmdwEqZaeYP9rTU7eD++TCUI53CGTFAb qVHA== X-Gm-Message-State: AJcUukfbUYTsa0YC0hQKTaMEOPi5IGQrlugKoO4LJDuXneLYDCpsBI5y zOb4dde4pKnisu/SjNrTzI2AycrVvidK8s4K1YI= X-Google-Smtp-Source: ALg8bN5mKbOUa0KInYFtlcUzxSq6xscKrtfWXiuVP4X4w2+d2tWnXNW/f+517Z9XUcs1fBI8UpLAsKYRWVQsBia5isI= X-Received: by 2002:a9d:39f7:: with SMTP id y110mr1926534otb.240.1546976162376; Tue, 08 Jan 2019 11:36:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Weaver Date: Tue, 8 Jan 2019 11:35:51 -0800 Message-ID: To: Dave Rice Cc: Ashley Blewer , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000a2707d057ef77452" Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 19:36:06 -0000 --000000000000a2707d057ef77452 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With regards to maintaining the repo, I would be quite happy to continue managing that along the lines of what you describe. Additionally I could then invite the people who are currently 'collaborators' on the repo to have ownership privileges. That feels to me a little bit more open and democratic for the work rather than the current version where I have de facto control. On Tue, Jan 8, 2019 at 11:24 AM Dave Rice wrote: > Uncertain if the IETF provides specific guidance with this, but I=E2=80= =99m okay > with the markdown work happening in either your repo or an organization > account as long as the repo=E2=80=99s maintainer is active in the group a= nd in the > management of pull requests and issues. The working group data tracker is > where official versioning will happen, so the github repo is a bit more > behind the scenes. > Dave > > On Jan 8, 2019, at 12:34 PM, Ashley Blewer > wrote: > > +1, I agree with this. It is probably worth hitting up the FLAC listserv > with some reminders about this too, and keeping them up to date with the > work that happens here. > > Ashley > > On Tue, Jan 8, 2019 at 12:29 PM Andrew Weaver > wrote: > >> Hello All, >> >> I wanted to float the idea again of the creation of a new more >> centralized/obviously CELLAR affiliated repository for the continuation = of >> the work on FLAC. >> >> This came up at the IETF meeting in 2017, where it was thought that >> moving the work to date out of its current location on my personal githu= b ( >> https://github.com/privatezero/flac_markdown) would facilitate >> participation and visibility for the efforts. This should also allow a >> little better management of permissions etc. >> >> If there was consensus about this vis-a-vis name etc, I would be happy t= o >> set this up. >> >> All the best, >> Andrew >> >> >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > > --000000000000a2707d057ef77452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With regards to maintaining the repo, I would be quit= e happy to continue managing that along the lines of what you describe. Add= itionally I could then invite the people who are currently 'collaborato= rs' on the repo to have ownership privileges. That feels to me a little= bit more open and democratic for the work rather than the current version = where I have de facto control.

On Tue, Jan 8, 2019 at 11:24 AM Dave Rice <dave@dericed.com> wrote:
Uncertain if the IETF provides specific guidance with this, but I=E2= =80=99m okay with the markdown work happening in either your repo or an org= anization account as long as the repo=E2=80=99s maintainer is active in the= group and in the management of pull requests and issues. The working group= data tracker is where official versioning will happen, so the github repo = is a bit more behind the scenes.
Dave

On Jan 8, 2019, at 12:34 PM, Ashley Blewer <ashley.blewer@gmail.com> = wrote:

+1, I agree with this. It is probably worth = hitting up the FLAC listserv with some reminders about this too, and keepin= g them up to date with the work that happens here.

Ashley

On T= ue, Jan 8, 2019 at 12:29 PM Andrew Weaver <theandrewjw@gmail.com> wrote:
Hello All,

I wante= d to float the idea again of the creation of a new more centralized/obvious= ly CELLAR affiliated repository for the continuation of the work on FLAC.

This came up at the IETF meeting in 2017, where= it was thought that moving the work to date out of its current location on= my personal github (https://github.com/privatezero/flac_markdown) woul= d facilitate participation and visibility for the efforts. This should also= allow a little better management of permissions etc.

<= div>If there was consensus about this vis-a-vis name etc, I would be happy = to set this up.

All the best,
Andrew
=




_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
_______________________________________________
Cellar mailing list
<= a href=3D"mailto:Cellar@ietf.org" target=3D"_blank">Cellar@ietf.org
= = https://www.ietf.org/mailman/listinfo/cellar

--000000000000a2707d057ef77452-- From nobody Tue Jan 8 11:48:30 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C17B130FF0 for ; Tue, 8 Jan 2019 11:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 5KHCbtytmaah for ; Tue, 8 Jan 2019 11:48:27 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 35E5E130FEE for ; Tue, 8 Jan 2019 11:48:27 -0800 (PST) Received: from [146.96.19.240] (port=44647 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ggxMO-003ULH-An; Tue, 08 Jan 2019 14:48:26 -0500 From: Dave Rice Message-Id: <36829CA1-695B-4EF3-AB0A-6DCEFCE8C56A@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F09E7B71-AC45-4A9D-8896-BA8CF39243AB" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 8 Jan 2019 14:48:23 -0500 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Ashley Blewer To: Andrew Weaver References: X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 19:48:29 -0000 --Apple-Mail=_F09E7B71-AC45-4A9D-8896-BA8CF39243AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You could add a README.md that expresses that. I see some related = boilerplate in this search: = https://github.com/search?q=3Dietf+working+group+readme.md&type=3DCode = . Dave > On Jan 8, 2019, at 2:35 PM, Andrew Weaver = wrote: >=20 > With regards to maintaining the repo, I would be quite happy to = continue managing that along the lines of what you describe. = Additionally I could then invite the people who are currently = 'collaborators' on the repo to have ownership privileges. That feels to = me a little bit more open and democratic for the work rather than the = current version where I have de facto control. >=20 > On Tue, Jan 8, 2019 at 11:24 AM Dave Rice > wrote: > Uncertain if the IETF provides specific guidance with this, but I=E2=80=99= m okay with the markdown work happening in either your repo or an = organization account as long as the repo=E2=80=99s maintainer is active = in the group and in the management of pull requests and issues. The = working group data tracker is where official versioning will happen, so = the github repo is a bit more behind the scenes. > Dave >=20 >> On Jan 8, 2019, at 12:34 PM, Ashley Blewer > wrote: >>=20 >> +1, I agree with this. It is probably worth hitting up the FLAC = listserv with some reminders about this too, and keeping them up to date = with the work that happens here. >>=20 >> Ashley >>=20 >> On Tue, Jan 8, 2019 at 12:29 PM Andrew Weaver > wrote: >> Hello All, >>=20 >> I wanted to float the idea again of the creation of a new more = centralized/obviously CELLAR affiliated repository for the continuation = of the work on FLAC. >>=20 >> This came up at the IETF meeting in 2017, where it was thought that = moving the work to date out of its current location on my personal = github (https://github.com/privatezero/flac_markdown = ) would facilitate = participation and visibility for the efforts. This should also allow a = little better management of permissions etc. >>=20 >> If there was consensus about this vis-a-vis name etc, I would be = happy to set this up. >>=20 >> All the best, >> Andrew >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar = >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_F09E7B71-AC45-4A9D-8896-BA8CF39243AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You = could add a README.md that expresses that. I see some related = boilerplate in this search: https://github.com/search?q=3Dietf+working+group+readme.md&= type=3DCode.
Dave

On Jan = 8, 2019, at 2:35 PM, Andrew Weaver <theandrewjw@gmail.com> wrote:

With regards to maintaining the repo, I would = be quite happy to continue managing that along the lines of what you = describe. Additionally I could then invite the people who are currently = 'collaborators' on the repo to have ownership privileges. That feels to = me a little bit more open and democratic for the work rather than the = current version where I have de facto control.

On = Tue, Jan 8, 2019 at 11:24 AM Dave Rice <dave@dericed.com> = wrote:
Uncertain if the IETF provides specific guidance = with this, but I=E2=80=99m okay with the markdown work happening in = either your repo or an organization account as long as the repo=E2=80=99s = maintainer is active in the group and in the management of pull requests = and issues. The working group data tracker is where official versioning = will happen, so the github repo is a bit more behind the scenes.
Dave

On Jan 8, 2019, at 12:34 PM, = Ashley Blewer <ashley.blewer@gmail.com> = wrote:

+1, I agree with = this. It is probably worth hitting up the FLAC listserv with some = reminders about this too, and keeping them up to date with the work that = happens here.

Ashley

On Tue, Jan 8, 2019 at = 12:29 PM Andrew Weaver <theandrewjw@gmail.com> wrote:
Hello = All,

I wanted = to float the idea again of the creation of a new more = centralized/obviously CELLAR affiliated repository for the continuation = of the work on FLAC.

This came up at the IETF meeting in = 2017, where it was thought that moving the work to date out of its = current location on my personal github (https://github.com/privatezero/flac_markdown) would = facilitate participation and visibility for the efforts. This should = also allow a little better management of permissions etc.

If there was consensus = about this vis-a-vis name etc, I would be happy to set this = up.

All the = best,
Andrew




_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
=
_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_F09E7B71-AC45-4A9D-8896-BA8CF39243AB-- From nobody Tue Jan 8 14:02:17 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985EF130FAF for ; Tue, 8 Jan 2019 14:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FE4JETnQGBpg for ; Tue, 8 Jan 2019 14:02:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A85131196 for ; Tue, 8 Jan 2019 14:02:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 169CD3808A for ; Tue, 8 Jan 2019 17:01:46 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1C7BA9A7; Tue, 8 Jan 2019 17:02:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1A58E6E9 for ; Tue, 8 Jan 2019 17:02:11 -0500 (EST) From: Michael Richardson To: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 22:02:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Rice wrote: > Uncertain if the IETF provides specific guidance with this, but I=E2= =80=99m > okay with the markdown work happening in either your repo or an The IETF now prefers the repos to be in an organization account. e.g: ROLL has https://github.com/roll-wg ANIMA has https://github.com/anima-wg We haven't created one for CELLAR, and to first order https://github.com/Matroska-Org has provided this. If the FLAC work just doesn't fit in for some reason I can create a new org, but I don't see a pressing need. BTW: I want to point a few internet drafts will expire this week, and it would be good to post refreshes this wek. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlw1HeIACgkQgItw+93Q 3WXOHgf+Lr5YYqF0Ko64uwQAd8t9WSuS7xMnu9Ahi1jvqy6oF8ZLBY//clK5GED3 eRXFlP66DDhXzPgII4N0VpswUwf7g7/gn3W39yeJxVKhaV1uAfvprb7Be0ciDaTP nZZfsE0kXytyadiJkicsEWfGBjBrlCPRtLQSbpLEU7bV3qiD3KP4/xxUGV8qQcLA 7Hns+m9vpS42pwT7iIuuxrF3/JgTsfO2Oz7KvE755JKFiFGONZo5s2CG/lIPwbeD m3VDttVbnFsMhbNJ/k6qfrpBv/jLTv/WjuG67kdKGT428JetOCAC9HeZbBCO3ETg GeBRiIU1rIi+jl0Max7tIV3n8YyiUQ== =Nl9e -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 9 08:49:52 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81880130EEA for ; Wed, 9 Jan 2019 08:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 BUB72HYuJY5P for ; Wed, 9 Jan 2019 08:49:48 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 D0DB3130EA9 for ; Wed, 9 Jan 2019 08:49:48 -0800 (PST) Received: from [146.96.19.240] (port=9968 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ghH34-000xOx-Ex; Wed, 09 Jan 2019 11:49:47 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9EEA8AB1-C24E-4260-93AD-176BC9A62F17" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 9 Jan 2019 11:49:45 -0500 In-Reply-To: <17722.1546984931@localhost> Cc: cellar@ietf.org To: Michael Richardson References: <17722.1546984931@localhost> X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 16:49:50 -0000 --Apple-Mail=_9EEA8AB1-C24E-4260-93AD-176BC9A62F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Jan 8, 2019, at 5:02 PM, Michael Richardson = wrote: >=20 > Dave Rice wrote: >> Uncertain if the IETF provides specific guidance with this, but I=E2=80= =99m >> okay with the markdown work happening in either your repo or an >=20 > The IETF now prefers the repos to be in an organization account. > e.g: ROLL has https://github.com/roll-wg > ANIMA has https://github.com/anima-wg >=20 > We haven't created one for CELLAR, and to first order > https://github.com/Matroska-Org >=20 > has provided this. If the FLAC work just doesn't fit in for some = reason I > can create a new org, but I don't see a pressing need. I=E2=80=99d prefer to have a https://github.com/cellar-wg = organizational account to provide the = appearance that the work is underway under the context of the IETF = rather than the individuals or source communities that are hosting = currently. That would allow Andrew to transfer the repository from his = account to a shared one of the working group. > BTW: I want to point a few internet drafts will expire this week, and > it would be good to post refreshes this wek. I see this is happening with the Codec Mappings and Metadata Tags = documents for Matroska. I=E2=80=99ll post updates before they expire. = I=E2=80=99ll check on the FLAC output as well since that document had = already expired. Dave Rice= --Apple-Mail=_9EEA8AB1-C24E-4260-93AD-176BC9A62F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On Jan 8, 2019, at 5:02 PM, Michael = Richardson <mcr+ietf@sandelman.ca> wrote:

Dave Rice <dave@dericed.com> = wrote:
Uncertain if = the IETF provides specific guidance with this, but I=E2=80=99m
okay with the markdown work happening in either your repo or = an

The IETF now prefers the = repos to be in an organization account.
=    e.g:    ROLL has https://github.com/roll-wg
=           ANIMA has https://github.com/anima-wg

We= haven't created one for CELLAR, and to first order
=   https://github.com/Matroska-Org

has provided this.    If the FLAC work just = doesn't fit in for some reason I
can create a new org, but = I don't see a pressing need.

I=E2=80= =99d prefer to have a https://github.com/cellar-wg organizational account = to provide the appearance that the work is underway under the context of = the IETF rather than the individuals or source communities that are = hosting currently. That would allow Andrew to transfer the repository = from his account to a shared one of the working group.

BTW: I want to point a few internet drafts will expire this = week, and
    it would be good to = post refreshes this wek.

I see this is happening with the Codec Mappings = and Metadata Tags documents for Matroska. I=E2=80=99ll post updates = before they expire. I=E2=80=99ll check on the FLAC output as well since = that document had already expired.
Dave = Rice
= --Apple-Mail=_9EEA8AB1-C24E-4260-93AD-176BC9A62F17-- From nobody Wed Jan 9 09:45:51 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7E1130EEF for ; Wed, 9 Jan 2019 09:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 cxxffNRwiLOq for ; Wed, 9 Jan 2019 09:45:47 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 D30CB130F56 for ; Wed, 9 Jan 2019 09:45:46 -0800 (PST) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x09HjivZ025971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 9 Jan 2019 18:45:44 +0100 Received: from Castor.local ([IPv6:2a02:aa13:4680:f280:f93a:8ad4:d6d6:e312]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x09HjgUT012511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jan 2019 18:45:44 +0100 Date: Wed, 9 Jan 2019 18:45:44 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 17:45:50 -0000 Dave Rice wrote: >I=E2=80=99d prefer to have a https://github.com/cellar-wg >organizational account to provide the appearance that the >work is underway under the context of the IETF rather than >the individuals or source communities that are hosting >currently. +1 Best regards, Reto From nobody Wed Jan 9 10:57:40 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1F131008 for ; Wed, 9 Jan 2019 10:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6R6pK_x_7Mzp for ; Wed, 9 Jan 2019 10:57:37 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 E281A131017 for ; Wed, 9 Jan 2019 10:57:36 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id s5so7628063oth.7 for ; Wed, 09 Jan 2019 10:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/vvXfhmYUMNLtifIkMQ6u/IDa3Skg78C1DwS9wJwqMI=; b=pQYKG+BgPMZpLC7ayyg1DS5otmbcv9jzNowIgpgNh/YGjVjcXFnkEclkIkuGoq6mmN VE+Wg+74otVNdlSinJWroU0KWZRWQ3juiT0h2oRFSA4kWWfJcsHLkE7cGPCA+NIKmMvD yxOWG4pT57rgs7QrQZr58NbNWd/fW9qCwRbBDr+99LfbJZR9V33Ny+RODx0OyfehTzwT 4br2QMwd8jivnl4Sd2yXbvxQKwD9fUmu7hNhwdh1xmhjcE6elu1kaO6kWh9ZyD46PRcx HaGdnMCLFyeUhQL6HxOfCtEaW3Q1d03T7315RZAZXB8uaqXKXFA3UdQOZQZLvZ+0Ge73 5NBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/vvXfhmYUMNLtifIkMQ6u/IDa3Skg78C1DwS9wJwqMI=; b=Q36Ug5vPgFOPUermLjD7TRNxPs6S2HsnvLZYjPxHppVMFFP9cEl3utmgeUjrkTSTJB hHcH/x0j8qYUroIMIUT8YQCs+twAHfK9gQo1y4GmWv9tobMxWx/y2rR0e7l16t2NJkXl EkKBizSkXU3aHvGw5CdfQJgv9bgPS/6yxZSDh6oV/NVIZOeAG2hCXqWLwMUg/Pm27fWb xLNFk+mFTbWRxeGAVwQuJDsX2V6dEfl2ghwKTdHjPtHRcWXmAJWr5GoBj0d3nq175Zpk ymhrzhw0hNcWMk2hRoZAuPSJw6irEm4978vWObTC+VWi/J704wvUWYPjfE9WP9LqgzCJ vwNg== X-Gm-Message-State: AJcUukcZOAY/awUi47uOsDtf9fdno6XWtdFESlkai5gxaW1/dauDtliQ BHjN2yDtzf8ZaI++c/uhvF1YskWXHMNwSt/uZqGXEQ== X-Google-Smtp-Source: ALg8bN68CJ3FrJvzevP/WgB0Cc7Ff3RkSy30yqUCvAHvHDlFJjuiZ0d1xhxKkF7+ywn1I+CvN01AeA2Ea4IHNkyJGp0= X-Received: by 2002:a9d:ecd:: with SMTP id 71mr4819339otj.155.1547060255939; Wed, 09 Jan 2019 10:57:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Weaver Date: Wed, 9 Jan 2019 10:57:24 -0800 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000000623e057f0b09e0" Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 18:57:39 -0000 --00000000000000623e057f0b09e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to Dave's suggestions as well (both for repository and development of the README to include more IETF project info). Best, Andrew On Wed, Jan 9, 2019 at 9:45 AM Reto Kromer wrote: > Dave Rice wrote: > > >I=E2=80=99d prefer to have a https://github.com/cellar-wg > >organizational account to provide the appearance that the > >work is underway under the context of the IETF rather than > >the individuals or source communities that are hosting > >currently. > > +1 > > Best regards, Reto > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --00000000000000623e057f0b09e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to Dave's suggestions as well (both for reposi= tory and development of the README to include more IETF project info).
<= /div>

Best,
Andrew

On Wed, Jan 9, 2019 at 9:45 AM Reto Kro= mer <lists@reto.ch> wrote:
Dave Rice wrote:

>I=E2=80=99d prefer to have a https://github.com/cellar-wg
>organizational account to provide the appearance that the
>work is underway under the context of the IETF rather than
>the individuals or source communities that are hosting
>currently.

+1

Best regards, Reto

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--00000000000000623e057f0b09e0-- From nobody Wed Jan 9 13:05:49 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A225131066 for ; Wed, 9 Jan 2019 13:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2hfZXh3FOiQm for ; Wed, 9 Jan 2019 13:05:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26A7131091 for ; Wed, 9 Jan 2019 13:05:42 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id DF99B3808A for ; Wed, 9 Jan 2019 16:05:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 597F0CBE; Wed, 9 Jan 2019 16:05:39 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 57C7CCBC for ; Wed, 9 Jan 2019 16:05:39 -0500 (EST) From: Michael Richardson To: cellar@ietf.org In-Reply-To: References: <17722.1546984931@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] CELLAR-WG organization created on GITHUB X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 21:05:47 -0000 --=-=-= Content-Type: text/plain https://github.com/cellar-wg now exists. I've invited a few people whose github IDs I could find easily, but I'm sure that there are another 6-8 that should be invited. Please unicast github ID to me. Repos can be moved to the organization, or forked into the organization, please send me a list: I don't want to surprise anyone. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlw2YiMACgkQgItw+93Q 3WUoJwf9GwBj4lldtp0gT5FyU8QrQnY6fBWfOrXGp/6DgLS4viy4kodIlqroR71Z s+Q8fRbpiwlGdEk0gSbYdFkwO4HUq8G/4gE0kL/Waoxapsc4gpU8MqfiMGIt9+vZ As7acIihufNEgceINZM+yOqRzRGkNZxiA9VKnTgtnpWSrl2QwNs4gywAvbBn63lY rYl77fVr9mrFYKS1uw9gXieQpwPU6Ot5Zq+xaDhWTvLYzamPO2KAHB7h1BYV5uIq 3hibDMV6HgD5ZyJFDKCJTWFR9cc+bQBsM2FclDOj6G5K4bpwNKBCpwFGR7Ny8flw IBMOnXwENyCqJqicRAEyHr+cAvgwZw== =8LhO -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 9 14:28:43 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74012D4F2 for ; Wed, 9 Jan 2019 14:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yk3ZzN-L395e for ; Wed, 9 Jan 2019 14:28:40 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 E436A124D68 for ; Wed, 9 Jan 2019 14:28:39 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id k98so8205201otk.3 for ; Wed, 09 Jan 2019 14:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5U6DN9dAhpDUqt05nfTbeSpzIr2hAeiz7OJKrtjEr+w=; b=hSaQe8QHL1dRWQBB6WUtYgMwl6y42KqRltpKOryYOi/yArd36AyBaXmFoayfUOnKyK ig/BwqGj+kfGA5mDQn2nuw/wMmvwXRaZyPPkvnV/R8y7x6k4sPYXNLETBcjB2Nzuw46t xujv0cJJFLilYJAvmd1O0DfT+vzk0tt7CmnH9eby745cnEiU3OjpZgyi1xXkjjW2vW/V p3Fc0yx2E7f+mpVc8QcQP4mnBXNikG3rpkFoQFVTUvSS6Mi7/D/8HxnnbeNoI+UjB78W QFRAR2oHWzmwV/u7dz5uWQXpHzxgguqB++WvjyPGL19T07enu/VxwTON+zQ3hegVtSRN VA3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5U6DN9dAhpDUqt05nfTbeSpzIr2hAeiz7OJKrtjEr+w=; b=MJGb3QQIGYVh+cYegFe2J1TANkOLzIwXpkEMRkT5Ko8oh6HxpPvT/O9bnpRXCQseWE WCveaXsQFyVAZKIirCuSXYyFX9OVRYtJLYbK3t+FAPUm7GC4H+YMSJTRLzvNYhaaX4OA m7p5CTfVGIMVnO3Yqvkda9dCBIPYTDXYS/9nCd9RWVj03YvxZTfWWo+CRdcI8Q6gNQZx vcwuYEZ9v5er1Yg5U6f+WKPhDHdJ8yhYOk/Mh8g3QZTilLfdZTX4HvkYLL1dWAmEN1cb H42FHndo+R77lY6O85jphtua9UAyo/udiyVWlLKKq7EBlS5s+JmCo2c2cBM/IukHaEPZ CrJA== X-Gm-Message-State: AJcUukeSFZSXx2YZyyAC0JM9EPe6tRPf+tny1TKD32Qfn5ImYdVWUjm3 m9vVH6n/DrSJvgb8bxsPwcLYyptdgQ5+J951UobexQ== X-Google-Smtp-Source: ALg8bN7S+RFSnu4xWT2DIy3XNYL8O6BUKDyvHdHXj8qiVINxN85ULEHDiCidMZJfUc6kz8ZYnzNazCun1SnEZrjE2P8= X-Received: by 2002:a9d:2aea:: with SMTP id e97mr5423311otb.206.1547072918885; Wed, 09 Jan 2019 14:28:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Weaver Date: Wed, 9 Jan 2019 14:28:27 -0800 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000c5a05e057f0dfbc2" Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 22:28:42 -0000 --000000000000c5a05e057f0dfbc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Quick follow-up, the repository containing the work to date on converting FLAC to Markdown has been transferred to the new cellar-wg repository. Thanks for creating that Michael! Best, Andrew On Wed, Jan 9, 2019 at 10:57 AM Andrew Weaver wrote= : > +1 to Dave's suggestions as well (both for repository and development of > the README to include more IETF project info). > > Best, > Andrew > > On Wed, Jan 9, 2019 at 9:45 AM Reto Kromer wrote: > >> Dave Rice wrote: >> >> >I=E2=80=99d prefer to have a https://github.com/cellar-wg >> >organizational account to provide the appearance that the >> >work is underway under the context of the IETF rather than >> >the individuals or source communities that are hosting >> >currently. >> >> +1 >> >> Best regards, Reto >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > --000000000000c5a05e057f0dfbc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Quick follow-up, the repository containing the work t= o date on converting FLAC to Markdown has been transferred to the new cella= r-wg repository. Thanks for creating that Michael!

Best,
Andrew

On Wed, Jan 9, 2019 at 10:57 AM Andrew Weaver <theandrewjw@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
+1 t= o Dave's suggestions as well (both for repository and development of th= e README to include more IETF project info).

B= est,
Andrew

On Wed, Jan 9, 2019 at 9:45 AM Reto Kromer <lists@reto.ch> wrote:
Dave Rice wrote:

>I=E2=80=99d prefer to have a https://github.com/cellar-wg
>organizational account to provide the appearance that the
>work is underway under the context of the IETF rather than
>the individuals or source communities that are hosting
>currently.

+1

Best regards, Reto

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--000000000000c5a05e057f0dfbc2-- From nobody Thu Jan 10 03:13:04 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CA31311AA for ; Thu, 10 Jan 2019 03:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nGPxVPg3lCkq for ; Thu, 10 Jan 2019 03:12:52 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 625BB131162 for ; Thu, 10 Jan 2019 03:12:51 -0800 (PST) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x0ABCmxl001006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 10 Jan 2019 12:12:48 +0100 Received: from Castor.local ([IPv6:2a02:aa13:4680:f280:4d92:d0b:c944:1297]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x0ABClGZ037096 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 10 Jan 2019 12:12:48 +0100 Date: Thu, 10 Jan 2019 12:12:48 +0100 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 11:12:55 -0000 Andrew Weaver wrote: >Quick follow-up, the repository containing the work to date on >converting FLAC to Markdown has been transferred to the new >cellar-wg repository. Thank you very much indeed, Andrew! Reto From nobody Thu Jan 10 05:49:09 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0707C130E11; Thu, 10 Jan 2019 05:49:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154712814099.30772.583061670891807687@ietfa.amsl.com> Date: Thu, 10 Jan 2019 05:49:01 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-codec-01.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:49:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Matroska Codec Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-codec-01.txt Pages : 45 Date : 2019-01-10 Abstract: This document defines the Matroska codec mappings, including the codec ID, layout of data in a "Block Element" and in an optional "CodecPrivate Element". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-codec-01 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-codec-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-codec-01 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 10 05:49:20 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 417631311AB; Thu, 10 Jan 2019 05:49:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154712814422.30744.16502990945434180645@ietfa.amsl.com> Date: Thu, 10 Jan 2019 05:49:04 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-tags-01.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:49:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Matroska Tags Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-tags-01.txt Pages : 20 Date : 2019-01-10 Abstract: This document defines the Matroska tags, namely the tag names and their respective semantic meaning. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-tags-01 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-tags-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-tags-01 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 10 05:49:45 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 984D91311AE; Thu, 10 Jan 2019 05:49:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154712817958.30856.4276697375134284135@ietfa.amsl.com> Date: Thu, 10 Jan 2019 05:49:39 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-matroska-02.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 13:49:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Matroska Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-matroska-02.txt Pages : 167 Date : 2019-01-10 Abstract: This document defines the Matroska audiovisual container, including definitions of its structural elements, as well as its terminology, vocabulary, and application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-matroska-02 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-matroska-02 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 10 06:01:52 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B837F128B14 for ; Thu, 10 Jan 2019 06:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 fqmMeDSecwyC for ; Thu, 10 Jan 2019 06:01:44 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 41C7A130ED0 for ; Thu, 10 Jan 2019 06:01:38 -0800 (PST) Received: from [146.96.19.240] (port=33005 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ghatm-0032C0-00; Thu, 10 Jan 2019 09:01:37 -0500 From: Dave Rice Message-Id: <518B5EF7-4BC7-4229-9F6E-167B7701C694@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_47CF53C9-1533-4AE4-B194-FA4247A045CA" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 09:01:28 -0500 In-Reply-To: Cc: cellar@ietf.org To: Michael Richardson References: <17722.1546984931@localhost> X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 14:01:51 -0000 --Apple-Mail=_47CF53C9-1533-4AE4-B194-FA4247A045CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, Tim, > On Jan 9, 2019, at 11:49 AM, Dave Rice wrote: >=20 >> BTW: I want to point a few internet drafts will expire this week, and >> it would be good to post refreshes this wek. >=20 > I see this is happening with the Codec Mappings and Metadata Tags = documents for Matroska. I=E2=80=99ll post updates before they expire. = I=E2=80=99ll check on the FLAC output as well since that document had = already expired. New Matroska documents are posted at: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ The FLAC document is expired at = https://datatracker.ietf.org/doc/draft-xiph-cellar-flac/. I tried to post an update, but get an error since it was never approved = and I don=E2=80=99t have access to the full submission url. I think this = happened since within the document no one in the working group is listed = as an author and the two listed authors, J. Coalson and Xiph.Org = Foundation, aren=E2=80=99t listed within the document by email. When I try to access the submission of draft-xiph-cellar-flac-01 I get = this error but no contact. > You are not allowed to modify or cancel this submission. You can only = modify or cancel this submission from the same URL you were redirected = to after the submission. > If you are the submitter check your browser history to find this URL. = You can share it with any person you need. > If you are one of the authors you can request the URL from which you = can modify or cancel this submission by clicking the next button. An = email will then be sent to the authors and submitter (if submitter email = was entered): . Thus far, Andrew Weaver, has contributed the most of the document beyond = what J. Coalson and Xiph have done. Perhaps Andrew should add himself as = a co-author so that we can submit this more easily in the future. Tim, See the paragraphs above regarding xiph, is there an xiph author email = that we can use in this document. Also one way around the error with draft-xiph-cellar-flac-01 may be that = I submit the current state of the document as draft-ietf-cellar-flac-00 = if it=E2=80=99s fair to upgrade this to a working group document. Dave= --Apple-Mail=_47CF53C9-1533-4AE4-B194-FA4247A045CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michael, Tim,

On Jan 9, 2019, at 11:49 AM, Dave Rice <dave@dericed.com> = wrote:

BTW: I want to = point a few internet drafts will expire this week, and
    it would be good to post refreshes = this wek.

I see this is happening with the Codec Mappings and = Metadata Tags documents for Matroska. I=E2=80=99ll post updates before = they expire. I=E2=80=99ll check on the FLAC output as well since that = document had already expired.

New Matroska documents are posted at:
https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/
https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/

The FLAC document is expired = at https://datatracker.ietf.org/doc/draft-xiph-cellar-flac/.
I tried to post an update, but get an error since it was never = approved and I don=E2=80=99t have access to the full submission url. I = think this happened since within the document no one in the working = group is listed as an author and the two listed authors, J. Coalson = and Xiph.Org Foundation, = aren=E2=80=99t listed within the document by email.

When I try to access the submission of = draft-xiph-cellar-flac-01 I get this error but no = contact.
You = are not allowed to modify or cancel this submission. You can only modify = or cancel this submission from the same URL you were redirected to = after the submission.
If you are the submitter check your = browser history to find this URL. You can share it with any person you = need.
If you are one of the authors you can request the = URL from which you can modify or cancel this submission by = clicking the next button. An email will then be sent to the authors = and submitter (if submitter email was entered): = .

Thus far, Andrew = Weaver, has contributed the most of the document beyond what J. Coalson = and Xiph have done. Perhaps Andrew should add himself as a co-author so = that we can submit this more easily in the future.

Tim,
See the paragraphs above regarding = xiph, is there an xiph author email that we can use in this = document.

Also one way around the = error with draft-xiph-cellar-flac-01 may be that I submit the = current state of the document as draft-ietf-cellar-flac-00 if = it=E2=80=99s fair to upgrade this to a working group document.
Dave
= --Apple-Mail=_47CF53C9-1533-4AE4-B194-FA4247A045CA-- From nobody Thu Jan 10 08:56:05 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59098130E90 for ; Thu, 10 Jan 2019 08:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1MGwyL2l_d93 for ; Thu, 10 Jan 2019 08:56:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EB8126C7E for ; Thu, 10 Jan 2019 08:55:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E5B2838261 for ; Thu, 10 Jan 2019 11:55:26 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 97BBBDC1; Thu, 10 Jan 2019 11:55:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9667FDBF for ; Thu, 10 Jan 2019 11:55:54 -0500 (EST) From: Michael Richardson To: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] [FFmpeg/FFV1] update to xml2rfc v3 (#135) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:56:04 -0000 --=-=-= Content-Type: text/plain Michael Niedermayer wrote: mcr> Yes, we moved to v3, which is not perhaps widely available yet. > yeah, and we also wrote in the README that xml2rfc 2.5.1 is > sufficient. You know we write that in the README in the VERY same pull > req that adds the requirement of v3. Maybe iam missing something and > surely my statement is a bit blunt but that combination does not look > ok to me > xml2rfc: error: no such option: --v3 Makefile:12: recipe > for target Hi, I wonder if you are getting the right version of xml2rfc? Could you have more than one installed? Dave, any comments? > I think some possibly dumb question, is there a requirement to depend > on v3 fo IETF texts ? I mean can we just stay compatible with v2 ? or > is that adding workload to us. I do not want to add some extra workload > on every future change, that would be bad too. We made the decision to move to v3 because: a) we have math in the document which v3 does a really nice job on. b) because its useful for the IETF to have someone clueful trying v3. That was on the list about a month ago. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlw3eRoACgkQgItw+93Q 3WWChwgApGKB0MMLG2wYh97c4UzUsR/VDkWIFdxRJyuCeDjgN+m3oRK0q6+H9v8t bZRKIkkUb3E0MVRULp4NFeTTmbCSviFmjoWdaTHgc3cqaoNcCPdI4izSDTJkat8p yxwXTRLX6MadBSTYfnBWD9aHq4y3XOVGXbNGwiUcdKIa492s4f6zr1H7o1twKLdZ VvCF/FM8V/l0EOINM70HX3X70RBuHsBNgsbe4MOmVIIvqEc66DCd3PwURWx/o0kR 1nQBZ8soZx/LYG/iOM4i09sJKXg8NhuXdE1CPVfT/ZttZE39vEjoyFdyr63BRWz/ fslVSAQ8iTwBic8ai1WzGRwhmKBTEQ== =H4K1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 10 09:01:49 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11CA130E9A for ; Thu, 10 Jan 2019 09:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 f_6ECY5cH79G for ; Thu, 10 Jan 2019 09:01:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E28D127B4C for ; Thu, 10 Jan 2019 09:01:44 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B2CC38261; Thu, 10 Jan 2019 12:01:15 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CC3B1DCE; Thu, 10 Jan 2019 12:01:42 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CAA98DC4; Thu, 10 Jan 2019 12:01:42 -0500 (EST) From: Michael Richardson To: Dave Rice cc: cellar@ietf.org In-Reply-To: <518B5EF7-4BC7-4229-9F6E-167B7701C694@dericed.com> References: <17722.1546984931@localhost> <518B5EF7-4BC7-4229-9F6E-167B7701C694@dericed.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 17:01:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Rice wrote: > The FLAC document is expired at > https://datatracker.ietf.org/doc/draft-xiph-cellar-flac/. I tried to > post an update, but get an error since it was never approved and I > don=E2=80=99t have access to the full submission url. I think this ha= ppened > since within the document no one in the working group is listed as an > author and the two listed authors, J. Coalson and Xiph.Org Foundation, > aren=E2=80=99t listed within the document by email. So, basically the new authors and old authors have none in common, so it gets rejected and nobody who can respond to the approval email. Can you forward the email you got directly? Please just upload it with a new name, i.e: draft-rice-cellar-flac and I'll mark it as replacing xiph-cellar-flac. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlw3enYACgkQgItw+93Q 3WWXbAf+PlRkjzGyWnRVe3erQ4+iSuvQYq1bsXloTWHVpFRoYAtBzGnDb1kwMC3g gf5ogstnWTS01gBIQ+ULFdDpHKwNUV0d8nWkJzoZBzpa10G0u4zaBo+sChAf9/Zl wySW1r8CLYZixVEcpZHQca315Kv7zKqQlx6qED+AQ9GsBQG0dMTSuFGRr8w8n9rt fYEDIZSjNQkuUJ9nSGmFL2migCTaYP6pRbSfRVLxFnst2WlBWGH74Sr7hws6g/jW 5ZkiPE6bCgfG1Hdo9Oo4UWFwZPq4NOde4a/OTRuEmgSmc6fqoNhv0A3ApfqGWgzo fUllEC8Tv0X1m6vzAgHUc1MZ48z30Q== =KEAx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 10 09:07:19 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA5130ED1 for ; Thu, 10 Jan 2019 09:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 jiVyupzv-GrG for ; Thu, 10 Jan 2019 09:07:17 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 4AC9D130ECA for ; Thu, 10 Jan 2019 09:07:17 -0800 (PST) Received: from [146.96.19.240] (port=16619 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ghdnW-000rtY-Iz; Thu, 10 Jan 2019 12:07:16 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Dave Rice In-Reply-To: <16052.1547139354@localhost> Date: Thu, 10 Jan 2019 12:07:13 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E6A3889-D51D-4A75-BAC2-307EDAA22A9E@dericed.com> References: <16052.1547139354@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [FFmpeg/FFV1] update to xml2rfc v3 (#135) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 17:07:19 -0000 > On Jan 10, 2019, at 11:55 AM, Michael Richardson = wrote: >=20 >=20 > Michael Niedermayer wrote: > mcr> Yes, we moved to v3, which is not perhaps widely available = yet. >=20 >> yeah, and we also wrote in the README that xml2rfc 2.5.1 is >> sufficient. You know we write that in the README in the VERY same = pull >> req that adds the requirement of v3. Maybe iam missing something and >> surely my statement is a bit blunt but that combination does not look >> ok to me >=20 >> xml2rfc: error: no such option: --v3 Makefile:12: recipe >> for target >=20 > Hi, I wonder if you are getting the right version of xml2rfc? > Could you have more than one installed? > Dave, any comments? The build works for me with the mmark and xml2rfc noted in the pull = request. On my system I get. With the older xml2rfc and mmark, the make = process would fail. $mmark -version 2.0.7 $xml2rfc -V xml2rfc 2.12.3 >> I think some possibly dumb question, is there a requirement to depend >> on v3 fo IETF texts ? I mean can we just stay compatible with v2 ? = or >> is that adding workload to us. I do not want to add some extra = workload >> on every future change, that would be bad too. >=20 > We made the decision to move to v3 because: > a) we have math in the document which v3 does a really nice job on. > b) because its useful for the IETF to have someone clueful trying v3. >=20 > That was on the list about a month ago. I reviewed the comments in https://github.com/FFmpeg/FFV1/pull/135 and = here=E2=80=99s a summary of my considerations. The currently head of the repo requires mmark version 1.3.4 and xml2rfc = 2.5.1, while the PR requires mmark version 2.0.7, xml2rfc 2.12.3. IMHO = using more recent releases is preferred but I understand the argument = that recent releases may not have been well disseminated through all = package repositories yet. The makefile process doesn=E2=80=99t fail gracefully. There is no = versioning check of the dependencies so if the Makefile of the PR is run = with the older versions of mmark or xml2rfc, it will fail. I think this = is an issue but independent to the PR since the issue is the same with = or without the PR. The PR adds dependencies with xmlstarlet and pdfcrop. This is a = disadvantage for the PR as the make process is more complex; however the = advantage is that we can use v3 and have better representations of the = equations rather than the ascii art version. Also the RFC outputs that = support equations can supersede the custom PDF output that we had been = using so a lot of the lines we were managing that were output specific = can be removed so that the source document is simplified. Also the makefile could certainly be improved and I=E2=80=99d wish I = could contribute better to it; however the Makefiles in the cellar = repositories are my first efforts at writing Makefiles and I=E2=80=99m = not sure how to efficiently add version checks and tests to the = Makefile. At any rate, with or without the PR the issues of whether the = Makefile fails gracefully are the same. Best Regards, Dave Rice From nobody Thu Jan 10 09:10:12 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65FE130EE1 for ; Thu, 10 Jan 2019 09:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 cH4hcapvrMgq for ; Thu, 10 Jan 2019 09:10:10 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 075E4130EDF for ; Thu, 10 Jan 2019 09:10:10 -0800 (PST) Received: from [146.96.19.240] (port=3080 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ghdqJ-000tg0-Kz; Thu, 10 Jan 2019 12:10:09 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Dave Rice In-Reply-To: <17431.1547139702@localhost> Date: Thu, 10 Jan 2019 12:10:06 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <17722.1546984931@localhost> <518B5EF7-4BC7-4229-9F6E-167B7701C694@dericed.com> <17431.1547139702@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 17:10:12 -0000 Hi Michael, > On Jan 10, 2019, at 12:01 PM, Michael Richardson = wrote: >=20 > Dave Rice wrote: >> The FLAC document is expired at >> https://datatracker.ietf.org/doc/draft-xiph-cellar-flac/. I tried to >> post an update, but get an error since it was never approved and I >> don=E2=80=99t have access to the full submission url. I think this = happened >> since within the document no one in the working group is listed as an >> author and the two listed authors, J. Coalson and Xiph.Org = Foundation, >> aren=E2=80=99t listed within the document by email. >=20 > So, basically the new authors and old authors have none in common, so > it gets rejected and nobody who can respond to the approval email. > Can you forward the email you got directly? I never received an email since I=E2=80=99m not an author, no author = emails were listed in the document. I was only the submitted and my = contributions to the document were more about formatting than authoring. > Please just upload it with a new name, i.e: > draft-rice-cellar-flac >=20 > and I'll mark it as replacing xiph-cellar-flac. Should I restart the versioning to 00 in that case? Dave Rice= From nobody Thu Jan 10 09:20:16 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7B130EFF for ; Thu, 10 Jan 2019 09:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Kg5kUO2Jv6QK for ; Thu, 10 Jan 2019 09:20:12 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B966B130F07 for ; Thu, 10 Jan 2019 09:20:12 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 23ADC38261; Thu, 10 Jan 2019 12:19:44 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CCC64DC4; Thu, 10 Jan 2019 12:20:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CB100D4D; Thu, 10 Jan 2019 12:20:11 -0500 (EST) From: Michael Richardson To: Dave Rice cc: cellar@ietf.org In-Reply-To: References: <17722.1546984931@localhost> <518B5EF7-4BC7-4229-9F6E-167B7701C694@dericed.com> <17431.1547139702@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 17:20:15 -0000 Dave Rice wrote: >> Dave Rice wrote: >>> The FLAC document is expired at >>> https://datatracker.ietf.org/doc/draft-xiph-cellar-flac/. I tried = to >>> post an update, but get an error since it was never approved and I >>> don=E2=80=99t have access to the full submission url. I think this = happened >>> since within the document no one in the working group is listed as = an >>> author and the two listed authors, J. Coalson and Xiph.Org >>> Foundation, aren=E2=80=99t listed within the document by email. >> >> So, basically the new authors and old authors have none in common, so >> it gets rejected and nobody who can respond to the approval email. >> Can you forward the email you got directly? > I never received an email since I=E2=80=99m not an author, no author = emails > were listed in the document. I was only the submitted and my > contributions to the document were more about formatting than > authoring. >> Please just upload it with a new name, i.e: draft-rice-cellar-flac >> >> and I'll mark it as replacing xiph-cellar-flac. > Should I restart the versioning to 00 in that case? Yes. From nobody Thu Jan 10 09:28:24 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A410F130EE0 for ; Thu, 10 Jan 2019 09:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 oFR3BFP-N7qV for ; Thu, 10 Jan 2019 09:28:19 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5D5130F0A for ; Thu, 10 Jan 2019 09:28:18 -0800 (PST) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id CDCB640011 for ; Thu, 10 Jan 2019 17:28:16 +0000 (UTC) Date: Thu, 10 Jan 2019 18:28:15 +0100 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20190110172815.GB2867@michaelspb> References: <16052.1547139354@localhost> <6E6A3889-D51D-4A75-BAC2-307EDAA22A9E@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aVD9QWMuhilNxW9f" Content-Disposition: inline In-Reply-To: <6E6A3889-D51D-4A75-BAC2-307EDAA22A9E@dericed.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Cellar] [FFmpeg/FFV1] update to xml2rfc v3 (#135) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 17:28:23 -0000 --aVD9QWMuhilNxW9f Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Thu, Jan 10, 2019 at 12:07:13PM -0500, Dave Rice wrote: >=20 >=20 > > On Jan 10, 2019, at 11:55 AM, Michael Richardson wrote: > >=20 > >=20 > > Michael Niedermayer wrote: > > mcr> Yes, we moved to v3, which is not perhaps widely available = yet. > >=20 > >> yeah, and we also wrote in the README that xml2rfc 2.5.1 is > >> sufficient. You know we write that in the README in the VERY same pull > >> req that adds the requirement of v3. Maybe iam missing something and > >> surely my statement is a bit blunt but that combination does not look > >> ok to me > >=20 > >> xml2rfc: error: no such option: --v3 Makefile:12: recipe > >> for target > >=20 > > Hi, I wonder if you are getting the right version of xml2rfc? > > Could you have more than one installed? > > Dave, any comments? >=20 > The build works for me with the mmark and xml2rfc noted in the pull reque= st. On my system I get. With the older xml2rfc and mmark, the make process = would fail. >=20 > $mmark -version > 2.0.7 >=20 > $xml2rfc -V > xml2rfc 2.12.3 ok, lets try again (iam a bit pretending to be a average contributor which is who this should work for IMO) mmark was 1.3+ on the new box i tried it on, ive upgraded it to the latest = available on any ubuntu next mmark --version 1.3.6 This is the latest version on any ubuntu release: https://packages.ubuntu.com/search?keywords=3Dmmark&searchon=3Dnames Its also the latest debian packages https://packages.debian.org/search?keywords=3Dmmark so this is likely what a lot of people will try it with but that fails still being too old now how to semi cleanly install latest xml2rfc and mmark 2.0.7 for the next= try: virtualenv ffv1build --python=3Dpython3 =2E ffv1build/bin/activate export PATH=3D~/ffv1build/bin:$PATH pip install xml2rfc cd ~/ffv1build/bin wget https://github.com/mmarkdown/mmark/releases/download/v2.0.7/mmark_2.0.= 7_linux_amd64.tgz tar -xzvf mmark_2.0.7_linux_amd64.tgz sha256sum mmark 87b2dacfe9b68ac30c56affe031925424d2215a91016b8e55266f72c80b9fadd mmark and drumroll ... still fails and its not obvious what tool fails RFC rendering has been tested with mmark version 2.0.7, xml2rfc 2.12.3, xml= starlet 1.6.1, pdfcrop v1.38, and pdf2svg 0.2.3, please ensure these are in= stalled and recent enough. bash makesvg PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `context.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `quantizationtablesets.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rgb1.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rgb2.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `samplediff.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues1.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues2.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues3.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues4.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues5.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues6.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `rangebinaryvalues7.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `statetransitiontable1.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `statetransitiontable2.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `initialstatedelta1.svg_cropped.pdf'. PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek. =3D=3D> 1 page written on `initialstatedelta2.svg_cropped.pdf'. cat rfc_frontmatter.md "ffv1.md" rfc_backmatter.md | grep -v "^RFC:" | grep= -v "^SVGC" | grep -v "{V4}" | sed "s|^RFC:||g;s|{V3}||g;s|SVGI:||g" > merg= ed_rfchtml.md mmark merged_rfchtml.md | xmlstarlet edit --delete '//postal|//uri' | sed '= s|alt=3D"alt"|type=3D"svg"|g' > draft-ietf-cellar-ffv1-06.xml xml2rfc --html --v3 draft-ietf-cellar-ffv1-06.xml -o "draft-ietf-cellar-ffv= 1-06.html" Parsing file draft-ietf-cellar-ffv1-06.xml draft-ietf-cellar-ffv1-06.xml(242): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[4]/t[2]/artwork draft-ietf-cellar-ffv1-06.xml(250): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[5]/t[2]/artwork draft-ietf-cellar-ffv1-06.xml(302): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[7]/section[2]/t[4]/artwork draft-ietf-cellar-ffv1-06.xml(306): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[7]/section[2]/t[6]/artwork draft-ietf-cellar-ffv1-06.xml(327): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/t[2]/artwork draft-ietf-cellar-ffv1-06.xml(336): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[2]/artwo= rk draft-ietf-cellar-ffv1-06.xml(339): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[3]/artwo= rk draft-ietf-cellar-ffv1-06.xml(342): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[4]/artwo= rk draft-ietf-cellar-ffv1-06.xml(345): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[5]/artwo= rk draft-ietf-cellar-ffv1-06.xml(348): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[6]/artwo= rk draft-ietf-cellar-ffv1-06.xml(351): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[7]/artwo= rk draft-ietf-cellar-ffv1-06.xml(354): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[1]/t[8]/artwo= rk draft-ietf-cellar-ffv1-06.xml(410): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[4]/t[1]/artwo= rk draft-ietf-cellar-ffv1-06.xml(413): Error: Did not expect element artwork t= here, at /rfc/middle/section[3]/section[8]/section[1]/section[4]/t[2]/artwo= rk draft-ietf-cellar-ffv1-06.xml(988): Error: Did not expect element artwork t= here, at /rfc/middle/section[4]/section[1]/section[15]/t[2]/artwork draft-ietf-cellar-ffv1-06.xml(991): Error: Did not expect element artwork t= here, at /rfc/middle/section[4]/section[1]/section[15]/t[3]/artwork draft-ietf-cellar-ffv1-06.xml(3): Error: Invalid document before running pr= eptool. Cannot continue, quitting now Makefile:12: recipe for target 'draft-ietf-cellar-ffv1-06.html' failed make: *** [draft-ietf-cellar-ffv1-06.html] Error 1 =46rom this failure how can one know which tool needs to be upgraded ? assuming it is a tool version issue >=20 > >> I think some possibly dumb question, is there a requirement to depend > >> on v3 fo IETF texts ? I mean can we just stay compatible with v2 ? or > >> is that adding workload to us. I do not want to add some extra workload > >> on every future change, that would be bad too. > >=20 > > We made the decision to move to v3 because: > > a) we have math in the document which v3 does a really nice job on. > > b) because its useful for the IETF to have someone clueful trying v3. > >=20 > > That was on the list about a month ago. >=20 >=20 > I reviewed the comments in https://github.com/FFmpeg/FFV1/pull/135 and he= re=E2=80=99s a summary of my considerations. >=20 > The currently head of the repo requires mmark version 1.3.4 and xml2rfc 2= =2E5.1, while the PR requires mmark version 2.0.7, xml2rfc 2.12.3. IMHO usi= ng more recent releases is preferred but I understand the argument that rec= ent releases may not have been well disseminated through all package reposi= tories yet. >=20 > The makefile process doesn=E2=80=99t fail gracefully. There is no version= ing check of the dependencies so if the Makefile of the PR is run with the = older versions of mmark or xml2rfc, it will fail. I think this is an issue = but independent to the PR since the issue is the same with or without the P= R. Because existing distros are more likely to have recent enough versions prior to the pr the chance of hitting this bug should be higher after the pr so the PR makes this worse btw thanks for your efforts to push this forward [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. --aVD9QWMuhilNxW9f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlw3gK8ACgkQYR7HhwQLD6skBgCffEx6yeyECjqYB03HsnGUYCFo x5AAn3UZseMkAgktH4eFIMMzwHKIf6wN =s8nN -----END PGP SIGNATURE----- --aVD9QWMuhilNxW9f-- From nobody Thu Jan 10 13:09:30 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F017130F70 for ; Thu, 10 Jan 2019 13:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NrlOoMtf3l8F for ; Thu, 10 Jan 2019 13:09:27 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 32BBB12896A for ; Thu, 10 Jan 2019 13:09:27 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id v6so10483393oif.2 for ; Thu, 10 Jan 2019 13:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=TemHvOeR2Yb36WSi0WIB+7Oc11idu7oIuAam2RzQdnk=; b=E41+Dy3TXAyP5oKYDOOyczl05UuVCsvr+y3WlwGxLLXJ5e/TTwImaNbJTcyzoQ6Zee CZfj1vg3rzuBfk1HnExtrX4NLwnpK89ym0Gh6OBeBpEamgZ+/+mTd9rmDkWaANGy+1f3 t63/RV6WXviedjT1m6iu/FZ+rNEX4W356CiTFnYnQs7yYcJlhioF2dQxMXMP69K4tVVs GDLJIgYUhkKnCJgpTvZ7vSmMzZn2oZl2FWoWOZQIp6cPD/VsfEhT/EkWsKg2eZRFlDWi unaxicfgFb7D5ijYWZhCzuLzRG/FXqPaGuLJV8wBeflezKBE2uiXdNBVkffOx6eGcko+ Rd9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TemHvOeR2Yb36WSi0WIB+7Oc11idu7oIuAam2RzQdnk=; b=VuVWHD4NNeZi4jsBf5cAZB+F380KQJB6njIai5zsv4dvmMo1a6Jjd0cjGe1atIe15f 38rQRF+EcHWsFAgTtwnqxu+xT2zzTFKbqUwJDDJclmlZQFMrJYPAcJWzJjORi9EtyROV XFxCHIu65m40uWAIS7SII4W1w33HGlITWEdLdj5YIfn4L4Fdfs1I8XDzVMZKXo/Fa7aD h28KRFYytDo8Fl22qQ6GKHn43EjWz57pKKdnN9s9+NSNfEGRWIRMQKrOPAgB9psgtA6g HZKZaU1elNI0spoKtAZmAYW/R6Y1AWI5hOxxIL4kyPMkNGXGmu1KzgqSQBQM67fayh5o AapQ== X-Gm-Message-State: AJcUukcT1TfvFNIz/UbmvwIND4q0YgRtqZKkSGriLURfdAcCoexH1lOI dj0ezMhWnWAHFt2lZc94qnQGAcYlJd4daLitFqu59QZK X-Google-Smtp-Source: ALg8bN4atCccDYcc0VvlxLU896tRZ2ywH6yAa80iM1nt5W487jS+pqtEIGySYhn52vVi2QJuCCCLZXtPJnqwpt8Ly7Y= X-Received: by 2002:aca:b184:: with SMTP id a126mr7766864oif.187.1547154566258; Thu, 10 Jan 2019 13:09:26 -0800 (PST) MIME-Version: 1.0 References: <17722.1546984931@localhost> <518B5EF7-4BC7-4229-9F6E-167B7701C694@dericed.com> <17431.1547139702@localhost> <21654.1547140811@localhost> In-Reply-To: <21654.1547140811@localhost> From: Andrew Weaver Date: Thu, 10 Jan 2019 13:09:14 -0800 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000055a542057f20fe94" Archived-At: Subject: Re: [Cellar] FLAC Repository X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 21:09:29 -0000 --00000000000055a542057f20fe94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, New FLAC documents have been posted at: https://datatracker.ietf.org/doc/draft-weaver-cellar-flac/ Best, Andrew On Thu, Jan 10, 2019 at 9:20 AM Michael Richardson wrote= : > > Dave Rice wrote: > >> Dave Rice wrote: > >>> The FLAC document is expired at > >>> https://datatracker.ietf.org/doc/draft-xiph-cellar-flac/. I > tried to > >>> post an update, but get an error since it was never approved and = I > >>> don=E2=80=99t have access to the full submission url. I think thi= s happened > >>> since within the document no one in the working group is listed a= s > an > >>> author and the two listed authors, J. Coalson and Xiph.Org > >>> Foundation, aren=E2=80=99t listed within the document by email. > >> > >> So, basically the new authors and old authors have none in common, > so > >> it gets rejected and nobody who can respond to the approval email. > >> Can you forward the email you got directly? > > > I never received an email since I=E2=80=99m not an author, no autho= r emails > > were listed in the document. I was only the submitted and my > > contributions to the document were more about formatting than > > authoring. > > >> Please just upload it with a new name, i.e: draft-rice-cellar-flac > >> > >> and I'll mark it as replacing xiph-cellar-flac. > > > Should I restart the versioning to 00 in that case? > > Yes. > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --00000000000055a542057f20fe94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

New= FLAC documents have been posted at: https://datatracker.ietf.org/doc/draft-wea= ver-cellar-flac/

Best,
Andrew

On Thu, Jan = 10, 2019 at 9:20 AM Michael Richardson <mcr@sandelman.ca> wrote:

Dave Rice <dave@de= riced.com> wrote:
=C2=A0 =C2=A0 >> Dave Rice <dave@dericed.com> wrote:
=C2=A0 =C2=A0 >>> The FLAC document is expired at
=C2=A0 =C2=A0 >>> https://datatrack= er.ietf.org/doc/draft-xiph-cellar-flac/.=C2=A0 I tried to
=C2=A0 =C2=A0 >>> post an update, but get an error since it was ne= ver approved and I
=C2=A0 =C2=A0 >>> don=E2=80=99t have access to the full submission= url. I think this happened
=C2=A0 =C2=A0 >>> since within the document no one in the working = group is listed as an
=C2=A0 =C2=A0 >>> author and the two listed authors, J. Coalson an= d Xiph.Org
=C2=A0 =C2=A0 >>> Foundation, aren=E2=80=99t listed within the doc= ument by email.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> So, basically the new authors and old authors have n= one in common, so
=C2=A0 =C2=A0 >> it gets rejected and nobody who can respond to the a= pproval email.
=C2=A0 =C2=A0 >> Can you forward the email you got directly?

=C2=A0 =C2=A0 > I never received an email since I=E2=80=99m not an autho= r, no author emails
=C2=A0 =C2=A0 > were listed in the document. I was only the submitted an= d my
=C2=A0 =C2=A0 > contributions to the document were more about formatting= than
=C2=A0 =C2=A0 > authoring.

=C2=A0 =C2=A0 >> Please just upload it with a new name, i.e: draft-ri= ce-cellar-flac
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> and I'll mark it as replacing xiph-cellar-flac.<= br>
=C2=A0 =C2=A0 > Should I restart the versioning to 00 in that case?

Yes.


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--00000000000055a542057f20fe94-- From nobody Thu Jan 10 14:38:00 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3261312AB; Thu, 10 Jan 2019 14:37:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154715987830.30792.6050040281144884586.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2019 14:37:58 -0800 Archived-At: Subject: [Cellar] The CELLAR WG has placed draft-weaver-cellar-flac in state "Candidate for WG Adoption" X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 22:37:58 -0000 The CELLAR WG has placed draft-weaver-cellar-flac in state Candidate for WG Adoption (entered by Michael Richardson) The document is available at https://datatracker.ietf.org/doc/draft-weaver-cellar-flac/ From nobody Mon Jan 14 15:43:09 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A92A13144D; Mon, 14 Jan 2019 15:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 BQv0siPJHXHV; Mon, 14 Jan 2019 15:43:04 -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 9B82A13144C; Mon, 14 Jan 2019 15:43:04 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0ENh25x061871 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 17:43:03 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547509384; bh=s7fFQoFqvF2+wjH1pZnA3t8ZH4cHJICzcw57LNJiQro=; h=From:Subject:Date:References:To:In-Reply-To; b=P18ye4JYOg5v2jk4p7rzPQoISqtGecVwVN5rTWHcYHbgtFR7cEh5d/M3170oTBtA9 f1vSifEpU+PkXwbPAKVfcjT8/MkUYBkvLvLU3PwrSkhsdWUcDB6tTc1eEkRTcBs65b i3VUZLh9Fi69S64DgtdZJhbaLE45WvBSnNwIdi1U= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_49BA1CAC-4B8A-4DB7-AACE-490E5590B610"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 17:43:02 -0600 References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> To: draft-ietf-cellar-ebml.all@ietf.org, cellar@ietf.org In-Reply-To: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> Message-Id: <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 23:43:07 -0000 --Apple-Mail=_49BA1CAC-4B8A-4DB7-AACE-490E5590B610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Any thoughts on my AD evaluation review? I know there=E2=80=99s a lot of comments. Please don=E2=80=99t take that = as critical; it=E2=80=99s not at all unusual for the Area Director = review to generate a lot of comments :-) Thanks! Ben. > On Jan 7, 2019, at 3:14 PM, Ben Campbell wrote: >=20 >=20 > Hi, >=20 > This is my AD Evaluation of draft-ietf-cellar-ebml-08. >=20 > Thanks for this work. It's generally on the right track, but I have a = number of comments that I would like to discuss prior progressing. >=20 > Thanks! >=20 > Ben. >=20 > *** Substantive Comments *** >=20 > - The Shepherd Report says "There are minor nits to be resolved = (adding one RFC 2119 keyword and some schema attributes which = are mentioned but not defined." >=20 > Do that comment still apply? To be clear, those are more than nits. = Adding a 2119 keyword is substantive change that needs to be agreed to = but the working group. Undefined attributes suggest that the draft is = incomplete. If the comment is still accurate, then these need to be = fixed prior to progressing the draft. If it is not accurate, then I ask = the shepherd to please update the shepherd report. >=20 > - I'm a little surprised to see the draft describe EBML as a general = purpose markup language format, as opposed to one designed to be used by = Matroska and similar technologies. I suspect others will also be = surprised during the IETF LC and IESG review. The review bar is higher = for the IETF to recommend EBML as a general purpose markup language than = it is to recommend it for specific purposes. I also note that the CELLAR = charter talks about EBML in terms of being used by Matroska and FFV1. >=20 > Would it be acceptable to add some scoping language to the effect of = "EBML is used by Matroska[citation] and FFV1[citation]. It MAY be used = for use cases similar to those. The applicability of EBML for other use = cases is beyond the scope of this document". >=20 > - There are several defined elements/attributes related to versioning, = but I don't find an explanation of how they all work together. Please = add a section describing versioning in general. >=20 > =C2=A72: Please use the newer boilerplate from RFC 8174. >=20 > =C2=A73: Can you offer guidance on the specific impacts of the = mentioned attacks, and how to mitigate them? (If there is no way to = mitigate an attack, it's okay to say that.) >=20 > =C2=A75: Please elaborate on how this is similar to UTF8. I assume = this refers to using prefix bits to indicate the field length. UTF8 does = that to maintain backwards compatibility with Ascii. What is the design = motivation for using that approach for EBML, which I presume doesn't = have such a requirement? >=20 > =C2=A75.3: "If the number of bits required for "VINT_DATA" > are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be > zero-padded to the left to a size that fits." >=20 > Why not MUST? What happens if this is violated? >=20 > =C2=A76: > - "The "VINT_DATA" component of the "Element ID" MUST > NOT be either defined or written as either all zero values or all one > values." > Why? >=20 > =C2=A78.7: "In this case, the "EBML Reader" should skip data > until a valid..." > Should that be a normative statement? If so, why should and not MUST? >=20 > =C2=A78.8: If the EBML reader does not interpret Binary Elements, why = add them at all? What does interpret them? is the point that the EBML = reader treats Binary Elements as opaque, and just hands them to the = application? >=20 > =C2=A710.1.3: "NOT RECOMMENDED" seems overly strong, especially in = light of the MAY in the first paragraph. Is the point to say "MUST = NOT... except when the implementation needs to update an element without = rewriting the entire document"? >=20 > =C2=A711: "An "EBML Document" consists of "EBML Elements" and MUST > NOT contain any data that is not part of an "EBML Element"." >=20 > That contradicts text in =C2=A78.7 that says you can do this in = streaming use cases. >=20 > =C2=A713.1: "The "DocType" > value for an "EBML Document Type" SHOULD be unique and persistent." >=20 > What is the scope of uniqueness? How should it be achieved? Is there = an expectation to register Document Types? (Also, why not MUST)? >=20 > =C2=A713.1.4.1: Are there uniqueness requirements for name? >=20 > =C2=A713.1.4.2: > - The idea behind "path" needs elaboration. I'd like to see some = high-level discussion of how you indicate where an element is allowed, = and how you encode the structure. An example (local to the section) = would be helpful. >=20 > =C2=A713.1.4.4: > - "The "minOccurs" value MUST be > equal to the "EBMLMinOccurrence" value of the "path"." >=20 > Why have both if they have to be the same? (Same question for = =C2=A713.1.4.5) >=20 > =C2=A713.1.4.12: > - "If the "recurring" attribute > is not present then the "EBML Element" MUST be considered to NOT be > an "Identically Recurring Element"." >=20 > "be considered to" is vague for a MUST. What concrete action must = implementations take in this case? >=20 > =C2=A713.1.6.2: > - It seems likely readers will confuse "type" with "data type". Would = it be reasonable to call this "document-type" or something similar? >=20 > =C2=A713.1.10: > - Please state (and cite) which XML schema format is used here. >=20 > - Has the schema been mechanically verified? >=20 > =C2=A713.3.1: > - "The CRC value MUST be computed on a little > endian bitstream and MUST use little endian storage." >=20 > Please elaborate. Most elements have been big-endian so far. Do there = have to be converted to calculate the CRC? >=20 > =C2=A715.1: > - "The numbers 0x3FFF and 0x4000 are RESERVED.", "The numbers 0x1FFFFF = and 0x200000 are RESERVED.", and "The numbers 0xFFFFFFF and 0x1000000 = are RESERVED." > What is the purpose of reserving them? >=20 > - "Four octet Element IDs whose lower three octets (as > encoded) would make printable 7-bit ASCII values may be allocated > only Specification Required." >=20 > Can you state a range or a list? Don't make IANA judge which values = are printable. >=20 > =C2=A715.2: > - "The strings may be allocated according to > First Come First Served" >=20 > Is there a requirement to register them, or is this optional? >=20 >=20 >=20 >=20 > *** Editorial Comments and Nits *** >=20 > - General: The draft puts double quotes around every mention of terms = that it defines. That is unconventional for IETF documents. I personally = find that it makes the draft harder to read. I suggest quoting them on = the first mention, then just capitalizing them in subsequent mentions. >=20 > - General (style comment): Please consider removing most instances of = the word "considered". When the text says "X is considered to be equal = to Y", that sounds like a weaker (and harder to read) statement than "X = is equal to Y". Along the same lines, "considered" is rarely appropriate = to use in a normative statement. For example, instead of saying = "Implementations MUST consider X to be an error", it is better to state = what concrete actions you expect the implementation to take when X = occurs. >=20 > =C2=A73: >=20 > - The Security Considerations are required to be one of the last two = sections in the body of the document (that is, before the references). = More precisely, Security Considerations and IANA considerations should = be the last two sections in the documents. >=20 >=20 > - first paragraph: Please expand CRC on first mention. (Which may or = may not be this instance once the Security Considerations are moved to = the proper place.) >=20 > =C2=A75.2: "The "VINT_MARKER" MUST be one bit in length and > contain a bit with a value of one." > That's really more of a definition or statement of fact than a = normative requirement. Please consider replacing MUST with "is". >=20 > =C2=A75.3: > - "The bits required for the "VINT_WIDTH" and the > "VINT_MARKER" combined use one out of eight bits" > Consider "use one out of every eight bits" >=20 > =C2=A75.4, paragraph after first table: "Data encoded as a "Variable = Size Integer" MAY be rendered at octet > lengths larger than needed to store the data." > Is that intended as permission, or a statement of fact? If the latter, = then the normative keyword is not appropriate. >=20 > =C2=A76: > - "The "Element ID" MUST be encoded as a "Variable Size Integer"." > That seems like a definition. Consider s/MUST/is > - "MUST NOT be considered an error in the "EBML Document"." > "be considered" is vague for a normative requirement. What concrete = action is being prohibited (or required)? >=20 > =C2=A77: > - "The "Element Data Size" itself MUST be encoded as a "Variable > Size Integer"." > Consider s/MUST/is >=20 > - 'Only "Master Elements" SHALL be "Unknown-Sized Elements".' > The use of "only" in normative statements can be ambiguous. In this = case it can be read that non-master elements MUST NOT be of unknown = size, or that the SHALL only applies to master elements, and there is no = rule for non-master elements. Please consider formulating this as "MUST = NOT". >=20 > - "For example, an "EBML Element" with an octet length of 127 > MUST NOT be encoded in an "Element Data Size" encoding with a one > octet length." >=20 > Examples are not normative, therefore they should not include = normative keywords. >=20 > =C2=A78.1: "Signed Integers MUST be stored with two=E2=80=99s > complement notation" > Please consider s/MUST/are >=20 > =C2=A710.1.2: "This method is only RECOMMENDED for reducing "Element = Data" by a > single octet..." > Please avoid using "only" in normative requirements (see previous = comment for explanation). >=20 > =C2=A711.1 > - 'that uses an"EBMLVersion" of "1" MUST only contain "EBML Elements"' > Please avoid "only" on normative statements. >=20 > - last paragraph: Please consider dropping "All" from the beginning of = each sentence. >=20 > =C2=A711.1: > - Is the concept of a file concrete (in the sense of a unit of = persistent storage) or abstract (as in any stream of data)? I had = assumed the latter, but with the different rules about data outside of = EBML elements for "files" and "streaming applications", I am not so = sure. If you mean "file" concretely, does there need to be additional = text in this section describing the structure for streaming = applications? >=20 > - "The "EBML Body" MUST consist > only of "EBML Elements"" > Please avoid "only" on normative statements. > - 'what "EBML Elements"' (several occurances). s/what/which >=20 > =C2=A713.1: > - "one or many" (several times throughout draft): Should this be "one = or more"? Some people do not tend to think of numbers like 2 or 3 as = counting as "many". >=20 > - "An "EBML Schema" must be > expressed as well-formed XML." > Normative? >=20 > - "An "EBML Schema" MUST declare exactly one "EBML Element" at "Root > Level" (referred to as the "Root Element") that MUST occur exactly > once within an "EBML Document"." >=20 > The second "MUST" seems like a statement of fact. >=20 > - If an "EBML Schema" > adopts the "EBML Header Element" as-is, then it is not REQUIRED to > document that Element within the "EBML Schema"." >=20 > "REQUIRED" is not used normatively, and therefore should not be = capitalized. >=20 > =C2=A713.1.1.2: > - "The "version" lists an incremental non-negative integer..." >=20 > I'm not sure what it means for a single integer to be "incremental". = (But see substantive comment concerning versioning.) >=20 >=20 > =C2=A713.4.1.2: > - The ""*"", ""("" and "")"" symbols MUST be interpreted as they are > defined in the ABNF." > This _is_ the ABNF. Do you mean "as defined in RFC 5234? Also, the = normative MUST is not appropriate here; it's a matter of definition, not = a normative requirement. >=20 > - "The "EBMLElementOccurrence" part is interpreted as an ABNF Variable > Repetition. >=20 > I don't understand what that means. There won't be ABNF in an actual = schema, will there? (Same for "VariableParentOccurrence") >=20 > - ""EBML Elements" with "EBMLMinOccurrence" set to "1" that also have = a > "default" value (see Section 13.1.4.8) declared are not REQUIRED to > be stored but are REQUIRED to be interpreted," >=20 > Statement of fact? >=20 > =C2=A713.1.4.7 > - The attribute is called "size" but defined to be "length". Why not = call it length? (Or describe it as "size")? >=20 > =C2=A713.1.4.10: > - "A boolean to express if an "EBML Element" MAY be used as an = "Unknown- > Sized Element"" > Statement of fact. >=20 > =C2=A713.1.11: It would be helpful to have the example closer to the = element descriptions. I suggesting putting this section before the = schema section. >=20 > =C2=A713.1.13: Why is the material is this section separate from the = range element description? >=20 >=20 > =C2=A713.1.14: > - "When a float value is represented textually in an "EBML Schema", = such > as within a "default" or "range" value,..." >=20 > The examples only talk about ranges. Can there be an example for a = default value? >=20 > =C2=A713.1.15: > - "In this case, the default value of the "Mandatory EBML > Element" MUST be interpreted by the "EBML Reader" although the "EBML > Element" is not present within its "Parent Element"." >=20 > I'm not sure the intent here. Is "interpreted" the correct word = choice? >=20 > =C2=A713.3.2: > - "Used to void damaged data, to avoid unexpected behaviors > when using damaged data." >=20 > Comma splice. >=20 > =C2=A714 > - "If a "Master Element" contains a "CRC-32 Element" that doesn=E2=80=99= t > validate, then the "EBML Reader" MAY ignore all contained data except > for "Descendant Elements" which contain their own valid "CRC-32 > Element"." >=20 > s/ ", which" / " that" >=20 > =C2=A715.1: > - "Values from 1 to 126 are to > be allocated according to RFC Required." >=20 > I suggest '... allocated according to the "RFC Required" policy.' = (Note: This pattern occurs several times in the RFC considerations = section.) Also, please cite 8126 on the first mention of each policy (or = state in advance that all registration policies mentioned herein are = defined in 8126). >=20 > - "Numbers MAY be allocated within this range according to > Specification Required." > s/MAY/are >=20 >=20 >=20 --Apple-Mail=_49BA1CAC-4B8A-4DB7-AACE-490E5590B610 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw9HoYACgkQgFZKbJXz 1A1Mng/8DITJQUnDeudOrSM7OscGmBI24Y//tLn6HZh1LjmE5wVa2vU5BQisLN1Q 6SfWPIeatzu1gHpokQX1CFQrjdogDPB22xp0ppMn1ZVnn9cOoxCLtLyCoLbEn/dw uwlQAXKYTtftqkwrHQSM+keeFXZVY4cSzaTi4i0MHxkg472aM41EDEgbR00ul8ib UCOA0j3x0iZFUMiWo7mXXL0knz0nQT0BZZtnQfkLTO/v7u5bnE3L4+mdjBFFjNzh TuxSGvhKLhVmWoNjvxcM7hEhyf4GN7AtQarjorG2LSWhM/2EmhLbEw0HnbgC7hxy 4W2N7zHEAkMpJe3T0a2vkGUzNhr8hJe5hmNlfO6qTRPLWiyfwXWOPrJ2ImNsBigK eO/aQ80w9ikmUi/VnV2h5lyQAifRxeLiZHuyV6aXixYCNAyaJCuGzIMAOsHfF2C/ DR/3cuGFgw1kugzoZRCZX1t8HcRMsdGiFDKPM04CzuOAGrr8velC0wgwrvrykxE7 Hr7ZQjLyz5TvlpFP4uFYav83ICmj0oVN+pwl+mvIZT9D0oFV4qVzeimECM3acTNU De7cXyxVF8OLM7bmBBv4BjP6ro71OLqRktQMV7b3NfvSvmJaf9w6GaiqXdoNCaJn 7Fke5n8YGwETk3uv0G2i7xZaKU2UvHxQbUe9axQYVWAZHi5owzA= =JCCh -----END PGP SIGNATURE----- --Apple-Mail=_49BA1CAC-4B8A-4DB7-AACE-490E5590B610-- From nobody Mon Jan 14 16:13:10 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14DC12D4EA; Mon, 14 Jan 2019 16:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=no autolearn_force=no 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 DIUNEdlVaElI; Mon, 14 Jan 2019 16:13:07 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 07693128CE4; Mon, 14 Jan 2019 16:13:07 -0800 (PST) Received: from [172.58.231.44] (port=38770 helo=[IPv6:2607:fb90:7a23:d46d:7517:d8b4:f579:cf48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gjCLn-003Xz8-IN; Mon, 14 Jan 2019 19:13:06 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dave Rice X-Mailer: iPhone Mail (15B202) In-Reply-To: <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> Date: Mon, 14 Jan 2019 19:13:01 -0500 Cc: draft-ietf-cellar-ebml.all@ietf.org, cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C6AF258-F52F-485B-BD53-8B4234403830@dericed.com> References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> To: Ben Campbell X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 00:13:09 -0000 Hi Ben, I did start dissecting the comments into issues for discussions and edits fo= r what is straightforward so do have a draft response in the works. I=E2=80=99= ll get that out tomorrow even though it will be a partial response. Thanks f= or your work here. Dave > On Jan 14, 2019, at 18:43, Ben Campbell wrote: >=20 > Hi, >=20 > Any thoughts on my AD evaluation review? >=20 > I know there=E2=80=99s a lot of comments. Please don=E2=80=99t take that a= s critical; it=E2=80=99s not at all unusual for the Area Director review to g= enerate a lot of comments :-) >=20 > Thanks! >=20 > Ben. >=20 >> On Jan 7, 2019, at 3:14 PM, Ben Campbell wrote: >>=20 >>=20 >> Hi, >>=20 >> This is my AD Evaluation of draft-ietf-cellar-ebml-08. >>=20 >> Thanks for this work. It's generally on the right track, but I have a num= ber of comments that I would like to discuss prior progressing. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> *** Substantive Comments *** >>=20 >> - The Shepherd Report says "There are minor nits to be resolved (adding o= ne RFC 2119 keyword and some schema attributes which are mentioned= but not defined." >>=20 >> Do that comment still apply? To be clear, those are more than nits. Addin= g a 2119 keyword is substantive change that needs to be agreed to but the wo= rking group. Undefined attributes suggest that the draft is incomplete. If t= he comment is still accurate, then these need to be fixed prior to progressi= ng the draft. If it is not accurate, then I ask the shepherd to please updat= e the shepherd report. >>=20 >> - I'm a little surprised to see the draft describe EBML as a general purp= ose markup language format, as opposed to one designed to be used by Matrosk= a and similar technologies. I suspect others will also be surprised during t= he IETF LC and IESG review. The review bar is higher for the IETF to recomme= nd EBML as a general purpose markup language than it is to recommend it for s= pecific purposes. I also note that the CELLAR charter talks about EBML in te= rms of being used by Matroska and FFV1. >>=20 >> Would it be acceptable to add some scoping language to the effect of "EBM= L is used by Matroska[citation] and FFV1[citation]. It MAY be used for use c= ases similar to those. The applicability of EBML for other use cases is beyo= nd the scope of this document". >>=20 >> - There are several defined elements/attributes related to versioning, bu= t I don't find an explanation of how they all work together. Please add a se= ction describing versioning in general. >>=20 >> =C2=A72: Please use the newer boilerplate from RFC 8174. >>=20 >> =C2=A73: Can you offer guidance on the specific impacts of the mentioned a= ttacks, and how to mitigate them? (If there is no way to mitigate an attack,= it's okay to say that.) >>=20 >> =C2=A75: Please elaborate on how this is similar to UTF8. I assume this r= efers to using prefix bits to indicate the field length. UTF8 does that to m= aintain backwards compatibility with Ascii. What is the design motivation fo= r using that approach for EBML, which I presume doesn't have such a requirem= ent? >>=20 >> =C2=A75.3: "If the number of bits required for "VINT_DATA" >> are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be >> zero-padded to the left to a size that fits." >>=20 >> Why not MUST? What happens if this is violated? >>=20 >> =C2=A76: >> - "The "VINT_DATA" component of the "Element ID" MUST >> NOT be either defined or written as either all zero values or all one >> values." >> Why? >>=20 >> =C2=A78.7: "In this case, the "EBML Reader" should skip data >> until a valid..." >> Should that be a normative statement? If so, why should and not MUST? >>=20 >> =C2=A78.8: If the EBML reader does not interpret Binary Elements, why add= them at all? What does interpret them? is the point that the EBML reader tr= eats Binary Elements as opaque, and just hands them to the application? >>=20 >> =C2=A710.1.3: "NOT RECOMMENDED" seems overly strong, especially in light o= f the MAY in the first paragraph. Is the point to say "MUST NOT... except wh= en the implementation needs to update an element without rewriting the entir= e document"? >>=20 >> =C2=A711: "An "EBML Document" consists of "EBML Elements" and MUST >> NOT contain any data that is not part of an "EBML Element"." >>=20 >> That contradicts text in =C2=A78.7 that says you can do this in streaming= use cases. >>=20 >> =C2=A713.1: "The "DocType" >> value for an "EBML Document Type" SHOULD be unique and persistent." >>=20 >> What is the scope of uniqueness? How should it be achieved? Is there an e= xpectation to register Document Types? (Also, why not MUST)? >>=20 >> =C2=A713.1.4.1: Are there uniqueness requirements for name? >>=20 >> =C2=A713.1.4.2: >> - The idea behind "path" needs elaboration. I'd like to see some high-lev= el discussion of how you indicate where an element is allowed, and how you e= ncode the structure. An example (local to the section) would be helpful. >>=20 >> =C2=A713.1.4.4: >> - "The "minOccurs" value MUST be >> equal to the "EBMLMinOccurrence" value of the "path"." >>=20 >> Why have both if they have to be the same? (Same question for =C2=A713.1.= 4.5) >>=20 >> =C2=A713.1.4.12: >> - "If the "recurring" attribute >> is not present then the "EBML Element" MUST be considered to NOT be >> an "Identically Recurring Element"." >>=20 >> "be considered to" is vague for a MUST. What concrete action must impleme= ntations take in this case? >>=20 >> =C2=A713.1.6.2: >> - It seems likely readers will confuse "type" with "data type". Would it b= e reasonable to call this "document-type" or something similar? >>=20 >> =C2=A713.1.10: >> - Please state (and cite) which XML schema format is used here. >>=20 >> - Has the schema been mechanically verified? >>=20 >> =C2=A713.3.1: >> - "The CRC value MUST be computed on a little >> endian bitstream and MUST use little endian storage." >>=20 >> Please elaborate. Most elements have been big-endian so far. Do there hav= e to be converted to calculate the CRC? >>=20 >> =C2=A715.1: >> - "The numbers 0x3FFF and 0x4000 are RESERVED.", "The numbers 0x1FFFFF an= d 0x200000 are RESERVED.", and "The numbers 0xFFFFFFF and 0x1000000 are RESE= RVED." >> What is the purpose of reserving them? >>=20 >> - "Four octet Element IDs whose lower three octets (as >> encoded) would make printable 7-bit ASCII values may be allocated >> only Specification Required." >>=20 >> Can you state a range or a list? Don't make IANA judge which values are p= rintable. >>=20 >> =C2=A715.2: >> - "The strings may be allocated according to >> First Come First Served" >>=20 >> Is there a requirement to register them, or is this optional? >>=20 >>=20 >>=20 >>=20 >> *** Editorial Comments and Nits *** >>=20 >> - General: The draft puts double quotes around every mention of terms tha= t it defines. That is unconventional for IETF documents. I personally find t= hat it makes the draft harder to read. I suggest quoting them on the first m= ention, then just capitalizing them in subsequent mentions. >>=20 >> - General (style comment): Please consider removing most instances of the= word "considered". When the text says "X is considered to be equal to Y", t= hat sounds like a weaker (and harder to read) statement than "X is equal to Y= ". Along the same lines, "considered" is rarely appropriate to use in a norm= ative statement. For example, instead of saying "Implementations MUST consid= er X to be an error", it is better to state what concrete actions you expect= the implementation to take when X occurs. >>=20 >> =C2=A73: >>=20 >> - The Security Considerations are required to be one of the last two sect= ions in the body of the document (that is, before the references). More prec= isely, Security Considerations and IANA considerations should be the last tw= o sections in the documents. >>=20 >>=20 >> - first paragraph: Please expand CRC on first mention. (Which may or may n= ot be this instance once the Security Considerations are moved to the proper= place.) >>=20 >> =C2=A75.2: "The "VINT_MARKER" MUST be one bit in length and >> contain a bit with a value of one." >> That's really more of a definition or statement of fact than a normative r= equirement. Please consider replacing MUST with "is". >>=20 >> =C2=A75.3: >> - "The bits required for the "VINT_WIDTH" and the >> "VINT_MARKER" combined use one out of eight bits" >> Consider "use one out of every eight bits" >>=20 >> =C2=A75.4, paragraph after first table: "Data encoded as a "Variable Size= Integer" MAY be rendered at octet >> lengths larger than needed to store the data." >> Is that intended as permission, or a statement of fact? If the latter, th= en the normative keyword is not appropriate. >>=20 >> =C2=A76: >> - "The "Element ID" MUST be encoded as a "Variable Size Integer"." >> That seems like a definition. Consider s/MUST/is >> - "MUST NOT be considered an error in the "EBML Document"." >> "be considered" is vague for a normative requirement. What concrete actio= n is being prohibited (or required)? >>=20 >> =C2=A77: >> - "The "Element Data Size" itself MUST be encoded as a "Variable >> Size Integer"." >> Consider s/MUST/is >>=20 >> - 'Only "Master Elements" SHALL be "Unknown-Sized Elements".' >> The use of "only" in normative statements can be ambiguous. In this case i= t can be read that non-master elements MUST NOT be of unknown size, or that t= he SHALL only applies to master elements, and there is no rule for non-maste= r elements. Please consider formulating this as "MUST NOT". >>=20 >> - "For example, an "EBML Element" with an octet length of 127 >> MUST NOT be encoded in an "Element Data Size" encoding with a one >> octet length." >>=20 >> Examples are not normative, therefore they should not include normative k= eywords. >>=20 >> =C2=A78.1: "Signed Integers MUST be stored with two=E2=80=99s >> complement notation" >> Please consider s/MUST/are >>=20 >> =C2=A710.1.2: "This method is only RECOMMENDED for reducing "Element Data= " by a >> single octet..." >> Please avoid using "only" in normative requirements (see previous comment= for explanation). >>=20 >> =C2=A711.1 >> - 'that uses an"EBMLVersion" of "1" MUST only contain "EBML Elements"' >> Please avoid "only" on normative statements. >>=20 >> - last paragraph: Please consider dropping "All" from the beginning of ea= ch sentence. >>=20 >> =C2=A711.1: >> - Is the concept of a file concrete (in the sense of a unit of persistent= storage) or abstract (as in any stream of data)? I had assumed the latter, b= ut with the different rules about data outside of EBML elements for "files" a= nd "streaming applications", I am not so sure. If you mean "file" concretely= , does there need to be additional text in this section describing the struc= ture for streaming applications? >>=20 >> - "The "EBML Body" MUST consist >> only of "EBML Elements"" >> Please avoid "only" on normative statements. >> - 'what "EBML Elements"' (several occurances). s/what/which >>=20 >> =C2=A713.1: >> - "one or many" (several times throughout draft): Should this be "one or m= ore"? Some people do not tend to think of numbers like 2 or 3 as counting as= "many". >>=20 >> - "An "EBML Schema" must be >> expressed as well-formed XML." >> Normative? >>=20 >> - "An "EBML Schema" MUST declare exactly one "EBML Element" at "Root >> Level" (referred to as the "Root Element") that MUST occur exactly >> once within an "EBML Document"." >>=20 >> The second "MUST" seems like a statement of fact. >>=20 >> - If an "EBML Schema" >> adopts the "EBML Header Element" as-is, then it is not REQUIRED to >> document that Element within the "EBML Schema"." >>=20 >> "REQUIRED" is not used normatively, and therefore should not be capitaliz= ed. >>=20 >> =C2=A713.1.1.2: >> - "The "version" lists an incremental non-negative integer..." >>=20 >> I'm not sure what it means for a single integer to be "incremental". (But= see substantive comment concerning versioning.) >>=20 >>=20 >> =C2=A713.4.1.2: >> - The ""*"", ""("" and "")"" symbols MUST be interpreted as they are >> defined in the ABNF." >> This _is_ the ABNF. Do you mean "as defined in RFC 5234? Also, the norma= tive MUST is not appropriate here; it's a matter of definition, not a normat= ive requirement. >>=20 >> - "The "EBMLElementOccurrence" part is interpreted as an ABNF Variable >> Repetition. >>=20 >> I don't understand what that means. There won't be ABNF in an actual sche= ma, will there? (Same for "VariableParentOccurrence") >>=20 >> - ""EBML Elements" with "EBMLMinOccurrence" set to "1" that also have a >> "default" value (see Section 13.1.4.8) declared are not REQUIRED to >> be stored but are REQUIRED to be interpreted," >>=20 >> Statement of fact? >>=20 >> =C2=A713.1.4.7 >> - The attribute is called "size" but defined to be "length". Why not call= it length? (Or describe it as "size")? >>=20 >> =C2=A713.1.4.10: >> - "A boolean to express if an "EBML Element" MAY be used as an "Unknown- >> Sized Element"" >> Statement of fact. >>=20 >> =C2=A713.1.11: It would be helpful to have the example closer to the elem= ent descriptions. I suggesting putting this section before the schema sectio= n. >>=20 >> =C2=A713.1.13: Why is the material is this section separate from the rang= e element description? >>=20 >>=20 >> =C2=A713.1.14: >> - "When a float value is represented textually in an "EBML Schema", such >> as within a "default" or "range" value,..." >>=20 >> The examples only talk about ranges. Can there be an example for a defaul= t value? >>=20 >> =C2=A713.1.15: >> - "In this case, the default value of the "Mandatory EBML >> Element" MUST be interpreted by the "EBML Reader" although the "EBML >> Element" is not present within its "Parent Element"." >>=20 >> I'm not sure the intent here. Is "interpreted" the correct word choice? >>=20 >> =C2=A713.3.2: >> - "Used to void damaged data, to avoid unexpected behaviors >> when using damaged data." >>=20 >> Comma splice. >>=20 >> =C2=A714 >> - "If a "Master Element" contains a "CRC-32 Element" that doesn=E2=80=99t= >> validate, then the "EBML Reader" MAY ignore all contained data except >> for "Descendant Elements" which contain their own valid "CRC-32 >> Element"." >>=20 >> s/ ", which" / " that" >>=20 >> =C2=A715.1: >> - "Values from 1 to 126 are to >> be allocated according to RFC Required." >>=20 >> I suggest '... allocated according to the "RFC Required" policy.' (Note: T= his pattern occurs several times in the RFC considerations section.) Also, p= lease cite 8126 on the first mention of each policy (or state in advance tha= t all registration policies mentioned herein are defined in 8126). >>=20 >> - "Numbers MAY be allocated within this range according to >> Specification Required." >> s/MAY/are >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Mon Jan 14 16:24:36 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75F712D4EA; Mon, 14 Jan 2019 16:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 utieAYY_Ewy5; Mon, 14 Jan 2019 16:24:32 -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 5F950128CE4; Mon, 14 Jan 2019 16:24:32 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0F0NliS068590 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 18:23:48 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547511828; bh=ccAkPbcBHRxHGB3vElp9JOfxpj8t1X+qPHflp/JSmb0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BqV+PGvgJ2voJm+HVj9a6Jm2tqjG+lL2eacKyOwuSCxz6XImrnwR0PNCBvIVQBHwl N90D1sFDuoha0W9ZYkez8ARzIcVjvbAup6kIrO70CeZWHLp/VbV9EieJNs8cUhKAGy uMafuqREXYMNmsU9ERkE4rso+SCeIMTrK3JaiXe0= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <98A5399F-5C92-426D-B4C2-F74B3B55EFD0@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_28FCB566-D528-41D2-9B1B-559C55CF6BE8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 18:23:46 -0600 In-Reply-To: <6C6AF258-F52F-485B-BD53-8B4234403830@dericed.com> Cc: draft-ietf-cellar-ebml.all@ietf.org, cellar@ietf.org To: Dave Rice References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> <6C6AF258-F52F-485B-BD53-8B4234403830@dericed.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 00:24:35 -0000 --Apple-Mail=_28FCB566-D528-41D2-9B1B-559C55CF6BE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Excellent, thanks! Ben. > On Jan 14, 2019, at 6:13 PM, Dave Rice wrote: >=20 > Hi Ben, > I did start dissecting the comments into issues for discussions and = edits for what is straightforward so do have a draft response in the = works. I=E2=80=99ll get that out tomorrow even though it will be a = partial response. Thanks for your work here. > Dave >=20 >> On Jan 14, 2019, at 18:43, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> Any thoughts on my AD evaluation review? >>=20 >> I know there=E2=80=99s a lot of comments. Please don=E2=80=99t take = that as critical; it=E2=80=99s not at all unusual for the Area Director = review to generate a lot of comments :-) >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Jan 7, 2019, at 3:14 PM, Ben Campbell wrote: >>>=20 >>>=20 >>> Hi, >>>=20 >>> This is my AD Evaluation of draft-ietf-cellar-ebml-08. >>>=20 >>> Thanks for this work. It's generally on the right track, but I have = a number of comments that I would like to discuss prior progressing. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>> *** Substantive Comments *** >>>=20 >>> - The Shepherd Report says "There are minor nits to be resolved = (adding one RFC 2119 keyword and some schema attributes which = are mentioned but not defined." >>>=20 >>> Do that comment still apply? To be clear, those are more than nits. = Adding a 2119 keyword is substantive change that needs to be agreed to = but the working group. Undefined attributes suggest that the draft is = incomplete. If the comment is still accurate, then these need to be = fixed prior to progressing the draft. If it is not accurate, then I ask = the shepherd to please update the shepherd report. >>>=20 >>> - I'm a little surprised to see the draft describe EBML as a general = purpose markup language format, as opposed to one designed to be used by = Matroska and similar technologies. I suspect others will also be = surprised during the IETF LC and IESG review. The review bar is higher = for the IETF to recommend EBML as a general purpose markup language than = it is to recommend it for specific purposes. I also note that the CELLAR = charter talks about EBML in terms of being used by Matroska and FFV1. >>>=20 >>> Would it be acceptable to add some scoping language to the effect of = "EBML is used by Matroska[citation] and FFV1[citation]. It MAY be used = for use cases similar to those. The applicability of EBML for other use = cases is beyond the scope of this document". >>>=20 >>> - There are several defined elements/attributes related to = versioning, but I don't find an explanation of how they all work = together. Please add a section describing versioning in general. >>>=20 >>> =C2=A72: Please use the newer boilerplate from RFC 8174. >>>=20 >>> =C2=A73: Can you offer guidance on the specific impacts of the = mentioned attacks, and how to mitigate them? (If there is no way to = mitigate an attack, it's okay to say that.) >>>=20 >>> =C2=A75: Please elaborate on how this is similar to UTF8. I assume = this refers to using prefix bits to indicate the field length. UTF8 does = that to maintain backwards compatibility with Ascii. What is the design = motivation for using that approach for EBML, which I presume doesn't = have such a requirement? >>>=20 >>> =C2=A75.3: "If the number of bits required for "VINT_DATA" >>> are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD = be >>> zero-padded to the left to a size that fits." >>>=20 >>> Why not MUST? What happens if this is violated? >>>=20 >>> =C2=A76: >>> - "The "VINT_DATA" component of the "Element ID" MUST >>> NOT be either defined or written as either all zero values or all = one >>> values." >>> Why? >>>=20 >>> =C2=A78.7: "In this case, the "EBML Reader" should skip data >>> until a valid..." >>> Should that be a normative statement? If so, why should and not = MUST? >>>=20 >>> =C2=A78.8: If the EBML reader does not interpret Binary Elements, = why add them at all? What does interpret them? is the point that the = EBML reader treats Binary Elements as opaque, and just hands them to the = application? >>>=20 >>> =C2=A710.1.3: "NOT RECOMMENDED" seems overly strong, especially in = light of the MAY in the first paragraph. Is the point to say "MUST = NOT... except when the implementation needs to update an element without = rewriting the entire document"? >>>=20 >>> =C2=A711: "An "EBML Document" consists of "EBML Elements" and MUST >>> NOT contain any data that is not part of an "EBML Element"." >>>=20 >>> That contradicts text in =C2=A78.7 that says you can do this in = streaming use cases. >>>=20 >>> =C2=A713.1: "The "DocType" >>> value for an "EBML Document Type" SHOULD be unique and persistent." >>>=20 >>> What is the scope of uniqueness? How should it be achieved? Is there = an expectation to register Document Types? (Also, why not MUST)? >>>=20 >>> =C2=A713.1.4.1: Are there uniqueness requirements for name? >>>=20 >>> =C2=A713.1.4.2: >>> - The idea behind "path" needs elaboration. I'd like to see some = high-level discussion of how you indicate where an element is allowed, = and how you encode the structure. An example (local to the section) = would be helpful. >>>=20 >>> =C2=A713.1.4.4: >>> - "The "minOccurs" value MUST be >>> equal to the "EBMLMinOccurrence" value of the "path"." >>>=20 >>> Why have both if they have to be the same? (Same question for = =C2=A713.1.4.5) >>>=20 >>> =C2=A713.1.4.12: >>> - "If the "recurring" attribute >>> is not present then the "EBML Element" MUST be considered to NOT be >>> an "Identically Recurring Element"." >>>=20 >>> "be considered to" is vague for a MUST. What concrete action must = implementations take in this case? >>>=20 >>> =C2=A713.1.6.2: >>> - It seems likely readers will confuse "type" with "data type". = Would it be reasonable to call this "document-type" or something = similar? >>>=20 >>> =C2=A713.1.10: >>> - Please state (and cite) which XML schema format is used here. >>>=20 >>> - Has the schema been mechanically verified? >>>=20 >>> =C2=A713.3.1: >>> - "The CRC value MUST be computed on a little >>> endian bitstream and MUST use little endian storage." >>>=20 >>> Please elaborate. Most elements have been big-endian so far. Do = there have to be converted to calculate the CRC? >>>=20 >>> =C2=A715.1: >>> - "The numbers 0x3FFF and 0x4000 are RESERVED.", "The numbers = 0x1FFFFF and 0x200000 are RESERVED.", and "The numbers 0xFFFFFFF and = 0x1000000 are RESERVED." >>> What is the purpose of reserving them? >>>=20 >>> - "Four octet Element IDs whose lower three octets (as >>> encoded) would make printable 7-bit ASCII values may be allocated >>> only Specification Required." >>>=20 >>> Can you state a range or a list? Don't make IANA judge which values = are printable. >>>=20 >>> =C2=A715.2: >>> - "The strings may be allocated according to >>> First Come First Served" >>>=20 >>> Is there a requirement to register them, or is this optional? >>>=20 >>>=20 >>>=20 >>>=20 >>> *** Editorial Comments and Nits *** >>>=20 >>> - General: The draft puts double quotes around every mention of = terms that it defines. That is unconventional for IETF documents. I = personally find that it makes the draft harder to read. I suggest = quoting them on the first mention, then just capitalizing them in = subsequent mentions. >>>=20 >>> - General (style comment): Please consider removing most instances = of the word "considered". When the text says "X is considered to be = equal to Y", that sounds like a weaker (and harder to read) statement = than "X is equal to Y". Along the same lines, "considered" is rarely = appropriate to use in a normative statement. For example, instead of = saying "Implementations MUST consider X to be an error", it is better to = state what concrete actions you expect the implementation to take when X = occurs. >>>=20 >>> =C2=A73: >>>=20 >>> - The Security Considerations are required to be one of the last two = sections in the body of the document (that is, before the references). = More precisely, Security Considerations and IANA considerations should = be the last two sections in the documents. >>>=20 >>>=20 >>> - first paragraph: Please expand CRC on first mention. (Which may or = may not be this instance once the Security Considerations are moved to = the proper place.) >>>=20 >>> =C2=A75.2: "The "VINT_MARKER" MUST be one bit in length and >>> contain a bit with a value of one." >>> That's really more of a definition or statement of fact than a = normative requirement. Please consider replacing MUST with "is". >>>=20 >>> =C2=A75.3: >>> - "The bits required for the "VINT_WIDTH" and the >>> "VINT_MARKER" combined use one out of eight bits" >>> Consider "use one out of every eight bits" >>>=20 >>> =C2=A75.4, paragraph after first table: "Data encoded as a "Variable = Size Integer" MAY be rendered at octet >>> lengths larger than needed to store the data." >>> Is that intended as permission, or a statement of fact? If the = latter, then the normative keyword is not appropriate. >>>=20 >>> =C2=A76: >>> - "The "Element ID" MUST be encoded as a "Variable Size Integer"." >>> That seems like a definition. Consider s/MUST/is >>> - "MUST NOT be considered an error in the "EBML Document"." >>> "be considered" is vague for a normative requirement. What concrete = action is being prohibited (or required)? >>>=20 >>> =C2=A77: >>> - "The "Element Data Size" itself MUST be encoded as a "Variable >>> Size Integer"." >>> Consider s/MUST/is >>>=20 >>> - 'Only "Master Elements" SHALL be "Unknown-Sized Elements".' >>> The use of "only" in normative statements can be ambiguous. In this = case it can be read that non-master elements MUST NOT be of unknown = size, or that the SHALL only applies to master elements, and there is no = rule for non-master elements. Please consider formulating this as "MUST = NOT". >>>=20 >>> - "For example, an "EBML Element" with an octet length of 127 >>> MUST NOT be encoded in an "Element Data Size" encoding with a one >>> octet length." >>>=20 >>> Examples are not normative, therefore they should not include = normative keywords. >>>=20 >>> =C2=A78.1: "Signed Integers MUST be stored with two=E2=80=99s >>> complement notation" >>> Please consider s/MUST/are >>>=20 >>> =C2=A710.1.2: "This method is only RECOMMENDED for reducing "Element = Data" by a >>> single octet..." >>> Please avoid using "only" in normative requirements (see previous = comment for explanation). >>>=20 >>> =C2=A711.1 >>> - 'that uses an"EBMLVersion" of "1" MUST only contain "EBML = Elements"' >>> Please avoid "only" on normative statements. >>>=20 >>> - last paragraph: Please consider dropping "All" from the beginning = of each sentence. >>>=20 >>> =C2=A711.1: >>> - Is the concept of a file concrete (in the sense of a unit of = persistent storage) or abstract (as in any stream of data)? I had = assumed the latter, but with the different rules about data outside of = EBML elements for "files" and "streaming applications", I am not so = sure. If you mean "file" concretely, does there need to be additional = text in this section describing the structure for streaming = applications? >>>=20 >>> - "The "EBML Body" MUST consist >>> only of "EBML Elements"" >>> Please avoid "only" on normative statements. >>> - 'what "EBML Elements"' (several occurances). s/what/which >>>=20 >>> =C2=A713.1: >>> - "one or many" (several times throughout draft): Should this be = "one or more"? Some people do not tend to think of numbers like 2 or 3 = as counting as "many". >>>=20 >>> - "An "EBML Schema" must be >>> expressed as well-formed XML." >>> Normative? >>>=20 >>> - "An "EBML Schema" MUST declare exactly one "EBML Element" at "Root >>> Level" (referred to as the "Root Element") that MUST occur exactly >>> once within an "EBML Document"." >>>=20 >>> The second "MUST" seems like a statement of fact. >>>=20 >>> - If an "EBML Schema" >>> adopts the "EBML Header Element" as-is, then it is not REQUIRED to >>> document that Element within the "EBML Schema"." >>>=20 >>> "REQUIRED" is not used normatively, and therefore should not be = capitalized. >>>=20 >>> =C2=A713.1.1.2: >>> - "The "version" lists an incremental non-negative integer..." >>>=20 >>> I'm not sure what it means for a single integer to be "incremental". = (But see substantive comment concerning versioning.) >>>=20 >>>=20 >>> =C2=A713.4.1.2: >>> - The ""*"", ""("" and "")"" symbols MUST be interpreted as they are >>> defined in the ABNF." >>> This _is_ the ABNF. Do you mean "as defined in RFC 5234? Also, the = normative MUST is not appropriate here; it's a matter of definition, not = a normative requirement. >>>=20 >>> - "The "EBMLElementOccurrence" part is interpreted as an ABNF = Variable >>> Repetition. >>>=20 >>> I don't understand what that means. There won't be ABNF in an actual = schema, will there? (Same for "VariableParentOccurrence") >>>=20 >>> - ""EBML Elements" with "EBMLMinOccurrence" set to "1" that also = have a >>> "default" value (see Section 13.1.4.8) declared are not REQUIRED to >>> be stored but are REQUIRED to be interpreted," >>>=20 >>> Statement of fact? >>>=20 >>> =C2=A713.1.4.7 >>> - The attribute is called "size" but defined to be "length". Why not = call it length? (Or describe it as "size")? >>>=20 >>> =C2=A713.1.4.10: >>> - "A boolean to express if an "EBML Element" MAY be used as an = "Unknown- >>> Sized Element"" >>> Statement of fact. >>>=20 >>> =C2=A713.1.11: It would be helpful to have the example closer to the = element descriptions. I suggesting putting this section before the = schema section. >>>=20 >>> =C2=A713.1.13: Why is the material is this section separate from the = range element description? >>>=20 >>>=20 >>> =C2=A713.1.14: >>> - "When a float value is represented textually in an "EBML Schema", = such >>> as within a "default" or "range" value,..." >>>=20 >>> The examples only talk about ranges. Can there be an example for a = default value? >>>=20 >>> =C2=A713.1.15: >>> - "In this case, the default value of the "Mandatory EBML >>> Element" MUST be interpreted by the "EBML Reader" although the "EBML >>> Element" is not present within its "Parent Element"." >>>=20 >>> I'm not sure the intent here. Is "interpreted" the correct word = choice? >>>=20 >>> =C2=A713.3.2: >>> - "Used to void damaged data, to avoid unexpected behaviors >>> when using damaged data." >>>=20 >>> Comma splice. >>>=20 >>> =C2=A714 >>> - "If a "Master Element" contains a "CRC-32 Element" that doesn=E2=80=99= t >>> validate, then the "EBML Reader" MAY ignore all contained data = except >>> for "Descendant Elements" which contain their own valid "CRC-32 >>> Element"." >>>=20 >>> s/ ", which" / " that" >>>=20 >>> =C2=A715.1: >>> - "Values from 1 to 126 are to >>> be allocated according to RFC Required." >>>=20 >>> I suggest '... allocated according to the "RFC Required" policy.' = (Note: This pattern occurs several times in the RFC considerations = section.) Also, please cite 8126 on the first mention of each policy (or = state in advance that all registration policies mentioned herein are = defined in 8126). >>>=20 >>> - "Numbers MAY be allocated within this range according to >>> Specification Required." >>> s/MAY/are >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 --Apple-Mail=_28FCB566-D528-41D2-9B1B-559C55CF6BE8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw9KBIACgkQgFZKbJXz 1A1jMhAAn7ZWkG5T0ry+T2brk9f88CpM0M7Yel+PgAAoZpk62fyJdg4NgBc26gTV 8QNbaTajf572vQMuIox3GVDrIdF1UpmQFiGFyeGMlETTtGLMJMpfJwVq9QwJ9Eee KzNnSXeAPkiCz7OMSl3mz+YW8rFHb2hIfPcUtNf0pmK4sKB5UJwzzQqqQJqHHz1r erB3/flol7x9Ig3TfEnWWjoVR5xTwt6mDELHsKp2FISVaIp0iOlFIkv0R0OMlUJn OCSV9FMhFJpb8N5nyEziIsoaY/Frd1eWzxarow0vKrt5nu02n1yFXkr5eYzV9ir1 5OFrfPcvsaNTtgYiTF1q1fJCzworlH271sHlOfyubMw7y7VYFj3c5cU77vciVRkk Z0rgtmeeWmHdmseqDrL/QK5k5lCm9LUJ7QTeVhm2xWiNRsXbVfsl9HMriQx9wSuT 4HsDBW1RFcjQbmzBPIGj2GYwX3XR4Txgfnw/vxc20PthZ4T5byGXfkzlmNTHEoLa 4r8j0i2okEVsH76GAJTeG2hK3qTE65ryGTv1OXDRtGgqXoToLqSSw6XviAhTs3Dp aM3hzwsut/wV2qi9EaGqW3CCgBHFaGcPcEMXVtIqmwRY4H+TZLWS6e2BtBa96xn0 jwmawJQ52b5BxOv7xmWB/1bd6J934wYR8wvNdHJZwQw5ob/sBmM= =8A/s -----END PGP SIGNATURE----- --Apple-Mail=_28FCB566-D528-41D2-9B1B-559C55CF6BE8-- From nobody Tue Jan 15 00:14:07 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCF4130DFA for ; Tue, 15 Jan 2019 00:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org 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 8HVlhVzMBu7X for ; Tue, 15 Jan 2019 00:14:02 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 7138B130DEA for ; Tue, 15 Jan 2019 00:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To:From:References; bh=XXJ2FqKV2Pv+GmoVB3dBGGVlU/SJ0sPh01IP55d6zhY=; b=A4nh9gcROBfMNeRiJHZqcks/lvm8CqQkakmszpuFbT9ximQShen+wDT1nlQ3E8sFqlu8BM5NcnUNYoaDrrFZaXuMkJLRRvCAx76JAzahJzAf4uTXJJOdM5NJ2MQhsMWLR6rW4ON4Ql+oyApNnQuD7g6StrzGohpHGsRszdhQlTU=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:39616) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gjJr8-0006RH-1r; Tue, 15 Jan 2019 09:13:55 +0100 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 39F7C6540089; Tue, 15 Jan 2019 09:13:48 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id C96AB56DBCC4; Tue, 15 Jan 2019 09:13:47 +0100 (CET) X-CTCH-RefID: str=0001.0A0B020F.5C3D9643.0071, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Ben Campbell Cc: draft-ietf-cellar-ebml.all@ietf.org, cellar@ietf.org In-reply-to: <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> Date: Tue, 15 Jan 2019 09:13:47 +0100 Message-ID: <87h8eae3t0.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 08:14:06 -0000 Hey, thanks for your work, Ben. I intended to work on the points & a thorough reply but was a bit overwhelmed by the amount of them (not so much by what you wrote as most points you brought up seemed uncontroversial and easy to fix for me) and short on time. It's still on my TODO list. Kind regards, mosu From nobody Thu Jan 17 07:05:54 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E411294FA for ; Thu, 17 Jan 2019 07:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com 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 5Bo51_eIq2Tu for ; Thu, 17 Jan 2019 07:05:51 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 7B9B5128CB7 for ; Thu, 17 Jan 2019 07:05:51 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id v13so11390114wrw.5 for ; Thu, 17 Jan 2019 07:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=7cLzB51w54ONsMl6NmD1hY+lBGzxe0wb8qza6256RPE=; b=OkQzTZFV3RaNYBH9/cF9B/Ge7KDK9dxz8RkzRbE3ZoXqgMMW5ZZPbNGqCmc+ELNbFE R87MSx3pu0mZ/icjM2gUyPi29rfzd823QuXt0uBjsmC1iY24raastRGSlwFiyn3ORk1X LPnsztN1k0AQ+od61y2wJ14LnWwiyFBwaq0HZweuZHWR7kdklmInlZHKj1GWgw3hEjpk 1iUHErsD1Ti1qr83NzpGWi7lJ0buvlVIkeH2ri1qgHSi6ZKsJ6wJ1WuIkuObWsb4L8v1 0aPKRX79Vt2RFuO793pye8Bpboz34v6eAoy1JWAkiwqubWd9BORxkAE84rOxiWF4Nx5D /Czg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7cLzB51w54ONsMl6NmD1hY+lBGzxe0wb8qza6256RPE=; b=dZnp9BG3LlbO5RBuG/VDW7G4E+CYoW0WvISPzJBxC+11XqcyyxsB7/I0QgDJlv85wK zzAisZ90/wkbW8/Y9lBI1hx2Yysay6HLz36Xy/qKwAM36ttI2KcpJJWbvihOKj3xuwFU t6JRT9grDqZc1lEPwD8W/QxQNM/4vTXxkLSORqdW29JmEdObgqCK7YEC6pXI+5NDCQqS 0pIOzqPKa2g1st1dBP/F0QHv98cfR9A0m4zAdd/3xxduAfN2Qhir8o7WumK1LpuQlK0m fjZ42Ni6xauxvi/I84UJljnvVeD9mF8MfGiTaSstkA2gdck1QD2UxdTXEsEfEObvlK+V ifuA== X-Gm-Message-State: AJcUukdJpXv/bfhgjsL4MbFXRICT5XP8NZ8xKyorx4ObaL0568Q36SSY dxF45dJw98ZBTz60ruAKSHX0VGYxXA8= X-Google-Smtp-Source: ALg8bN6wM7TZL1v7+ciRSc6Oo8JYAJKktAwyhDUN0KjiLRUZKN3SsqSXuJEbcTa/XK7EAeMSf4gg1g== X-Received: by 2002:a5d:6850:: with SMTP id o16mr12701805wrw.123.1547737549294; Thu, 17 Jan 2019 07:05:49 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id m193sm43864136wmb.26.2019.01.17.07.05.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jan 2019 07:05:48 -0800 (PST) To: cellar@ietf.org References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> <5590C374-8505-4E4F-995D-2F779C830C24@nostrum.com> <87h8eae3t0.fsf@bunkus.org> From: Steve Lhomme Message-ID: Date: Thu, 17 Jan 2019 16:05:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <87h8eae3t0.fsf@bunkus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 15:05:54 -0000 Same for me. I'll try to get some time during the weekend. On 15/01/2019 09:13, Moritz Bunkus wrote: > Hey, > > thanks for your work, Ben. I intended to work on the points & a thorough > reply but was a bit overwhelmed by the amount of them (not so much by what > you wrote as most points you brought up seemed uncontroversial and easy to > fix for me) and short on time. It's still on my TODO list. > > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Thu Jan 17 09:49:07 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050B3130ECD for ; Thu, 17 Jan 2019 09:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=iSFLjlr5; dkim=pass (2048-bit key) header.d=gmail.com header.b=P5E9v2dU 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 KY5u8UEWUgSB for ; Thu, 17 Jan 2019 09:49:03 -0800 (PST) Received: from mail-qt1-x84a.google.com (mail-qt1-x84a.google.com [IPv6:2607:f8b0:4864:20::84a]) (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 1C9F2130EB5 for ; Thu, 17 Jan 2019 09:49:03 -0800 (PST) Received: by mail-qt1-x84a.google.com with SMTP id w18so9644021qts.8 for ; Thu, 17 Jan 2019 09:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=fNtbC7YWfD+6RfhqmfnuGFZu5VAzdfFyUqttjLX8XVM=; b=iSFLjlr509JVWBFqYhHWnMtu1HoFs2Pl7GGVp/GiDE5Zpb41N8RImPCDv1oCpW2d/Z RY8V+2FnBZBiqVUKpWHKMUQLAmyXNCWlq0lUcMQmbZhyqSsKfqxHk8ugiOTnIWF11zio wHQTTz5Nl9JHn/H75IR+Di+fXM/UJEQB9NfDk/YLaI1X+x8HOJqMVAFVy+I2mF1KuknU 5xZhUE1nZJFtE0auf7bnyyavfRHkBhCCiH1ugFRbjZvHlimfuWQ+tDi9EzffzfTtvKYj bgFUGlasNDwwORAIXp+3Pc5hw6/DeTFQrJht4htClG7Y0kUAzRd+LAuzNb3YFlnggxMF +eWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=fNtbC7YWfD+6RfhqmfnuGFZu5VAzdfFyUqttjLX8XVM=; b=P5E9v2dUnxzgEJy7q0/S+949aJPUmqsgUGYnwLr9G4D3yKBCYud3O4lk6OOrzZSz7x nmWBiwizie6nkx44SNTbWWZWjcQyqSKq4UUgfzj6iqflMFwuyPLDJf0fZR+BkxCx4GeU VF6QBdzUDIbNzXr7fGjQhHSkd85LxAqGAPjUdNvKdZZPj73dQC/+kocEXrwQqdmDSiUf mDaWGwuFT4s6GlH+V7PQuYM3jyCkvdGJ21oIuFlxh8huyG9pbhsWE3Dxt35z7pcgacBh +VGC81Cwqk1ZUoMF8SuDIGHVzSqce8HT2Ql86kluCkpB+rVLuTUapP7ILlr60wWFjFCH U18A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:message-id:date :subject:from:to; bh=fNtbC7YWfD+6RfhqmfnuGFZu5VAzdfFyUqttjLX8XVM=; b=bDXBP4rMr/iXyi5DkXmJAtjz6kbGxDXr/6IPBbLTSGZPqrdvuEI6BpWhoEyvgMgxhW QQ2sDbNRqW7vi94Ga2q1ItSVeYa08KloMJGWe+ZIb58FwQORqJ4rd4D3KRJ/YrqI1NCZ XBTzX7Hy5AAy1gujcepcDl+vQaTic5F5Bl0vykALnglqMpvPORODVh8SiWuIIO8Dceze McJlg8OrvdXy6l5Big+FIBr1Rh7A0itOkT5NI1qrz2C+I7xkOMF4gCLgtiuHvgNbo0hK 37kAge9AYjO2qqsy+g+4G8EzDbJtHPrwwF8jnckrT4Mvf/3iwIqhQuEFlcmX8bIh248I eRXA== X-Gm-Message-State: AJcUukcND4LY5wmHvNdHB0S7o7pWuT2xjco7CemSJmLuWMDHhLIyj8LW ocX6Hgvwyss5mHMjDpuLRUzjqJ5jr4cze2yS4ig= X-Google-Smtp-Source: ALg8bN5VfR3zkBFxxaF7dAcTrfs/Y6GDQvA3qpIBhBYWwMDwllxbDvUeJ+L4s2pAt+CPPf4YxGPxEii9JVZVwPLHWyqb MIME-Version: 1.0 X-Received: by 2002:ae9:df41:: with SMTP id t62mr8331304qkf.59.1547747341912; Thu, 17 Jan 2019 09:49:01 -0800 (PST) Reply-To: mcharlesr@gmail.com Sender: Google Calendar Message-ID: <0000000000008451b5057fab02f3@google.com> Date: Thu, 17 Jan 2019 17:49:01 +0000 From: Michael Richardson To: cellar@ietf.org, tterriberry@mozilla.com Content-Type: multipart/mixed; boundary="000000000000845191057fab02f2" Archived-At: Subject: [Cellar] Invitation: cellar-interim @ Monthly from 15:00 to 16:30 on the last Tuesday from Tue 2019-01-29 to Tue 2019-06-25 (EST) (cellar@ietf.org) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 17:49:06 -0000 --000000000000845191057fab02f2 Content-Type: multipart/alternative; boundary="00000000000084518c057fab02f0" --00000000000084518c057fab02f0 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes You have been invited to the following event. Title: cellar-interim JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m7b0a6e8d394a8310c3d98a728b1918fe Meeting number (access code): 313 505 170 Host key: 763872 Meeting password: dq64cWsm JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting. When: Monthly from 15:00 to 16:30 on the last Tuesday from Tue 2019-01-29 to Tue 2019-06-25 Eastern Time - Toronto Where: https://ietf.webex.com/ietf Calendar: cellar@ietf.org Who: * Michael Richardson - organizer * cellar@ietf.org * tterriberry@mozilla.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=N3FwMmR2b3VqMXBxdGF1NnU1ZWlpMGVqdHEgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbWM2Mjk3ZGRiODA2MTRlM2NlNWE3YTgxM2E4OTFkZjE5YWU5MjJjZjg&ctz=America%2FToronto&hl=en&es=0 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cellar@ietf.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding --00000000000084518c057fab02f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= tr>

= cellar-interim

When
Monthly from 15:00 to 16:30 on t= he last Tuesday from Tue 2019-01-29 to Tue 2019-06-25 Eastern Time - Toronto
Where
https://ietf.webex.com= /ietf (map)
Calendar
cellar@ietf.org
Who
&#= x2022;
<= div style=3D"margin:0 0 0.3em 0">Michael Richardson - organizer
•
cellar@ietf.org
=
•
tterriberry@mozilla.com=

JOIN WEBEX MEETING
https://ietf.webex.com/= ietf/j.php?MTID=3Dm7b0a6e8d394a8310c3d98a728b1918fe
Meeting number (= access code): 313 505 170
Host key: 763872
Meeting password: dq64cWsm=

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/= Canada)
1-650-479-3208 Call-in toll number (US/Canada)

Toll-free = dialing restrictions:
https://www.webex.com/pdf/tollfree_restrictions.pdf

=

Can't join the meeting? Contact support here:
https://ietf.webex.com/ietf/mc


IMPORTANT NOTI= CE: Please note that this WebEx service allows audio and other information = sent during the session to be recorded, which may be discoverable in a lega= l matter. You should inform all meeting attendees prior to recording if you= intend to record the meeting.

Going (cellar@ietf.org)?   All e= vents in this series:   Yes - Maybe - No<= /a>    more options »

Invitation from Google Calendar

You ar= e receiving this courtesy email at the account cellar@ietf.org because you = are an attendee of this event.

To stop receiving future updates for t= his event, decline this event. Alternatively you can sign up for a Google a= ccount at https://www.google.com/calendar/ and control your notification se= ttings for your entire calendar.

Forwarding this invitation could all= ow any recipient to modify your RSVP response. Learn More.

--00000000000084518c057fab02f0 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20190129T200000Z DTEND:20190129T213000Z RRULE:FREQ=MONTHLY;UNTIL=20190625T235959Z;BYDAY=-1TU DTSTAMP:20190117T174901Z ORGANIZER;CN=Michael Richardson:mailto:mcharlesr@gmail.com UID:7qp2dvouj1pqtau6u5eii0ejtq@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=cellar@ietf.org;X-NUM-GUESTS=0:mailto:cellar@ietf.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=tterriberry@mozilla.com;X-NUM-GUESTS=0:mailto:tterriberry@mozilla.c om ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Michael Richardson;X-NUM-GUESTS=0:mailto:mcharlesr@gmail.com CLASS:PUBLIC CREATED:20190117T174720Z DESCRIPTION:\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID= m7b0a6e8d394a8310c3d98a728b1918fe\nMeeting number (access code): 313 505 17 0\nHost key: 763872\nMeeting password: dq64cWsm\n\n\n\nJOIN BY PHONE\n1-877 -668-4493 Call-in toll free number (US/Canada) \n1-650-479-3208 Call-in tol l number (US/Canada)\n\nToll-free dialing restrictions: \nhttps://www.webex .com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join the meeting? Contact s upport here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded\, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting.\n\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the description.\n\nView your event at https://www.google.com/calendar/even t?action=VIEW&eid=N3FwMmR2b3VqMXBxdGF1NnU1ZWlpMGVqdHEgY2VsbGFyQGlldGYub3Jn& tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbWM2Mjk3ZGRiODA2MTRlM2NlNWE3YTgxM2E4OTFkZjE 5YWU5MjJjZjg&ctz=America%2FToronto&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20190117T174901Z LOCATION:https://ietf.webex.com/ietf SEQUENCE:2 STATUS:CONFIRMED SUMMARY:cellar-interim TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H10M0S END:VALARM END:VEVENT END:VCALENDAR --00000000000084518c057fab02f0-- --000000000000845191057fab02f2 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMTkwMTI5VDIwMDAwMFoNCkRURU5EOjIwMTkwMTI5 VDIxMzAwMFoNClJSVUxFOkZSRVE9TU9OVEhMWTtVTlRJTD0yMDE5MDYyNVQyMzU5NTlaO0JZREFZ PS0xVFUNCkRUU1RBTVA6MjAxOTAxMTdUMTc0OTAxWg0KT1JHQU5JWkVSO0NOPU1pY2hhZWwgUmlj aGFyZHNvbjptYWlsdG86bWNoYXJsZXNyQGdtYWlsLmNvbQ0KVUlEOjdxcDJkdm91ajFwcXRhdTZ1 NWVpaTBlanRxQGdvb2dsZS5jb20NCkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVR LVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPQ0KIFRSVUU7Q049Y2VsbGFy QGlldGYub3JnO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpjZWxsYXJAaWV0Zi5vcmcNCkFUVEVOREVF O0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFD VElPTjtSU1ZQPQ0KIFRSVUU7Q049dHRlcnJpYmVycnlAbW96aWxsYS5jb207WC1OVU0tR1VFU1RT PTA6bWFpbHRvOnR0ZXJyaWJlcnJ5QG1vemlsbGEuYw0KIG9tDQpBVFRFTkRFRTtDVVRZUEU9SU5E SVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1BQ0NFUFRFRDtSU1ZQPVRSVUUN CiA7Q049TWljaGFlbCBSaWNoYXJkc29uO1gtTlVNLUdVRVNUUz0wOm1haWx0bzptY2hhcmxlc3JA Z21haWwuY29tDQpDTEFTUzpQVUJMSUMNCkNSRUFURUQ6MjAxOTAxMTdUMTc0NzIwWg0KREVTQ1JJ UFRJT046XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9DQogbTdiMGE2ZThkMzk0YTgzMTBjM2Q5OGE3MjhiMTkxOGZlXG5NZWV0aW5n IG51bWJlciAoYWNjZXNzIGNvZGUpOiAzMTMgNTA1IDE3DQogMFxuSG9zdCBrZXk6IDc2Mzg3Mlxu TWVldGluZyBwYXNzd29yZDogZHE2NGNXc21cblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtODc3DQog LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBcbjEtNjUwLTQ3 OS0zMjA4IENhbGwtaW4gdG9sDQogbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuVG9sbC1mcmVlIGRp YWxpbmcgcmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8vd3d3LndlYmV4DQogLmNvbS9wZGYvdG9sbGZy ZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFj dCBzDQogdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5J TVBPUlRBTlQgTk9USUNFOiBQbGVhc2UgDQogbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nDQogIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkXCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2Fs IG1hdHRlci4gDQogWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9y IHRvIHJlY29yZGluZyBpZiB5b3UgaW50ZW5kIHRvDQogIHJlY29yZCB0aGUgbWVldGluZy5cblxu XG4tOjp+On46On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+DQogOn46 fjp+On46fjp+On46fjp+On46fjp+On46fjp+Ojp+On46Oi1cblBsZWFzZSBkbyBub3QgZWRpdCB0 aGlzIHNlY3Rpb24gb2YgDQogdGhlIGRlc2NyaXB0aW9uLlxuXG5WaWV3IHlvdXIgZXZlbnQgYXQg aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jYWxlbmRhci9ldmVuDQogdD9hY3Rpb249VklFVyZlaWQ9 TjNGd01tUjJiM1ZxTVhCeGRHRjFOblUxWldscE1HVnFkSEVnWTJWc2JHRnlRR2xsZEdZdWIzSm4m DQogdG9rPU1Ua2piV05vWVhKc1pYTnlRR2R0WVdsc0xtTnZiV00yTWprM1pHUmlPREEyTVRSbE0y TmxOV0UzWVRneE0yRTRPVEZrWmpFDQogNVlXVTVNakpqWmpnJmN0ej1BbWVyaWNhJTJGVG9yb250 byZobD1lbiZlcz0xLlxuLTo6fjp+Ojp+On46fjp+On46fjp+On46fjp+DQogOn46fjp+On46fjp+ On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjo6fjp+OjotDQpMQVNULU1P RElGSUVEOjIwMTkwMTE3VDE3NDkwMVoNCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zg0KU0VRVUVOQ0U6Mg0KU1RBVFVTOkNPTkZJUk1FRA0KU1VNTUFSWTpjZWxsYXItaW50ZXJp bQ0KVFJBTlNQOk9QQVFVRQ0KQkVHSU46VkFMQVJNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJ T046VGhpcyBpcyBhbiBldmVudCByZW1pbmRlcg0KVFJJR0dFUjotUDBEVDBIMTBNMFMNCkVORDpW QUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --000000000000845191057fab02f2-- From nobody Thu Jan 17 09:58:34 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A4D130EBC for ; Thu, 17 Jan 2019 09:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=Kpu7b+JY; dkim=pass (2048-bit key) header.d=gmail.com header.b=ORJwU68L 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 TP2JS9xpZ6-G for ; Thu, 17 Jan 2019 09:58:30 -0800 (PST) Received: from mail-qk1-x749.google.com (mail-qk1-x749.google.com [IPv6:2607:f8b0:4864:20::749]) (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 CA5BE12426E for ; Thu, 17 Jan 2019 09:58:29 -0800 (PST) Received: by mail-qk1-x749.google.com with SMTP id a199so9008190qkb.23 for ; Thu, 17 Jan 2019 09:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=YYMYwX2jkfvo9NTVgdu7DfrNVZulHTbmwtfzkgZwv+g=; b=Kpu7b+JYao9z/vaTgRiimPX/udzuwC1oAYBes/GmAbBzgGEqK8FMlIz+QaKdYmv5zG nBlOIVH7JsqTiaQ1wxuAFhE3glFPujIleS2RPEOo77b2PBWWNmZwh4f9feHNViJSYe+B gyoHvHzBDLAHCtnRgG7FitoLVVb/Yuy2yzZPls40SXnGFTcLURzFeXXxzie7xxypxWS9 zFx3NMoclVgqc2MXah6pDg5lKTaVqiOHil+a8py46YQm8UTebVguTKZ++TtGa3TZzq6F UnfTUsRx6yo6qBLG6V5wxp0jfbz4Ymb0k/43mdnyo3Pk8FBTKdjLq7TkKCjLTGQl0gjS N2Sw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=YYMYwX2jkfvo9NTVgdu7DfrNVZulHTbmwtfzkgZwv+g=; b=ORJwU68LwOmOVOS8+syFoOILvhztSFJjLOI+DBZOI4Is+rH1pyhxg/izQuquLHIiHx tpIYo7zlV1JBJRo2tK8jmXAV8km6h/9DESga9CQjnNhtCWrP32TtWT694Wr7+dK/hHh/ U77KvtmB26V44D+NRpOJhuDKGDNfjSlFL0QHIDGvyERCXjR+JUyxBdNVx9teLCeZkH81 K01M1ZOyblpzBjkNwvsHI8q00/BGk4k4TiiCPp5LUNkVkpOFQfhTTTdvbIt+2DSZYkkY 4gok2xV9+JNVPgncuWggdgZ9gvCfb6JZCc/sKZJUrW4QQFl//p8gqTsfcwM3zMLfBRAp xpBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:message-id:date :subject:from:to; bh=YYMYwX2jkfvo9NTVgdu7DfrNVZulHTbmwtfzkgZwv+g=; b=Vnpx+WJSZ114FGTRHpZcrD0Q004yr5QDpKlWTqrnRw855ifoUln401YJuQrT8LvrVo gas1ObcJ3oZQ5zpBFM2AQHAxDJ+WDEPT+1ZpMC+m9vAmhz+2MwfdqipwZwbe36SK5HYh S6I5o08F7aZxslNVcoJECOY1m663TK/AxVDSxxssgpIuV0w6ud3JUxe5+wYDsPDfsUo8 lkI+8PrcwIpdWLq0XY6Bg9ZyAsXpNvBw2lH+bnnAX+zrLE9rJqfDQe+mXq93RIp4re0V exwmxuAdSnmtpnwUdkkOklidqGo04bPmSUdulXiCrMtaMuFnSgd8NITJv8db1+R3YwgA MygA== X-Gm-Message-State: AJcUukd16wN6SSQUv7OQsClaLS16u+hiQUzzzx29+F7QEbo1jOVCOy3C e4HdkZkDJnrQeGi92MkOhJM4KJgMcU0vP7TDPvo= X-Google-Smtp-Source: ALg8bN6giSa+Eelnc8h47Rs1S181mAthkinWX2vCmihv8VsvbP9tMvJQAmqmmGg3frBkPLwXsNHfMkJmMNY8PsZJz153 MIME-Version: 1.0 X-Received: by 2002:a37:654f:: with SMTP id z76mr8245583qkb.61.1547747908679; Thu, 17 Jan 2019 09:58:28 -0800 (PST) Reply-To: mcharlesr@gmail.com Sender: Google Calendar Message-ID: <0000000000004c83db057fab24c7@google.com> Date: Thu, 17 Jan 2019 17:58:28 +0000 From: Michael Richardson To: cellar@ietf.org, tterriberry@mozilla.com Content-Type: multipart/mixed; boundary="0000000000004c83c1057fab24c6" Archived-At: Subject: [Cellar] Invitation: cellar-interim @ Tue 2019-04-02 16:00 - 17:30 (EDT) (cellar@ietf.org) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 17:58:33 -0000 --0000000000004c83c1057fab24c6 Content-Type: multipart/alternative; boundary="0000000000004c83be057fab24c4" --0000000000004c83be057fab24c4 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBj ZWxsYXItaW50ZXJpbQ0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvY2VsbGFy L21lZXRpbmdzLw0KV2hlbjogVHVlIDIwMTktMDQtMDIgMTY6MDAg4oCTIDE3OjMwIEVhc3Rlcm4g VGltZSAtIFRvcm9udG8NCldoZXJlOiBodHRwczovL2FwcGVhci5pbi9jZWxsYXItaW50ZXJpbQ0K Q2FsZW5kYXI6IGNlbGxhckBpZXRmLm9yZw0KV2hvOg0KICAgICAqIE1pY2hhZWwgUmljaGFyZHNv biAtIG9yZ2FuaXplcg0KICAgICAqIGNlbGxhckBpZXRmLm9yZw0KICAgICAqIHR0ZXJyaWJlcnJ5 QG1vemlsbGEuY29tDQoNCkV2ZW50IGRldGFpbHM6ICANCmh0dHBzOi8vd3d3Lmdvb2dsZS5jb20v Y2FsZW5kYXIvZXZlbnQ/YWN0aW9uPVZJRVcmZWlkPU5tVXlNak0wYzIwMGFYUTJiV3RzYzJobk5E TnJNalptT1dzZ1kyVnNiR0Z5UUdsbGRHWXViM0puJnRvaz1NVGtqYldOb1lYSnNaWE55UUdkdFlX bHNMbU52YlRSak5EYzJZekkzWXpKaFl6aG1NREF3Wm1ReE1EUmlZbVZpWkRRMVkySTRZVEUxTUdS ak5EUSZjdHo9QW1lcmljYSUyRlRvcm9udG8maGw9ZW4mZXM9MA0KDQpJbnZpdGF0aW9uIGZyb20g R29vZ2xlIENhbGVuZGFyOiBodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyLw0KDQpZb3Ug YXJlIHJlY2VpdmluZyB0aGlzIGNvdXJ0ZXN5IGVtYWlsIGF0IHRoZSBhY2NvdW50IGNlbGxhckBp ZXRmLm9yZyAgDQpiZWNhdXNlIHlvdSBhcmUgYW4gYXR0ZW5kZWUgb2YgdGhpcyBldmVudC4NCg0K VG8gc3RvcCByZWNlaXZpbmcgZnV0dXJlIHVwZGF0ZXMgZm9yIHRoaXMgZXZlbnQsIGRlY2xpbmUg dGhpcyBldmVudC4gIA0KQWx0ZXJuYXRpdmVseSB5b3UgY2FuIHNpZ24gdXAgZm9yIGEgR29vZ2xl IGFjY291bnQgYXQgIA0KaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jYWxlbmRhci8gYW5kIGNvbnRy b2wgeW91ciBub3RpZmljYXRpb24gc2V0dGluZ3MgZm9yICANCnlvdXIgZW50aXJlIGNhbGVuZGFy Lg0KDQpGb3J3YXJkaW5nIHRoaXMgaW52aXRhdGlvbiBjb3VsZCBhbGxvdyBhbnkgcmVjaXBpZW50 IHRvIG1vZGlmeSB5b3VyIFJTVlAgIA0KcmVzcG9uc2UuIExlYXJuIG1vcmUgYXQgIA0KaHR0cHM6 Ly9zdXBwb3J0Lmdvb2dsZS5jb20vY2FsZW5kYXIvYW5zd2VyLzM3MTM1I2ZvcndhcmRpbmcNCg== --0000000000004c83be057fab24c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= tr>

= cellar-interim

When
Tue 2019-04-02 16:00 =E2=80=93 1= 7:30 Eastern Time - Toronto
Where
https://appear.in/cellar-interim (map)
Calenda= r
cellar@ietf.org
Who
•
Michael Richardson - or= ganizer
cellar@ietf.org
•
tterriberry@mozilla.com

Going (c= ellar@ietf.org)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

Y= ou are receiving this courtesy email at the account cellar@ietf.org because= you are an attendee of this event.

To stop receiving future updates = for this event, decline this event. Alternatively you can sign up for a Goo= gle account at https://www.google.com/calendar/ and control your notificati= on settings for your entire calendar.

Forwarding this invitation coul= d allow any recipient to modify your RSVP response. Learn More.

 --0000000000004c83be057fab24c4 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20190402T200000Z DTEND:20190402T213000Z DTSTAMP:20190117T175828Z ORGANIZER;CN=Michael Richardson:mailto:mcharlesr@gmail.com UID:6e2234sm4it6mklshg43k26f9k@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=cellar@ietf.org;X-NUM-GUESTS=0:mailto:cellar@ietf.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=tterriberry@mozilla.com;X-NUM-GUESTS=0:mailto:tterriberry@mozilla.c om ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Michael Richardson;X-NUM-GUESTS=0:mailto:mcharlesr@gmail.com CLASS:PUBLIC CREATED:20190117T175827Z DESCRIPTION:\n\nhttps://datatracker.ietf.org/wg/cellar/meetings/ \n\n-::~: ~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: :~:~::-\nPlease do not edit this section of the description.\n\nView your e vent at https://www.google.com/calendar/event?action=VIEW&eid=NmUyMjM0c200a XQ2bWtsc2hnNDNrMjZmOWsgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmN vbTRjNDc2YzI3YzJhYzhmMDAwZmQxMDRiYmViZDQ1Y2I4YTE1MGRjNDQ&ctz=America%2FToro nto&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20190117T175827Z LOCATION:https://appear.in/cellar-interim SEQUENCE:0 STATUS:CONFIRMED SUMMARY:cellar-interim TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H10M0S END:VALARM END:VEVENT END:VCALENDAR --0000000000004c83be057fab24c4-- --0000000000004c83c1057fab24c6 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMTkwNDAyVDIwMDAwMFoNCkRURU5EOjIwMTkwNDAy VDIxMzAwMFoNCkRUU1RBTVA6MjAxOTAxMTdUMTc1ODI4Wg0KT1JHQU5JWkVSO0NOPU1pY2hhZWwg UmljaGFyZHNvbjptYWlsdG86bWNoYXJsZXNyQGdtYWlsLmNvbQ0KVUlEOjZlMjIzNHNtNGl0Nm1r bHNoZzQzazI2ZjlrQGdvb2dsZS5jb20NCkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9 UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPQ0KIFRSVUU7Q049Y2Vs bGFyQGlldGYub3JnO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpjZWxsYXJAaWV0Zi5vcmcNCkFUVEVO REVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURT LUFDVElPTjtSU1ZQPQ0KIFRSVUU7Q049dHRlcnJpYmVycnlAbW96aWxsYS5jb207WC1OVU0tR1VF U1RTPTA6bWFpbHRvOnR0ZXJyaWJlcnJ5QG1vemlsbGEuYw0KIG9tDQpBVFRFTkRFRTtDVVRZUEU9 SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1BQ0NFUFRFRDtSU1ZQPVRS VUUNCiA7Q049TWljaGFlbCBSaWNoYXJkc29uO1gtTlVNLUdVRVNUUz0wOm1haWx0bzptY2hhcmxl c3JAZ21haWwuY29tDQpDTEFTUzpQVUJMSUMNCkNSRUFURUQ6MjAxOTAxMTdUMTc1ODI3Wg0KREVT Q1JJUFRJT046XG5cbmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvY2VsbGFyL21lZXRp bmdzLyAgXG5cbi06On46DQogfjo6fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46 fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46DQogOn46fjo6LVxuUGxlYXNlIGRv IG5vdCBlZGl0IHRoaXMgc2VjdGlvbiBvZiB0aGUgZGVzY3JpcHRpb24uXG5cblZpZXcgeW91ciBl DQogdmVudCBhdCBodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1W SUVXJmVpZD1ObVV5TWpNMGMyMDBhDQogWFEyYld0c2MyaG5ORE5yTWpabU9Xc2dZMlZzYkdGeVFH bGxkR1l1YjNKbiZ0b2s9TVRramJXTm9ZWEpzWlhOeVFHZHRZV2xzTG1ODQogdmJUUmpORGMyWXpJ M1l6SmhZemhtTURBd1ptUXhNRFJpWW1WaVpEUTFZMkk0WVRFMU1HUmpORFEmY3R6PUFtZXJpY2El MkZUb3JvDQogbnRvJmhsPWVuJmVzPTEuXG4tOjp+On46On46fjp+On46fjp+On46fjp+On46fjp+ On46fjp+On46fjp+On46fjp+On46fjp+On46DQogfjp+On46fjp+On46fjp+On46fjp+Ojp+On46 Oi0NCkxBU1QtTU9ESUZJRUQ6MjAxOTAxMTdUMTc1ODI3Wg0KTE9DQVRJT046aHR0cHM6Ly9hcHBl YXIuaW4vY2VsbGFyLWludGVyaW0NClNFUVVFTkNFOjANClNUQVRVUzpDT05GSVJNRUQNClNVTU1B Ulk6Y2VsbGFyLWludGVyaW0NClRSQU5TUDpPUEFRVUUNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJ U1BMQVkNCkRFU0NSSVBUSU9OOlRoaXMgaXMgYW4gZXZlbnQgcmVtaW5kZXINClRSSUdHRVI6LVAw RFQwSDEwTTBTDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --0000000000004c83c1057fab24c6-- From nobody Thu Jan 17 10:00:09 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C6130F73 for ; Thu, 17 Jan 2019 09:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Op5hezx6vuEz for ; Thu, 17 Jan 2019 09:59:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88AE130F07 for ; Thu, 17 Jan 2019 09:59:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A8D93808A; Thu, 17 Jan 2019 12:59:17 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 85314CA3; Thu, 17 Jan 2019 12:59:55 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 82BA9CA1; Thu, 17 Jan 2019 12:59:55 -0500 (EST) From: Michael Richardson To: cellar@ietf.org cc: Ben Campbell X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] upcoming virtual meeting for CELLAR --- reminders X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 18:00:07 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 1) January 29 at 20:00 UTC (15:00 EST) 2) February 26 at 20:00 UTC (15:00 EST) 3) March 26 -> April 2. This is during the IETF week. I was going to suggest that we attempt to have a regular session at IETF104, and use meetecho. The plan was to ask for a session on Tuesday afternoon, which would be morning for EST people, and during the work-day for Europeans. If we couldn't get that slot, then we'd defer that meeting by a week to April 2. 4) PROPOSED meeting April 30 5) PROPOSED meeting May 28. 6) PROPOSED meeting June 24 7) No meeting in July Looking at *MY* schedule, I will need to do other things on Tuesday afternoon while at IETF104. (Can't say I'm happy about the conflict) So I will go directly to the backup plan of moving the virtual interim From=20March 26 to April 2. As per the discussion last time and the experiment, we will *NOT* use webex for these meetings, but rather https://appear.in/cellar-interim This accomodates up to 12 people (I have a premium account), and we have typically not had more than about 7-8 people attend. Ben, do I have your approval? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxAwpsACgkQgItw+93Q 3WUKXAf9EhtNjBhXHdrFlzmSOHv++U3dNaEBciGHzAcd0BculblT5riowKC4Wf+r by6xtXvlkcHGZ/NvD/nKUiQqOa0LPBNNTwR6/C+2cKiq9O2atQHTNDunlOrgRWu3 PI9JOnhupd6KObAHNXnXyZy266EECKTQ3y2YaCMKWz2z1M1YoaAdhy4yOKmMBeij UPvbP/yYZz/yVGSJaxy1lTdtZJ+08YccAkVFX6u3wzsnqbPc5tc23VjunE3PWHUg wz/hOtMLX8PdSyf9Tn70Hdh1/iu4MkTfl85St5daLHEaZMBr/i2hJNXxrhR/68BW XI3BJNBv2CCtTgM4ndCMcL50/wNJ4Q== =e9NW -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jan 19 01:30:11 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3AB12F1AB for ; Sat, 19 Jan 2019 01:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com 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 qSDzYijduy7a for ; Sat, 19 Jan 2019 01:30:07 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 60FCD12E043 for ; Sat, 19 Jan 2019 01:30:07 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id r24so2596419wmh.0 for ; Sat, 19 Jan 2019 01:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=VcxIbuU4LeWpuHuu0R6Z7JZ1sGlO3hI2xBWVpG5jZC8=; b=ajp0UuLGF8VU5h73MvxVeOz33tbFbA7Bz7aMK+/efl76cU9JnmtvvG+SVb5i38JnoS NIf6gs94r1EPDzWfq29bvaPg/X7DvgPid97L+ruPeYCFMh2VoMLvZHAgQs9kWtsWMpxV X/gyGMVi5n7Mo3iVQTm3JlPztllS3HT9cStyU93C2bavDjGpG6dijmHDA5maNC7mZsgH tFugme7jbFMjWJeYUBeoQ+ZVyToOmp+/dRAdu7r3Cvs43GBA4q57k2q24PBX49ADZqnP KtHX7gM1UsC3fKrLA0RE2N8jF7IKoa0NVXuVJcoxEMfjkt5Vj7Pcmu6LXo+S7bBs6hoO keqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=VcxIbuU4LeWpuHuu0R6Z7JZ1sGlO3hI2xBWVpG5jZC8=; b=sqLS5bDJrgrAy05iLbPyHpGugKJX9xxQX8jA8+J+vsR7wktxE4grNwnizv62pLrwAZ LTgC65wNI9ftsDkrOsplMjpyTQZ/MvfWh+sgJ9FrpAAt65RBmi6OSM5z5sJF3uWpjq2s vAisCEENfetJWjdOHax3OJGmXB1OBZISfcZcplORt2E9PHOhR6pHcKJofywfuRkZACry 5wTbhQVTlFpPHEwlGs5wBR9E53b2Mex99Ain7CNu+9dDQogl56mkRbroW8lXVzKQt9iK 2lA2YzZvIOCbeyA4k4LltIIJY3dzY3wk43fw2DFY1noAbxBvO5rMgfBmTK84UwFzo25D /T1g== X-Gm-Message-State: AJcUukffJqChpCVcJrND3bprtikepr6FBoL5BaRlyklCoUtaqkpLD9OM RgABcyIrzqjaYIoArP9WKT88aG6PNfA= X-Google-Smtp-Source: ALg8bN6LsAdoHT7VJbdOHnKx84qjT2U9mPRD2W9SjyMgHyEC0LKNT6ICgHx5au9U4Ox3aDgRwLhblg== X-Received: by 2002:a1c:d74a:: with SMTP id o71mr18441211wmg.73.1547890205208; Sat, 19 Jan 2019 01:30:05 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id n82sm44520196wma.42.2019.01.19.01.30.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jan 2019 01:30:04 -0800 (PST) To: cellar@ietf.org References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> From: Steve Lhomme Message-ID: <2c4399b6-69e1-d21d-a58d-972eb035a66c@matroska.org> Date: Sat, 19 Jan 2019 10:30:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 09:30:09 -0000 Hi Ben, On 07/01/2019 22:14, Ben Campbell wrote: > Hi, > > This is my AD Evaluation of draft-ietf-cellar-ebml-08. > > Thanks for this work. It's generally on the right track, but I have a number of comments that I would like to discuss prior progressing. > > Thanks! > > Ben. > > *** Substantive Comments *** > > - The Shepherd Report says "There are minor nits to be resolved (adding one RFC 2119 keyword and some schema attributes which are mentioned but not defined." > > Do that comment still apply? To be clear, those are more than nits. Adding a 2119 keyword is substantive change that needs to be agreed to but the working group. I don't understand this. RFC2119 has been mentioned in the header and a link is generated at the bottom of the document since 2016. I don't think we should include the whole document, so what is missing ? > Undefined attributes suggest that the draft is incomplete. If the comment is still accurate, then these need to be fixed prior to progressing the draft. If it is not accurate, then I ask the shepherd to please update the shepherd report. Which attributes are mentioned but not defined ? All the "attribute" mentions I see in the text are all attributes described further in their own section. > > - I'm a little surprised to see the draft describe EBML as a general purpose markup language format, as opposed to one designed to be used by Matroska and similar technologies. I suspect others will also be surprised during the IETF LC and IESG review. The review bar is higher for the IETF to recommend EBML as a general purpose markup language than it is to recommend it for specific purposes. I also note that the CELLAR charter talks about EBML in terms of being used by Matroska and FFV1. It's actually not used in FFV1, only Matroska. But we are aware of other people using EBML for other purposes/formats and some considering to use it. > Would it be acceptable to add some scoping language to the effect of "EBML is used by Matroska[citation] and FFV1[citation]. It MAY be used for use cases similar to those. The applicability of EBML for other use cases is beyond the scope of this document". Yes, (apart from the FFV1 part). Done in this PR https://github.com/Matroska-Org/ebml-specification/pull/199 > > - There are several defined elements/attributes related to versioning, but I don't find an explanation of how they all work together. Please add a section describing versioning in general. Done in PR https://github.com/Matroska-Org/ebml-specification/pull/200 > > §2: Please use the newer boilerplate from RFC 8174. Done in PR https://github.com/Matroska-Org/ebml-specification/pull/201 > > §3: Can you offer guidance on the specific impacts of the mentioned attacks, and how to mitigate them? (If there is no way to mitigate an attack, it's okay to say that.) Partially covered by https://github.com/Matroska-Org/ebml-specification/pull/202 I'm not sure how to mitigate side channels errors, or rather if we have to go in deep details for each (it could go very deep on all kinds of security things). > > §5: Please elaborate on how this is similar to UTF8. I assume this refers to using prefix bits to indicate the field length. UTF8 does that to maintain backwards compatibility with Ascii. What is the design motivation for using that approach for EBML, which I presume doesn't have such a requirement? Done in https://github.com/Matroska-Org/ebml-specification/pull/203 > > §5.3: "If the number of bits required for "VINT_DATA" > are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be > zero-padded to the left to a size that fits." > > Why not MUST? What happens if this is violated? Done in https://github.com/Matroska-Org/ebml-specification/pull/204 I'll try to continue with the rest ASAP Thanks a lot for all your comments. From nobody Thu Jan 24 06:25:08 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17534123FFD; Thu, 24 Jan 2019 06:25:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154833990104.25162.4585028307774235557@ietfa.amsl.com> Date: Thu, 24 Jan 2019 06:25:01 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-09.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 14:25:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-09.txt Pages : 43 Date : 2019-01-24 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-09 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-09 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 24 09:14:38 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F60A127598; Thu, 24 Jan 2019 09:14:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, cellar@ietf.org, cellar-chairs@ietf.org, mcr+ietf@sandelman.ca X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154835007651.29384.14639289725815082463.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2019 09:14:36 -0800 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 104 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 17:14:37 -0000 Michael Richardson, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 104. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Sun Jan 27 07:31:32 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3798912F295 for ; Sun, 27 Jan 2019 07:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com 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 3BhjnPt3KFiX for ; Sun, 27 Jan 2019 07:31:28 -0800 (PST) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 63711130DD6 for ; Sun, 27 Jan 2019 07:31:28 -0800 (PST) Received: by mail-pl1-x641.google.com with SMTP id 101so6634181pld.6 for ; Sun, 27 Jan 2019 07:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pxs/O1no46ItkbU/5lsMOBHp53wnyUYZziYugGvgkk4=; b=piHHGF7K0ikY32D/tyJV2Rinp3nlGZ02+af3BjkjaVeVFW4wGjmOX3wxKPyTwE91yD Ytn4D7IJ0BlRvNdM08+pfugvlh0YegABuOYDGS4NovAkuxDkF79+TNjXF9evDohCIW8f V9z1nxLrlQAbIGDI2yEAexm6iJtguN6NUcnZylhxC5zFL1ZQZpjLnJ2KkHHXfTLIpSrb wAjWeqQKqZNGfkGzaftsV/x+9ZyCFfNg6X6MpByfNqqMmO0d0gvixUp+e30pQCtWXxo2 Ltyg70TxGKjsG98u4BPALwrHQdYVe7jbvPSbqZQxCRolORXyxFJV/LM2Zu3mg3pBfye8 7dNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pxs/O1no46ItkbU/5lsMOBHp53wnyUYZziYugGvgkk4=; b=uZfjZdQr/GtEnRmKv2aWpPjGDDFdboPViZyFoMKicQNNChh1mWR8fVNsz0vnkYabFU DFDypeHVXu305h8twLK+fd8Ia/vRgaNlRcoafWC16aAD98SXVsvhGS14oNEROTFn4ydX 9YwV+aW9UGdEi6nMwlMNQbi3SbCrdEpy33yotQWm7PF967GVOGrY+4gro5t7YSBwwJuw utCJNGKC5BW1Q+nSwY+vvmfHU0PMRWM6vSUzcoS3FXatnAYk//9rSTow0b4dXZoDo8U+ zW8lck7Nint8jYwCjuD/nJlHWdOjmlHPwQOGNJZhCuAp6FhTxpLqbAH78t/XsVjjUYJU 7Ofg== X-Gm-Message-State: AJcUukfxeHpcOwnVuj9sT9R5ZjeK8QJM+jPFs4H2/AUrtf/1XH41AiDo r/ctJmcO/6MHnnyeDf4O6JAO9zlqQ8GYWR1lZSUhgQ== X-Google-Smtp-Source: ALg8bN6fLSHbKBI1iGjIIN7CV3uuiNe5B5mJAOx0qyY6Hz3WzskeuyQMvOmVArw6/UbQaciCwhm368Fgy5jC2KDzbYk= X-Received: by 2002:a17:902:9047:: with SMTP id w7mr18660718plz.270.1548603087670; Sun, 27 Jan 2019 07:31:27 -0800 (PST) MIME-Version: 1.0 References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> In-Reply-To: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> From: Steve Lhomme Date: Sun, 27 Jan 2019 16:31:17 +0100 Message-ID: To: Ben Campbell Cc: draft-ietf-cellar-ebml.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 15:31:31 -0000 Hi,Some more comments on the comments: Le lun. 7 janv. 2019 =C3=A0 22:15, Ben Campbell a =C3=A9c= rit : >>> Hi, >> This is my AD Evaluation of draft-ietf-cellar-ebml-08. >> Thanks for this work. It's generally on the right track, but I have a nu= mber of comments that I would like to discuss prior progressing. >> Thanks! >> Ben. >> *** Substantive Comments *** >> =C2=A76: > - "The "VINT_DATA" component of the "Element ID" MUST > NOT be either defined or written as either all zero values or all one > values." > Why? There is no technical reason why these values can't be used. For example VINT_DATA all set to 0 is valid for the Element Size (and all ones has a special meaning). These are rather reserved values that may help expand EBML one day if necessary. Should we call them reserved rather than invalid ? > =C2=A78.7: "In this case, the "EBML Reader" should skip data > until a valid..." > Should that be a normative statement? If so, why should and not MUST? It can't be a MUST if we tolerate values to be there, someone might want to make use of these data. It could also be data that have been damaged and don't appear as EBML Elements anymore. In that case the reader should do its best to skip over these data. In any case the behaviour of the reader when such data is found not normative. > =C2=A78.8: If the EBML reader does not interpret Binary Elements, why add= them at all? What does interpret them? is the point that the EBML reader t= reats Binary Elements as opaque, and just hands them to the application? Yes, it's exactly that. Binary is a blob that is unknown to the EBML Reader. Only an app that knows the particular Element in the DocType can interpret what is in this blob. > =C2=A710.1.3: "NOT RECOMMENDED" seems overly strong, especially in light = of the MAY in the first paragraph. Is the point to say "MUST NOT... except = when the implementation needs to update an element without rewriting the en= tire document"? The MAY means zeros can be added after a string, but one shouldn't do that.The NOT RECOMMENDED also says that it shouldn't be used unless you know what you're doing (the definition of NOT RECOMMENDED).Should we rephrase the paragraph ? Saying that use Null terminated should not be used in general but must be handled by a Reader because it's a possibility ? > =C2=A711: "An "EBML Document" consists of "EBML Elements" and MUST > NOT contain any data that is not part of an "EBML Element"." >> That contradicts text in =C2=A78.7 that says you can do this in streamin= g use cases. Correct, it should be SHOULD NOT rather than MUST NOT. See Pull Request #212https://github.com/Matroska-Org/ebml-specification/pull/212 > =C2=A713.1: "The "DocType" > value for an "EBML Document Type" SHOULD be unique and persistent." >> What is the scope of uniqueness? How should it be achieved? Is there an = expectation to register Document Types? (Also, why not MUST)? There is a IANA registry and it MUST be unique (see 15.2 CELLAR EBML DocType Registry), although if people use the same separately string separately without going through IANA registration, it's possible they won't be unique. That being said I think it should be a MUST. See Pull Request #213https://github.com/Matroska-Org/ebml-specification/pul= l/213 > =C2=A713.1.4.1: Are there uniqueness requirements for name? No, it's a human readable name that's only there for readability. I never ends up in the actual EBML data. The same name could be found in different path for example. > =C2=A713.1.4.2: > - The idea behind "path" needs elaboration. I'd like to see some high-lev= el discussion of how you indicate where an element is allowed, and how you = encode the structure. I don't understand what you mean. > An example (local to the section) would be helpful. Added in Pull Request #214 https://github.com/Matroska-Org/ebml-specification/pull/214 > =C2=A713.1.4.4: > - "The "minOccurs" value MUST be > equal to the "EBMLMinOccurrence" value of the "path"." >> Why have both if they have to be the same? (Same question for =C2=A713.1= .4.5) EBMLMinOccurrence is just a coded name in the path definition. It's not found in the path itself. Whereas minOccurs is found in the XML Schema describing the format.The former has a long name to make it clearer what it does in this context. The latter has a short name to be more readable and is always found in its context anyway. > =C2=A713.1.4.12: > - "If the "recurring" attribute > is not present then the "EBML Element" MUST be considered to NOT be > an "Identically Recurring Element"." >> "be considered to" is vague for a MUST. What concrete action must implem= entations take in this case? Fixed by https://github.com/Matroska-Org/ebml-specification/commit/45497f5e= d9d9d4f0fe206c69431fd0f39be3dbd4 > =C2=A713.1.6.2: > - It seems likely readers will confuse "type" with "data type". Would it = be reasonable to call this "document-type" or something similar? I renamed it to "purpose" in Pull Request #215 https://github.com/Matroska-Org/ebml-specification/pull/215 > =C2=A713.1.10: > - Please state (and cite) which XML schema format is used here. >> - Has the schema been mechanically verified? I'm not competent on that one (I suppose Dave or Jerome have used it ?) > =C2=A713.3.1: > - "The CRC value MUST be computed on a little > endian bitstream and MUST use little endian storage." >> Please elaborate. Most elements have been big-endian so far. Do there ha= ve to be converted to calculate the CRC? The EBML headers and integers are in Big Endian. But the Binary data can be anything. For convenience with modern CPUs the CRC-32 is done on little endian reading of the EBML header+data and stored as such.I can't access the ISO spec, but the ITU one doesn't mention anything about endianess. > =C2=A715.1: > - "The numbers 0x3FFF and 0x4000 are RESERVED.", "The numbers 0x1FFFFF an= d 0x200000 are RESERVED.", and "The numbers 0xFFFFFFF and 0x1000000 are RES= ERVED." > What is the purpose of reserving them? The answer can be found here https://github.com/Matroska-Org/ebml-specification/pull/179#discussion_r196= 481366 There are invalid values, but that's not a word used for IANA registration. Should we mention that they are invalid anyway ? > - "Four octet Element IDs whose lower three octets (as > encoded) would make printable 7-bit ASCII values may be allocated > only Specification Required." > > Can you state a range or a list? Don't make IANA judge which values are p= rintable. Done in Pull Request 216 https://github.com/Matroska-Org/ebml-specification/pull/216 > =C2=A715.2: > - "The strings may be allocated according to > First Come First Served" > > Is there a requirement to register them, or is this optional? We can't force people to do it, but it's encouraged. From nobody Sun Jan 27 07:49:06 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58CB130E46 for ; Sun, 27 Jan 2019 07:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com 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 lCEqSo85TkM4 for ; Sun, 27 Jan 2019 07:49:03 -0800 (PST) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 EF55F130E3F for ; Sun, 27 Jan 2019 07:49:02 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id r136so6880262pfc.6 for ; Sun, 27 Jan 2019 07:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8kLPEQB2J5F28X96ch70jZDUngdK0iEjH/Qpe/94Yp8=; b=ugCiMqR+mzcLlaNn4KEv8d1Mz9D5N1vqeickOrstpWuZleJGoK6mNOPHoU3LHY5x0c YPd7Lhij7zuCJJHJHh9P5v21JyDZs4eOslDBYfn8hcY51xdJXNTp5XOwzaLvzzSWjqSF h8xrG9uaWOsBvpK3PHNjb5ALpLwQrIwnAiNglPcEh+qy8sZhX7ofriI9EfMbrHBWfr/B 6O/9XRRzNqEVzqjLULfLkMFZhNCZiWzizRYTT2eOPSw3H39BCT4ITLAtDR1loFYs1uc4 Ov31mSNvC2T2ac7dKrs2rmnZ8UOw2NzJebRulVy43hci73fKVrakyLE6LN1+ev1ZR2nk MPow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8kLPEQB2J5F28X96ch70jZDUngdK0iEjH/Qpe/94Yp8=; b=ojR6D4OkX+JyJa7gpLUw6b/yXsPKc4rnIHtCBm/RMyA6jgyckUr79UbMPHoSBa+fyM sJ5JZPwZC9kDJVYc6BdwDbNU86eKpRrrQQbnqgMssqvBCeQp5gP7WlBBdiHXosOkGYp8 WymW/hCobT7ILOTjVDC6Sx8wRFDii08mfwcv07RqHojmqxrZyvXQWP6zboS49qJDxH24 YRRYTwuPzDuDwqitcQDmLzS/0ConE9kghN77ocI4RPT6dXCQ8i9dS+jGXWzFSd7EZL/h BQw+spz4uIr54x0Red1OasMeTbj8fj1PnGxwAQMuagHXAVe0yUqB+Jonguz+hz1+twnD rPug== X-Gm-Message-State: AJcUukdXCqrHqTYqpLJYuumCkmdSBAYcfFGLJaN+18bRs9g2XAogIjpg GJUdNQmfkCjFFhD7yCHMJL32Fh6LXyLMkcXBkymC0HAdIFE= X-Google-Smtp-Source: ALg8bN4L437AAG0cN804O8SEHtbkOdWau+MdvXF8LPzuS2XgeklOKSMPkcUoKm6w3NsCBgS8khK6ZNeHCWnUYnZ4e98= X-Received: by 2002:a63:5320:: with SMTP id h32mr16788895pgb.414.1548604141784; Sun, 27 Jan 2019 07:49:01 -0800 (PST) MIME-Version: 1.0 References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> In-Reply-To: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> From: Steve Lhomme Date: Sun, 27 Jan 2019 16:48:50 +0100 Message-ID: To: Ben Campbell Cc: draft-ietf-cellar-ebml.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 15:49:05 -0000 More: Le lun. 7 janv. 2019 =C3=A0 22:15, Ben Campbell a =C3=A9c= rit : > *** Editorial Comments and Nits *** > > - General: The draft puts double quotes around every mention of terms tha= t it defines. That is unconventional for IETF documents. I personally find = that it makes the draft harder to read. I suggest quoting them on the first= mention, then just capitalizing them in subsequent mentions. I suppose you don't mean full capital letters ? The idea is that if you read a particular section and not the whole document you can still understand what is internal terms or generic names. > =C2=A711.1: > - Is the concept of a file concrete (in the sense of a unit of persistent= storage) or abstract (as in any stream of data)? I had assumed the latter,= but with the different rules about data outside of EBML elements for "file= s" and "streaming applications", I am not so sure. If you mean "file" concr= etely, does there need to be additional text in this section describing the= structure for streaming applications? It's more of an abstract thing. When we mention streaming it's some kind of reading where you can't seek forward (and only backward is there's a cache). But in general the storage itself doesn't matter. > =C2=A713.4.1.2: > - "The "EBMLElementOccurrence" part is interpreted as an ABNF Variable > Repetition. > > I don't understand what that means. There won't be ABNF in an actual sche= ma, will there? (Same for "VariableParentOccurrence") The path is in the Schema and is interpreted as ABNF > - ""EBML Elements" with "EBMLMinOccurrence" set to "1" that also have a > "default" value (see Section 13.1.4.8) declared are not REQUIRED to > be stored but are REQUIRED to be interpreted," > > Statement of fact? It is normative, if that's what you mean. Even if such element is not found in the data, it must be considered to be there and used with the default value. > =C2=A713.1.4.7 > - The attribute is called "size" but defined to be "length". Why not call= it length? (Or describe it as "size")? That must be for historical reasons. I'm fine with renaming it to length since that's the term we use everywhere else. See Pull Request #217 https://github.com/Matroska-Org/ebml-specification/pull/217 From nobody Sun Jan 27 15:48:06 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05D130F40 for ; Sun, 27 Jan 2019 15:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Jc6AIrEGyqPt for ; Sun, 27 Jan 2019 15:47:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48DE130F2C for ; Sun, 27 Jan 2019 15:47:55 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 938EA38265 for ; Sun, 27 Jan 2019 18:47:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AA310DB0; Sun, 27 Jan 2019 18:47:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A8E21CA6 for ; Sun, 27 Jan 2019 18:47:54 -0500 (EST) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] DRAFT AGENDA 2019-01-29 20:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 23:48:04 -0000 --=-=-= Content-Type: text/plain CELLAR -- DRAFT AGENDA for Virtual Interim Meeting January 29, 2019 20:00 UTC DRAFT MINUTES FROM 2018-12-18 meeting will be posted as soon as I find them and/or etherpad is fixed. INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-01/session/cellar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-01-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. Proposed Agenda: 1. Note Well. 2. Accept draft minutes from December meeting 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) 2c) Roll call 4. WG status update - EBML is now in IESG publication queue. - work on Matroska and FFV1 issues!! - confirm list of dates for meetings: 2019-01-29 2019-02-26 2019-04-02 *NEW DATE* 5. Dave Rice on updates to EBML to address AD comments. 6. Steve LHome on Matroska document changes since last meeting. 7. WG plans for advancing documents. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxOQyoACgkQgItw+93Q 3WXPtAf/TtZYhKPW7wvQCVyYhJ1MVtolAfOiEOGZl9TL4rH1BFtcuzHAohlvqOJd s5Popzp8bZsQsdCK1hHAH8mEF8DM3qscQcl0n1TslMfXY88KKgCpKKlW5sG2EpL/ dh2lCQWAKdYWC2f2uOYAeSU8I49Qz4H2Md1cQ9ga/TKqtPU29yNyRo1UA6fWcgIx W5BDScwXumepwiDK+Ta9p3Rz6p6oqfX5xBoAjJKnWj4QszupcQPag0KqfQTXFG+O XWGFqvvH6/c4Oyl1ZZhBxYnCXLH5WZLy5Nw1iAgjxAjm++HCjb+x/7U/V+cSX9ai QHGYqDavk7X4IfI/BSe33KBNcHVN1w== =cXbg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 28 07:19:59 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98250129A87 for ; Mon, 28 Jan 2019 07:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 V8FuzszTD01X for ; Mon, 28 Jan 2019 07:19:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1056127598 for ; Mon, 28 Jan 2019 07:19:54 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AD8938265 for ; Mon, 28 Jan 2019 10:18:59 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8AD6D249F; Mon, 28 Jan 2019 10:19:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 897A12364 for ; Mon, 28 Jan 2019 10:19:53 -0500 (EST) From: Michael Richardson to: cellar@ietf.org In-Reply-To: <2827.1548632874@localhost> References: <2827.1548632874@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] DRAFT AGENDA 2019-01-29 20:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 15:19:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable CELLAR -- DRAFT AGENDA for Virtual Interim Meeting January 29, 2019 20:00 UTC DRAFT MINUTES FROM 2018-12-18 are attached at the end. INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-01/session/ce= llar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-01-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. Proposed Agenda: 1. Note Well. 2. Accept draft minutes from December meeting 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceF= ont=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) 2c) Roll call 4. WG status update - EBML is now in IESG publication queue. - work on Matroska and FFV1 issues!! - confirm list of dates for meetings: 2019-01-29 2019-02-26 2019-04-02 *NEW DATE* 5. Dave Rice on updates to EBML to address AD comments. 6. Steve LHome on Matroska document changes since last meeting. 7. WG plans for advancing documents. =3D=3D=3D=3D=3D CELLAR -- Agenda for Virtual Interim Meeting December 18, 2018 20:00 UTC INFO: https://datatracker.ietf.org/meeting/interim-2018-cellar-04/session= /cellar WEBEX: https://ietf.webex.com/ietf/j.php?MTID=3Dme21026faa14be85507cdef66b= 860014e Attendees: * Michael Richardson * J=C3=A9r=C3=B4me Martinez * Martin Below * Dave Rice (as call-in user) * Tim Terriberry * Steve Lhomme * Missing: Regrets: * Moritz Bunkus * Reto Kromer * Michael Niedermayer Agenda: 1. Note Well. https://www.ietf.org/about/note-well/ Proposed Agenda: 1. Note Well. 2. Accept draft minutes from September meeting https://datatracker.ietf.org/meeting/interim-2018-cellar-05/materials/minu= tes-interim-2018-cellar-05-201809252000 taken as written. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual04?useMonospac= eFont=3Dtrue 2b) Roll call c) March meeting in March 26. 20:00 UTC. Preference to meetecho... webr= tc based. 21:00 UTC. 4. WG status update - EBML is now in IESG publication queue. Thx to Steven Villereal for the= shepherd writeup. Shepherd writeup: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebm= l/shepherdwriteup/ - work on Matroska and FFV1 issues!! Preview of xml2rfc v3 for FFV1 is at https://htmlpreview.github.io/?http= s://gist.githubusercontent.com/dericed/5ce9c949eeec9042a4ac5e2b222f1cc0/raw= /b315b8d3f5c4b06ecf656fc1fb7e9ad9bd6fd88c/draft-ietf-cellar-ffv1-06.html. - confirm list of dates for meetings: 2019-01-29 2019-02-26 2019-03-26 5. https://github.com/FFmpeg/FFV1/issues (without a version): - new v0,1,3 was posted in September, are there still issues with v1? - Jerome still has to work to do on 0,1,3 version. - https://github.com/FFmpeg/FFV1/pull/100 new feature for v3. Could be= an extension done later on? - https://github.com/FFmpeg/FFV1/pull/111 CRITICAL PATH. Jerome. - hoping to get into WGLC by mid-January. 6. https://github.com/Matroska-Org/matroska-specification/issues - what new issues? - 29 issues open. - draft-ietf-cellar-tags-00 - draft-ietf-cellar-codec-00 - draft-ietf-cellar-matroska-01 (165 pages. Maybe it could be broken u= p further) 7. Any other Business. https://appear.in/cellar-interim We have Tim, Steve, MCR, Jerome, Marti= n,... Dave missing. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxPHZkACgkQgItw+93Q 3WXMKQf/areiTM8vPiKiBa0VbF2SnqrhEAu9G/adznbu8fSbJGbP+z/6yjkcQ9NY vG+HNVpa8P0+U3BKPWn0V6MYKUhzzddjb0SzInOs4DRZsjMAnH7f/569gxZY+2u1 0Uk5wEvT+oGySL1ZF+StwO82B6Nk7aW3JnDS5YUJ2jp+r6V1AeYqCnqpx4wKAeOU yGf0oKhcTzPHua2z8Yi2fgOvJGPelzUlrpQAQZqdBI1hJLrlhYUCPyg2GkBdM/jt lOXTNKkSsrkcWUoq2Cyc7VgxMR6814z9qoz7VMJ9CZds+Yta1vAYZIZiJRgAqhp5 pC4+TVZDoAGsPB1k2lUOK1d5VX5E1w== =l1AB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 28 09:58:12 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA8E1310DB for ; Mon, 28 Jan 2019 09:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Y4V_sK8C93C3 for ; Mon, 28 Jan 2019 09:58:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 19FF21310D3 for ; Mon, 28 Jan 2019 09:58:07 -0800 (PST) Received: from [192.168.2.109] ([93.242.166.75]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M3igT-1h5ZYz3LAP-00rD4o for ; Mon, 28 Jan 2019 18:58:05 +0100 To: cellar@ietf.org References: <2827.1548632874@localhost> <7307.1548688793@localhost> From: hubblec4 Message-ID: Date: Mon, 28 Jan 2019 18:58:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <7307.1548688793@localhost> Content-Type: multipart/alternative; boundary="------------E87503F80D2C9B88BC760C45" X-Provags-ID: V03:K1:KpM4F+Nzzni7IiByZ0zC8oB9AXpalZniHWO0Ba6D4seEC5t3pGZ wPg+dvpC4z13/Qd589Rcj2tz0r04SS0IxpwQCUDBT6M+r6fspaD/9zZzfQLmQtcDigIaLV1 gNzHvT3aN3vsaLbtz+6RwMzg5pdRDxVn4JNLlkMh6/Gsoyp0hWPRrVOXQtw3sH8DFg0W8N0 Gg6SvX7hvHLdOsPXp6IxQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:zfziXIAtyZM=:pUAP8LZkFV7tn22LV9Gfld bZ5cmm0h4z7y9Z4tKeuJGzsSJ4yfFi0u6SZAG7b2Iw/ZA3YtphTBJSBLHBasLdXFa3SbMfmqL PhiBmHiaNSRJOf6idjy3LW0DY+FqkIbXoCYxY6injlKFJNl7RZpkswu/fso0d0efpiDkDNa/y aOVkKLhrJ1tib2daSO65/oKofXckKKCmfb9O1UIdF4y/1Bs/EImpf9igRV62tUznjg+b4gDiU 66T247OevB0JtrhGTRtOeLtDmFlC1enV07Ya+EBelcXsd8iPldXz8GzedShjhzX9G0oNxbrjI sipw/EggcDZ7xo5lKGq5cJySCQQkeY1xZ9bPRvRDNbqjzRti4xg2RvgIqPH4COiJOnMfwJYSn iO1cF18boUK8EQy0SnoZoN40jyAWYSrg/ETgzDNra80TlQZwEJ/wlJn9PAbVw6m+YqRP/LgW/ UTEkRV9OtN380Ro7WYDQdATJt5Eu7NxIOQ4nsQdRH6iNqkseJPV4py10TuzXmg2RVHvuDFWFo fAvQTr4JjAc1e+5AEIgZY6Jap5Oixm9LRoNSrCW7KqEStn8zOTMO73vJ6G63Oy8EucHqMONMW XvLwhCT7CZVquxbmijzzw4W86kItHwoMbdB2uybmz57jgysVqOJgOxhajnQ9sYXeFTE4olsWZ B9qjJZqGInjBlhpYTqenYRp5cq84c/H0ssGn32WecllMocQ7MF0lXqfZUvQiUFKyHpMjEsLtn xHpekqGAu05Kh7FGf6Ym3Epg130TDsKjjQkToJIOmWUAbpWMv2W+CQVGxSA75xffqtSmk6hNK jH9JHKT1FZLDC7dnK4TLrsPVfxh5W30kMXkYhncegBBoO1N2e7v1BYMSiggbwGGC4erxv3dsy RTL0SKX3fA4sPSRtQcing0jGuP0R2qgN/dVgH1zltHUkTqNScJwYJTxjJyo9OVt4FGaHlQQOy nwJZdOdJqcw== Archived-At: Subject: Re: [Cellar] DRAFT AGENDA 2019-01-29 20:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 17:58:12 -0000 This is a multi-part message in MIME format. --------------E87503F80D2C9B88BC760C45 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Michael Thanks for this info email. Martin Below Am 28.01.2019 um 16:19 schrieb Michael Richardson: > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > January 29, 2019 20:00 UTC > > DRAFT MINUTES FROM 2018-12-18 are attached at the end. > > INFO: > https://datatracker.ietf.org/meeting/interim-2019-cellar-01/session/cellar > https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-01-sessa/ > > WEB CONFERENCE: > https://appear.in/cellar-interim > THERE IS NO TELEPHONE DIALIN > You can try this at any time. > > Proposed Agenda: > > 1. Note Well. > 2. Accept draft minutes from December meeting > > 3. Logistics for Meeting. > 2a) Etherpad for notes > https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true > > 2b) APPEAR.IN for video and screen sharing. > https://appear.in/cellar-interim > (as agreed last meeting) > > 2c) Roll call > > 4. WG status update > - EBML is now in IESG publication queue. > - work on Matroska and FFV1 issues!! > - confirm list of dates for meetings: > 2019-01-29 > 2019-02-26 > 2019-04-02 *NEW DATE* > > 5. Dave Rice on updates to EBML to address AD comments. > > 6. Steve LHome on Matroska document changes since last meeting. > > 7. WG plans for advancing documents. > > ===== > > CELLAR -- Agenda for Virtual Interim Meeting > December 18, 2018 20:00 UTC > > INFO: > https://datatracker.ietf.org/meeting/interim-2018-cellar-04/session/cellar > > WEBEX: > https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e > > Attendees: > * Michael Richardson > * Jérôme Martinez > * Martin Below > * Dave Rice (as call-in user) > * Tim Terriberry > * Steve Lhomme > * > > Missing: > > Regrets: > * Moritz Bunkus > * Reto Kromer > * Michael Niedermayer > > > > Agenda: > > 1. Note Well. https://www.ietf.org/about/note-well/ > Proposed Agenda: > > 1. Note Well. > > 2. Accept draft minutes from September meeting > https://datatracker.ietf.org/meeting/interim-2018-cellar-05/materials/minutes-interim-2018-cellar-05-201809252000 > taken as written. > > 3. Logistics for Meeting. > 2a) Etherpad for notes > https://etherpad.tools.ietf.org/p/notes-cellar-virtual04?useMonospaceFont=true > > 2b) Roll call > c) March meeting in March 26. 20:00 UTC. Preference to meetecho... webrtc based. > 21:00 UTC. > > 4. WG status update > - EBML is now in IESG publication queue. Thx to Steven Villereal for the shepherd writeup. > Shepherd writeup: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/shepherdwriteup/ > - work on Matroska and FFV1 issues!! > Preview of xml2rfc v3 for FFV1 is at https://htmlpreview.github.io/?https://gist.githubusercontent.com/dericed/5ce9c949eeec9042a4ac5e2b222f1cc0/raw/b315b8d3f5c4b06ecf656fc1fb7e9ad9bd6fd88c/draft-ietf-cellar-ffv1-06.html. > - confirm list of dates for meetings: > 2019-01-29 > 2019-02-26 > 2019-03-26 > > > 5. https://github.com/FFmpeg/FFV1/issues (without a version): > - new v0,1,3 was posted in September, are there still issues with v1? > - Jerome still has to work to do on 0,1,3 version. > - https://github.com/FFmpeg/FFV1/pull/100 new feature for v3. Could be an extension done later on? > - https://github.com/FFmpeg/FFV1/pull/111 CRITICAL PATH. Jerome. > - hoping to get into WGLC by mid-January. > > 6. https://github.com/Matroska-Org/matroska-specification/issues > - what new issues? > - 29 issues open. > - draft-ietf-cellar-tags-00 > - draft-ietf-cellar-codec-00 > - draft-ietf-cellar-matroska-01 (165 pages. Maybe it could be broken up further) > > > 7. Any other Business. > https://appear.in/cellar-interim We have Tim, Steve, MCR, Jerome, Martin,... Dave missing. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------E87503F80D2C9B88BC760C45 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Michael

Thanks for this info email.

Martin Below

Am 28.01.2019 um 16:19 schrieb Michael Richardson:
CELLAR -- DRAFT AGENDA for Virtual Interim Meeting
January 29, 2019        20:00 UTC

   DRAFT MINUTES FROM 2018-12-18 are attached at the end.

INFO:
     https://datatracker.ietf.org/meeting/interim-2019-cellar-01/session/cellar
     https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-01-sessa/

WEB CONFERENCE:
   https://appear.in/cellar-interim
   THERE IS NO TELEPHONE DIALIN
   You can try this at any time.

Proposed Agenda:

1. Note Well.
2. Accept draft minutes from December meeting

3. Logistics for Meeting.
   2a) Etherpad for notes
       https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true

   2b) APPEAR.IN for video and screen sharing.
       https://appear.in/cellar-interim
       (as agreed last meeting)

   2c) Roll call

4. WG status update
   - EBML is now in IESG publication queue.
   - work on Matroska and FFV1 issues!!
   - confirm list of dates for meetings:
       2019-01-29
       2019-02-26
       2019-04-02       *NEW DATE*

5. Dave Rice on updates to EBML to address AD comments.

6. Steve LHome on Matroska document changes since last meeting.

7. WG plans for advancing documents.

=====

CELLAR -- Agenda for Virtual Interim Meeting
December 18, 2018        20:00 UTC

INFO:
        https://datatracker.ietf.org/meeting/interim-2018-cellar-04/session/cellar

WEBEX:
        https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e

Attendees:
	* Michael Richardson
	* Jérôme Martinez
	* Martin Below
	* Dave Rice (as call-in user)
	* Tim Terriberry
	* Steve Lhomme
	* <PLEASE SIGN YOUR NAME HERE>

Missing:

Regrets:
	* Moritz Bunkus
	* Reto Kromer
	* Michael Niedermayer



Agenda:

1. Note Well.    https://www.ietf.org/about/note-well/
Proposed Agenda:

1. Note Well.

2. Accept draft minutes from September meeting
	https://datatracker.ietf.org/meeting/interim-2018-cellar-05/materials/minutes-interim-2018-cellar-05-201809252000
		taken as written.

3. Logistics for Meeting.
   2a) Etherpad for notes
       https://etherpad.tools.ietf.org/p/notes-cellar-virtual04?useMonospaceFont=true

   2b) Roll call
   c) March meeting in March 26. 20:00 UTC.  Preference to meetecho... webrtc based.
      21:00 UTC.

4. WG status update
   - EBML is now in IESG publication queue. Thx to Steven Villereal for the shepherd writeup.
   Shepherd writeup: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/shepherdwriteup/
   - work on Matroska and FFV1 issues!!
   Preview of xml2rfc v3 for FFV1 is at https://htmlpreview.github.io/?https://gist.githubusercontent.com/dericed/5ce9c949eeec9042a4ac5e2b222f1cc0/raw/b315b8d3f5c4b06ecf656fc1fb7e9ad9bd6fd88c/draft-ietf-cellar-ffv1-06.html.
   - confirm list of dates for meetings:
       2019-01-29
       2019-02-26
       2019-03-26


5. https://github.com/FFmpeg/FFV1/issues  (without a version):
   - new v0,1,3 was posted in September, are there still issues with v1?
   - Jerome still has to work to do on 0,1,3 version.
   - https://github.com/FFmpeg/FFV1/pull/100  new feature for v3.  Could be an extension done later on?
   - https://github.com/FFmpeg/FFV1/pull/111  CRITICAL PATH. Jerome.
  - hoping to get into WGLC by mid-January.

6. https://github.com/Matroska-Org/matroska-specification/issues
   - what new issues?
   - 29 issues open.
   - draft-ietf-cellar-tags-00
   - draft-ietf-cellar-codec-00
   - draft-ietf-cellar-matroska-01   (165 pages. Maybe it could be broken up further)


7. Any other Business.
  https://appear.in/cellar-interim   We have Tim, Steve, MCR, Jerome, Martin,... Dave missing.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-


_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
--------------E87503F80D2C9B88BC760C45--