From nobody Wed Jul 3 06:44:31 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 14F421200B4 for ; Wed, 3 Jul 2019 06:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=MTOI0cnM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jncFfazZ 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 3p5n_fK1MBpb for ; Wed, 3 Jul 2019 06:44:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578B6120059 for ; Wed, 3 Jul 2019 06:44:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 70E4621F48 for ; Wed, 3 Jul 2019 09:44:27 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 03 Jul 2019 09:44:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=Dt7NUGUMGE4G3vHCIRtg2kQFzKjFLFsW7/2Hn1Rj1bY=; b=MTOI0cnM 450DQehmg1R/N2aeagrdL9a51y/b/P+4GHCEWA40FGe92t0P1V7qPnnqW59pEEbE U0LHPHQVzVAPn9WU8FqI2caCD1La/P2j3e4od78U5BR0hi+xiKXpvbiuhFb5Lhft yZxd/DfgNntDx/NxpgfzpKfNH7pVt9AMrqNUiDmkIGAJhV1WefEjsh/UZdwMsW2B ySrJkhynTWMB+fUTlzuvRde6fsXk5xBB/zTqydMmM99OHVLnOXBr4oj10sYnE5cW gca3Fth5ny5wvQ5lB0ag0F7eORKW+y+cn4WAhK2pwOtr0rZzq9UV1OuRGGvktlGM So8ykM6ZVceb0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=Dt7NUGUMGE4G3vHCIRtg2kQFzKjFL FsW7/2Hn1Rj1bY=; b=jncFfazZ8lhq/UtYudQknOEs75bLYltqg3l68x6URwEo1 dmyypUUldzoW9fx3umo4iN7KGSKuUSoWXh4TGMV1CkHyYQlJf/puMZr33Cb7TIf0 a/9gfKhe+pwdphbMsE7FmCloEZyFpjnCQ5xg8drJzMoR8Rsk8MEJ/Ut6pHSi+oBR Kpsmi+6J5fTv1NFAzgsDvCbxCzn6OF9sA09H2TBTMCGow/3nBpHvr4ja8P1BtSDH xPY8Lw1AfowyI/S7NcaJBzzGIljZvEZj2SeiHTv6etJMRpVs/Ag/bkqOhB/XhKmi oI691GtnVJmu7GXpf4bcbq01wVyRuxJDYLg77Md0Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrfedtgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhi khhovhesfhgrshhtmhgrihhlrdhfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrg hmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 13C94C200A4; Wed, 3 Jul 2019 09:44:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> Date: Wed, 03 Jul 2019 14:44:07 +0100 From: "Alexey Melnikov" To: cellar@ietf.org Content-Type: text/plain Archived-At: Subject: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 03 Jul 2019 13:44:30 -0000 Hi all, I took over from Ben as the Area Director responsible for this WG. My apologies that my review took so long. Firstly, I am glad that you've implemented changes requested by Ben, as some of them were on my list of issues as well. I have a few comments of my own. Please respond to my review, so that we can collectively figure out what still needs fixing and which parts of the document I just misunderstood. 7. EBML Element Types EBML Elements are defined by an EBML Schema which MUST declare one of I think it would be helpful to readers to include a forward pointer to the section talking about EBML Schema here. the following EBML Element Types for each EBML Element. An EBML Element Type defines a concept of storing data within an EBML Element that describes such characteristics as length, endianness, and definition. 11.1. EBML Schema An EBML Schema is a well-formed XML Document that defines the I think "well-formed XML" needs a normative reference here. properties, arrangement, and usage of EBML Elements that compose a specific EBML Document Type. 11.1.2. Element As an XML Document, the EBML Schema MUST use "" as the top level element. The "" element MAY contain "" sub-elements. RFC 2119 MAY describes an implementation or deployment choice. So the above MAY doesn't seem to be appropriate. I suggest you change it to "can", as this is just a statement of fact. 11.1.5.2. path The path defines the allowed storage locations of the EBML Element within an EBML Document. This path MUST be defined with the full hierarchy of EBML Elements separated with a "/". The top EBML Yet below the ABNF is using \. I think one of these need to be fixed. PathDelimiter = "\" This is supposed to be the same as the above, right? EBMLElementOccurrence = [EBMLMinOccurrence] "*" [EBMLMaxOccurrence] EBMLMinOccurrence = 1*DIGIT EBMLMaxOccurrence = 1*DIGIT Are there any upper limits on allowed values for these fields? Even if you don't encode them using ABNF, it would be good to mention them in an ABNF comment. VariableParentOccurrence = [PathMinOccurrence] "*" [PathMaxOccurrence] PathMinOccurrence = 1*DIGIT PathMaxOccurrence = 1*DIGIT Same comment as above. 11.1.10.1. label The label provides a concise expression for human consumption that describes what the value of the "" represents. Is it worth adding a cross reference to the "lang" attribute here? 11.2.10. DocTypeExtensionName Element description: The name of the DocTypeExtension to identify it from I think the verb "differentiate" might be better than "identify" here. other DocTypeExtension of the same DocType+DocTypeVersion tuple. 12. Considerations for Reading EBML Data If a Master Element contains a CRC-32 Element that doesn't validate, then the EBML Reader MAY ignore all contained data except for Descendant Elements that contain their own valid CRC-32 Element. I don't fully understand your use of "MAY ... except ..." here. Can you elaborate on why would an implementation ignore data contained in a Master Element and not ignore Descendant Elements, even if they own CRC-32 is valid? If a Master Element contains more occurrences of a Child Element that is not a Master Element than permitted according to the maxOccurs attribute of the definition of that Element then all but the instance of that Element with the smallest byte offset from the beginning of its Parent Element SHOULD be ignored. I don't understand what this is is trying to say. If I have a Child Element with minOccurs = 2 and maxOccurs = 3, but the element appears 4 times: what would happen? I think the text above suggest to only use the first instance, which is possibly less than minOccurs. 16. Security Considerations An EBML Reader MAY use the data if it considers it doesn't create any security issue. I don't understand what this is trying to convey and how it can be complied with. Can you elaborate? I suggest just deleting this sentence. 17.1. CELLAR EBML Element ID Registry Four-octet Element IDs are numbers between 0x101FFFFF and 0x1FFFFFFE. Four-octet Element IDs are somewhat special in that they are useful for resynchronizing to major structures in the event of data corruption or loss. As such four-octet Element IDs are split into two categories. Four-octet Element IDs whose lower three octets (as encoded) would make printable 7-bit ASCII values (0x20 to 0x7F) 0x7F character is not considered printable. So I think this should be "(0x20 to 0x7E)". Ideally, you should also clarify that you want the whole range including 0x20 and 0x7E. MUST be allocated by the "Specification Required" policy. 17.2. CELLAR EBML DocType Registry This document creates a new IANA Registry called "CELLAR EBML DocType Registry". DocType values are described in Section 11.1.3.1. DocTypes are ASCII strings, defined in Section 7.4, which label the official name of the EBML Document Type. The strings may be allocated according to the "First Come First Served" policy. I think you need to be clearer on what you expect to appear on IANA's page. Do you expect a reference and/or description field in addition to a DocType name? I suspect you would also need the Change Controller field (who registered the value and can update the description). DocType string values of "matroska" and "webm" are RESERVED to the IETF for future use. These can be assigned via the "IESG Approval" or "RFC Required" policies [RFC8126]. The last sentence is odd, but then I realized that you only reserve these two names and will attempt to assign them separately in the future. I suppose the current text is Ok. Thank you, Alexey From nobody Sat Jul 6 10:22: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 0C15812006E for ; Sat, 6 Jul 2019 10:22:57 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 XUetf7wLMeql for ; Sat, 6 Jul 2019 10:22:54 -0700 (PDT) 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 3293412006D for ; Sat, 6 Jul 2019 10:22:54 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:45341 helo=[10.0.1.29]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hjoOd-0010dd-R1; Sat, 06 Jul 2019 13:22:53 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A7880ECB-CE5D-4E18-B823-DCC1EE7ABFD5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Sat, 6 Jul 2019 13:22:45 -0400 In-Reply-To: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> Cc: cellar@ietf.org To: Alexey Melnikov References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.4 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] Second AD review of draft-ietf-cellar-ebml-10 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, 06 Jul 2019 17:22:57 -0000 --Apple-Mail=_A7880ECB-CE5D-4E18-B823-DCC1EE7ABFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Alexey, Thanks much for providing this thorough review. I=E2=80=99ll try to = reply point by point below with references to either pull requests or = issues or offer followup questions. In a few places I ping Steve Lhomme = and Michael Richardson as the comments relate to text they originated in = their work. > On Jul 3, 2019, at 9:44 AM, Alexey Melnikov = wrote: >=20 > Hi all, > I took over from Ben as the Area Director responsible for this WG. My = apologies that my review took so long. >=20 > Firstly, I am glad that you've implemented changes requested by Ben, = as some of them were on my list of issues as well. I have a few comments = of my own. Please respond to my review, so that we can collectively = figure out what still needs fixing and which parts of the document I = just misunderstood. >=20 > 7. EBML Element Types >=20 > EBML Elements are defined by an EBML Schema which MUST declare one = of >=20 > I think it would be helpful to readers to include a forward pointer to = the section talking about EBML Schema here. >=20 > the following EBML Element Types for each EBML Element. An EBML > Element Type defines a concept of storing data within an EBML = Element > that describes such characteristics as length, endianness, and > definition. Added in https://github.com/cellar-wg/ebml-specification/pull/265 = . > 11.1. EBML Schema >=20 > An EBML Schema is a well-formed XML Document that defines the >=20 > I think "well-formed XML" needs a normative reference here. >=20 > properties, arrangement, and usage of EBML Elements that compose a > specific EBML Document Type. Added to https://github.com/cellar-wg/ebml-specification/pull/265 = . > 11.1.2. Element >=20 > As an XML Document, the EBML Schema MUST use "" as the > top level element. The "" element MAY contain > "" sub-elements. >=20 > RFC 2119 MAY describes an implementation or deployment choice. So the = above MAY doesn't seem to be appropriate. I suggest you change it to = "can", as this is just a statement of fact. Added to https://github.com/cellar-wg/ebml-specification/pull/265 = . > 11.1.5.2. path >=20 > The path defines the allowed storage locations of the EBML Element > within an EBML Document. This path MUST be defined with the full > hierarchy of EBML Elements separated with a "/". The top EBML >=20 > Yet below the ABNF is using \. I think one of these need to be fixed. >=20 > PathDelimiter =3D "\" >=20 > This is supposed to be the same as the above, right? Good catch. Corrected to use \ in both places. Added to = https://github.com/cellar-wg/ebml-specification/pull/265 = . > EBMLElementOccurrence =3D [EBMLMinOccurrence] "*" = [EBMLMaxOccurrence] > EBMLMinOccurrence =3D 1*DIGIT > EBMLMaxOccurrence =3D 1*DIGIT >=20 > Are there any upper limits on allowed values for these fields? Even if = you don't encode them using ABNF, it would be good to mention them in an = ABNF comment. >=20 > VariableParentOccurrence =3D [PathMinOccurrence] "*" = [PathMaxOccurrence] > PathMinOccurrence =3D 1*DIGIT > PathMaxOccurrence =3D 1*DIGIT >=20 > Same comment as above. I looked for examples of that sort of commenting but didn=E2=80=99t find = much guidance. Eventually I simply appended " ; no upper limit=E2=80=9D = to each of the four referenced lines and added that to = https://github.com/cellar-wg/ebml-specification/pull/265 = . > 11.1.10.1. label >=20 > The label provides a concise expression for human consumption that > describes what the value of the "" represents. >=20 > Is it worth adding a cross reference to the "lang" attribute here? Do you mean to express the language of the term used within the label? = Currently the language of the label is undefined and since it is an = attribute that label is not repeatable. > 11.2.10. DocTypeExtensionName Element >=20 > description: The name of the DocTypeExtension to identify it from >=20 > I think the verb "differentiate" might be better than "identify" here. >=20 > other DocTypeExtension of the same DocType+DocTypeVersion tuple. Added to https://github.com/cellar-wg/ebml-specification/pull/265 = . > 12. Considerations for Reading EBML Data >=20 > If a Master Element contains a CRC-32 Element that doesn't validate, > then the EBML Reader MAY ignore all contained data except for > Descendant Elements that contain their own valid CRC-32 Element. >=20 > I don't fully understand your use of "MAY ... except ..." here. > Can you elaborate on why would an implementation ignore data contained = in a Master Element and not ignore Descendant Elements, even if they own = CRC-32 is valid? For instance if a Matroska file has three metadata tags and each has a = CRC value and so does the parent Tags element like this. We=E2=80=99re trying to say that even though the contents of the = element is invalid, that the valid child elements may still be used. An = invalid descendant element would make all ancestor element invalid, but = should not necessary make all sibling elements unusable. > If a Master Element contains more occurrences of a Child Element = that > is not a Master Element than permitted according to the maxOccurs > attribute of the definition of that Element then all but the = instance > of that Element with the smallest byte offset from the beginning of > its Parent Element SHOULD be ignored. >=20 > I don't understand what this is is trying to say. If I have a Child = Element with minOccurs =3D 2 and maxOccurs =3D 3, but the element = appears 4 times: what would happen? I think the text above suggest to = only use the first instance, which is possibly less than minOccurs. Good point, the language presumes that the minOccurs would be <=3D 1. = This needs to be adjusted. Added an issue at = https://github.com/cellar-wg/ebml-specification/issues/266 = . > 16. Security Considerations >=20 > An EBML Reader MAY use the data if it considers it doesn't create = any > security issue. >=20 > I don't understand what this is trying to convey and how it can be = complied with. Can you elaborate? > I suggest just deleting this sentence. Ping to Steve. This line was initially added in = https://github.com/cellar-wg/ebml-specification/commit/640fbb71fb102f73948= 857bd97f7330d237bd5d6 = .=20 Issue added at = https://github.com/cellar-wg/ebml-specification/issues/268 = . > 17.1. CELLAR EBML Element ID Registry >=20 >=20 > Four-octet Element IDs are numbers between 0x101FFFFF and = 0x1FFFFFFE. > Four-octet Element IDs are somewhat special in that they are useful > for resynchronizing to major structures in the event of data > corruption or loss. As such four-octet Element IDs are split into > two categories. Four-octet Element IDs whose lower three octets (as > encoded) would make printable 7-bit ASCII values (0x20 to 0x7F) >=20 > 0x7F character is not considered printable. So I think this should be = "(0x20 to 0x7E)". Ideally, you should also clarify that you want the = whole range including 0x20 and 0x7E. >=20 > MUST > be allocated by the "Specification Required" policy. Adjusted to say "0x20 to 0x7E, inclusive=E2=80=9D. Added to = https://github.com/cellar-wg/ebml-specification/pull/265 = . > 17.2. CELLAR EBML DocType Registry >=20 > This document creates a new IANA Registry called "CELLAR EBML = DocType > Registry". >=20 > DocType values are described in Section 11.1.3.1. DocTypes are = ASCII > strings, defined in Section 7.4, which label the official name of = the > EBML Document Type. The strings may be allocated according to the > "First Come First Served" policy. >=20 > I think you need to be clearer on what you expect to appear on IANA's = page. Do you expect a reference and/or description field in addition to = a DocType name? I suspect you would also need the Change Controller = field (who registered the value and can update the description). >=20 > DocType string values of "matroska" and "webm" are RESERVED to the > IETF for future use. These can be assigned via the "IESG Approval" > or "RFC Required" policies [RFC8126]. >=20 > The last sentence is odd, but then I realized that you only reserve = these two names and will attempt to assign them separately in the = future. I suppose the current text is Ok. Ping to Michael Richardson and Steve. Any comment? Issue filed at = https://github.com/cellar-wg/ebml-specification/issues/267 = . [=E2=80=A6] Thanks again for this helpful review. Kind Regards, Dave Rice --Apple-Mail=_A7880ECB-CE5D-4E18-B823-DCC1EE7ABFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Alexey,

Thanks much = for providing this thorough review. I=E2=80=99ll try to reply point by = point below with references to either pull requests or issues or offer = followup questions. In a few places I ping Steve Lhomme and Michael = Richardson as the comments relate to text they originated in their = work.

On Jul 3, 2019, at 9:44 AM, Alexey Melnikov = <aamelnikov@fastmail.fm> wrote:

Hi = all,
I took over from Ben as the Area Director responsible = for this WG.  My apologies that my review took so long.

Firstly, I am glad that you've implemented = changes requested by Ben, as some of them were on my list of issues as = well. I have a few comments of my own. Please respond to my review, so = that we can collectively figure out what still needs fixing and which = parts of the document I just misunderstood.

7.  EBML Element Types

=   EBML Elements are defined by an EBML Schema which MUST = declare one of

I think it would be helpful = to readers to include a forward pointer to the section talking about = EBML Schema here.

  the = following EBML Element Types for each EBML Element.  An EBML
  Element Type defines a concept of storing data = within an EBML Element
  that describes such = characteristics as length, endianness, and
=   definition.

Added in https://github.com/cellar-wg/ebml-specification/pull/265.
11.1.  EBML Schema

  An EBML Schema is a well-formed XML Document = that defines the

I think "well-formed XML" = needs a normative reference here.

=   properties, arrangement, and usage of EBML Elements that = compose a
  specific EBML Document Type.

Added = to https://github.com/cellar-wg/ebml-specification/pull/265.
11.1.2.  <EBMLSchema> Element

  As an XML Document, the EBML = Schema MUST use "<EBMLSchema>" as the
=   top level element.  The "<EBMLSchema>" element = MAY contain
  "<element>" = sub-elements.

RFC 2119 MAY describes an = implementation or deployment choice. So the above MAY doesn't seem to be = appropriate. I suggest you change it to "can", as this is just a = statement of fact.

Added to https://github.com/cellar-wg/ebml-specification/pull/265.
11.1.5.2.  path

  The path defines the allowed storage locations = of the EBML Element
  within an EBML Document. =  This path MUST be defined with the full
=   hierarchy of EBML Elements separated with a "/".  The = top EBML

Yet below the ABNF is using \. I = think one of these need to be fixed.

= PathDelimiter =            =3D = "\"

This is supposed to be the same as the = above, right?

Good catch. Corrected to use \ in both places. = Added to https://github.com/cellar-wg/ebml-specification/pull/265.
EBMLElementOccurrence    =3D = [EBMLMinOccurrence] "*" [EBMLMaxOccurrence]
= EBMLMinOccurrence        =3D = 1*DIGIT
EBMLMaxOccurrence =        =3D 1*DIGIT

Are there any upper limits on allowed values for these = fields? Even if you don't encode them using ABNF, it would be good to = mention them in an ABNF comment.

= VariableParentOccurrence =3D [PathMinOccurrence] "*" = [PathMaxOccurrence]
PathMinOccurrence =        =3D 1*DIGIT
= PathMaxOccurrence        =3D = 1*DIGIT

Same comment as above.

I = looked for examples of that sort of commenting but didn=E2=80=99t find = much guidance. Eventually I simply appended " ; no upper limit=E2=80=9D= to each of the four referenced lines and added that to https://github.com/cellar-wg/ebml-specification/pull/265.
11.1.10.1.  label

  The label provides a concise expression for = human consumption that
  describes what the = value of the "<enum>" represents.

Is = it worth adding a cross reference to the "lang" attribute here?

Do = you mean to express the language of the term used within the label? = Currently the language of the label is undefined and since it is an = attribute that label is not repeatable.

11.2.10. =  DocTypeExtensionName Element

=   description: The name of the DocTypeExtension to identify it = from

I think the verb "differentiate" might = be better than "identify" here.

=   other DocTypeExtension of the same DocType+DocTypeVersion = tuple.

Added to https://github.com/cellar-wg/ebml-specification/pull/265.
12.  Considerations for Reading EBML = Data

  If a Master Element = contains a CRC-32 Element that doesn't validate,
=   then the EBML Reader MAY ignore all contained data except = for
  Descendant Elements that contain their = own valid CRC-32 Element.

I don't fully = understand your use of "MAY ... except ..." here.
Can you = elaborate on why would an implementation ignore data contained in a = Master Element and not ignore Descendant Elements, even if they own = CRC-32 is valid?

For instance if a Matroska file has three metadata = tags and each has a CRC value and so does the parent Tags element like = this.

<Tags = crc=3Dinvalid>
  <Tag = crc=3Dvalid>
  <Tag crc=3Dvalid>
  = <Tag crc=3Dinvalid>
<Tags>

We=E2=80=99re trying to say that even though the = contents of the <Tags> element is invalid, that the valid child = elements may still be used. An invalid descendant element would make all = ancestor element invalid, but should not necessary make all sibling = elements unusable.

  If a Master = Element contains more occurrences of a Child Element that
=   is not a Master Element than permitted according to the = maxOccurs
  attribute of the definition of that = Element then all but the instance
  of that = Element with the smallest byte offset from the beginning of
=   its Parent Element SHOULD be ignored.

I don't understand what this is is trying to say. If I have a = Child Element with minOccurs =3D 2 and maxOccurs =3D 3, but the element = appears 4 times: what would happen? I think the text above suggest to = only use the first instance, which is possibly less than minOccurs.

Good = point, the language presumes that the minOccurs would be <=3D 1. This = needs to be adjusted. Added an issue at https://github.com/cellar-wg/ebml-specification/issues/266.=

16.  Security Considerations

  An EBML Reader MAY use the data = if it considers it doesn't create any
=   security issue.

I don't = understand what this is trying to convey and how it can be complied = with. Can you elaborate?
I suggest just deleting this = sentence.


17.1.  CELLAR EBML Element ID = Registry


=   Four-octet Element IDs are numbers between 0x101FFFFF and = 0x1FFFFFFE.
  Four-octet Element IDs are = somewhat special in that they are useful
  for = resynchronizing to major structures in the event of data
=   corruption or loss.  As such four-octet Element IDs are = split into
  two categories.  Four-octet = Element IDs whose lower three octets (as
=   encoded) would make printable 7-bit ASCII values (0x20 to = 0x7F)

0x7F character is not considered = printable. So I think this should be "(0x20 to 0x7E)". Ideally, you = should also clarify that you want the whole range including 0x20 and = 0x7E.

  MUST
=   be allocated by the "Specification Required" policy.

Adjusted to say "0x20 to 0x7E, inclusive=E2=80=9D. = Added to https://github.com/cellar-wg/ebml-specification/pull/265.
17.2.  CELLAR EBML DocType Registry

  This document creates a new IANA = Registry called "CELLAR EBML DocType
=   Registry".

  DocType = values are described in Section 11.1.3.1.  DocTypes are ASCII
  strings, defined in Section 7.4, which label the = official name of the
  EBML Document Type. =  The strings may be allocated according to the
=   "First Come First Served" policy.

I think you need to be clearer on what you expect to appear = on IANA's page. Do you expect a reference and/or description field in = addition to a DocType name? I suspect you would also need the Change = Controller field (who registered the value and can update the = description).

  DocType string = values of "matroska" and "webm" are RESERVED to the
=   IETF for future use.  These can be assigned via the = "IESG Approval"
  or "RFC Required" policies = [RFC8126].

The last sentence is odd, but = then I realized that you only reserve these two names and will attempt = to assign them separately in the future. I suppose the current text is = Ok.

Ping to Michael Richardson and Steve. Any comment? Issue = filed at https://github.com/cellar-wg/ebml-specification/issues/267.=

[=E2=80=A6]

Thanks again for = this helpful review.

Kind Regards,
Dave Rice

= --Apple-Mail=_A7880ECB-CE5D-4E18-B823-DCC1EE7ABFD5-- From nobody Thu Jul 11 06:36: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 C9F811200E0 for ; Thu, 11 Jul 2019 06:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=aPTPk/rH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZzyIoka8 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 VmjCZ5sUsN3z for ; Thu, 11 Jul 2019 06:36:11 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02521200FB for ; Thu, 11 Jul 2019 06:36:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id D7B753B5; Thu, 11 Jul 2019 09:36:10 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 11 Jul 2019 09:36:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=mUdVej3RXPimLmCYcB9Yj8vO5fbWtCL Hm/Mr6XnbqEg=; b=aPTPk/rHx3yVlttlnqR1pQPwHANYnGWKGtsyXBPqG8fHu1g xglWkQQwOJSeh7FgwTnM3oS0y9YcSCb11hfgGeLrbuiz37MLzCLqTa0S7sRXrl21 7ol1pr33sVd62OHaYeaZ8UqsQOCEdmpLJCPX6pWx8inEU0yhaqKagpDfY4FiRBOQ 430ubMkyyLDkTptjIRReQ8OckaFHJuBPQv0NWHUfJ9vbqZdluAgSk8pX96gaILzx y11r2WgI2InHegBgGnRVh5mYDungSlt7U1Dre1IHedHriVfghWx+KWGkxAhZXShg q9qlfwrV3dg5lNfZhAqvMpMUQ2CdvXcB8Kh1VjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mUdVej 3RXPimLmCYcB9Yj8vO5fbWtCLHm/Mr6XnbqEg=; b=ZzyIoka8SH7CUMzDoO6g48 zeBFeBmmKOI2Jzw3rVJUpRhyB6XVp7JnOjt5+cO8ZXyL33wk+bRn10NF+uxZlPwv +XY6eJq7k4esQ+vFctb6KY4XujVZcW4xSnBY5yJ8JRsdBFWAY/b9YihznQm/GA8a MOGk9GDw8IXKB3y7NIF6FF1kPKujIJpaVYJ5UxBoh/kT0Z/wQ+y5Edy78V2oGKNb PNBXS9L4wbew3//UQhhT9L0yMi01DfedtNxFn31pRSDUZgnL4MDs1JG+isRSFL0P 8IMLwVfBv3GJqcuuDZ30CQ3vRqrQZiQ4sE8qe5WzVC+ApL4WWqwGD6c2QpXZV8sA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeekgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25783C200A4; Thu, 11 Jul 2019 09:36:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <52b3f63f-fddb-4438-be5f-f61359307f98@www.fastmail.com> In-Reply-To: References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> Date: Thu, 11 Jul 2019 14:36:09 +0100 From: "Alexey Melnikov" To: "Dave Rice" Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary=9f80b438fbfe436e9be397f2b8e0eb8b Archived-At: Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 11 Jul 2019 13:36:15 -0000 --9f80b438fbfe436e9be397f2b8e0eb8b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dave, I removed comments where we are in agreement. A few followups: On Sat, Jul 6, 2019, at 6:23 PM, Dave Rice wrote: > Hello Alexey, >=20 > Thanks much for providing this thorough review. I=E2=80=99ll try to re= ply point by point below with references to either pull requests or issu= es or offer followup questions. In a few places I ping Steve Lhomme and = Michael Richardson as the comments relate to text they originated in the= ir work. >=20 >> EBMLElementOccurrence =3D [EBMLMinOccurrence] "*" [EBMLMaxOccurrence]= >> EBMLMinOccurrence =3D 1*DIGIT >> EBMLMaxOccurrence =3D 1*DIGIT >>=20 >> Are there any upper limits on allowed values for these fields? Even i= f you don't encode them using ABNF, it would be good to mention them in = an ABNF comment. >>=20 >> VariableParentOccurrence =3D [PathMinOccurrence] "*" [PathMaxOccurren= ce] >> PathMinOccurrence =3D 1*DIGIT >> PathMaxOccurrence =3D 1*DIGIT >>=20 >> Same comment as above. >=20 > I looked for examples of that sort of commenting but didn=E2=80=99t fi= nd much guidance. Eventually I simply appended " ; no upper limit=E2=80=9D= to each of the four referenced lines and added that to https://github.c= om/cellar-wg/ebml-specification/pull/265. I think this is the wrong fix. Is it sufficient for an implementation to= use 32 bit value to represent any of these? 64 bit value? "no upper limit" is not going to be interoperable. >=20 >> 11.1.10.1. label >>=20 >> The label provides a concise expression for human consumption that >> describes what the value of the "" represents. >>=20 >> Is it worth adding a cross reference to the "lang" attribute here? >=20 > Do you mean to express the language of the term used within the label?= Currently the language of the label is undefined and since it is an att= ribute that label is not repeatable. To be honest I am not yet sure how I feel about "undefined language" her= e. Need to think about that. But either way, I think adding some text that "lang" attribute doesn't a= pply would be helpful. >=20 >> 12. Considerations for Reading EBML Data >>=20 >> If a Master Element contains a CRC-32 Element that doesn't validate,= >> then the EBML Reader MAY ignore all contained data except for >> Descendant Elements that contain their own valid CRC-32 Element. >>=20 >> I don't fully understand your use of "MAY ... except ..." here. >> Can you elaborate on why would an implementation ignore data containe= d in a Master Element and not ignore Descendant Elements, even if they o= wn CRC-32 is valid? >=20 > For instance if a Matroska file has three metadata tags and each has a= CRC value and so does the parent Tags element like this. >=20 > > > > > >=20 > We=E2=80=99re trying to say that even though the contents of the element is invalid, that the valid child elements may still be used. So to me this means that after discarding all invalid elements you end u= p with something like this: As this is an incomplete document, I am struggling to understand what it= can be used for? > An invalid descendant element would make all ancestor element invalid= , but should not necessary make all sibling elements unusable. >=20 Best Regards, Alexey --9f80b438fbfe436e9be397f2b8e0eb8b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,
I removed comments where we are in agreement. A few followu= ps:

On Sat, Jul 6, 2019, at 6:23 PM, Dave Rice wrote:
Hello Alexey,

Thanks much for providing this th= orough review. I=E2=80=99ll try to reply point by point below with refer= ences to either pull requests or issues or offer followup questions. In = a few places I ping Steve Lhomme and Michael Richardson as the comments = relate to text they originated in their work.

EBMLElementOccurrence    =3D [EBMLMinOccurr= ence] "*" [EBMLMaxOccurrence]
EBMLMinOccurrence  &nbs= p;     =3D 1*DIGIT
EBMLMaxOccurre= nce        =3D 1*DIGIT
=
Are there any upper limits on allowed values for these fi= elds? Even if you don't encode them using ABNF, it would be good to ment= ion them in an ABNF comment.

VariableParent= Occurrence =3D [PathMinOccurrence] "*" [PathMaxOccurrence]
PathMinOccurrence        =3D 1*DIGIT=
PathMaxOccurrence       &nb= sp;=3D 1*DIGIT

Same comment as above.

I looked for examples o= f that sort of commenting but didn=E2=80=99t find much guidance. Eventua= lly I simply appended " ; no upper limit=E2=80=9D to each of the fo= ur referenced lines and added that to https://github.com= /cellar-wg/ebml-specification/pull/265.
I think this is the wrong fix. Is it sufficient for an implem= entation to use 32 bit value to represent any of these? 64 bit value?
"no upper limit" is not going to be interoperable.

<= div>
11.1.10.1.  label

=
  The label provides a concise expression for human consu= mption that
  describes what the value of the "&= lt;enum>" represents.

Is it worth adding= a cross reference to the "lang" attribute here?

Do you mean to express the language of th= e term used within the label? Currently the language of the label is und= efined and since it is an attribute that label is not repeatable.

To be honest I am not ye= t sure how I feel about "undefined language" here. Need to think about t= hat.
But either way, I think adding some text that "lang" attr= ibute doesn't apply would be helpful.


<= div>12.  Considerations for Reading EBML Data

  If a Master Element contains a CRC-32 Element that d= oesn't validate,
  then the EBML Reader MAY igno= re all contained data except for
  Descendant El= ements that contain their own valid CRC-32 Element.

I don't fully understand your use of "MAY ... except ..." here.=
Can you elaborate on why would an implementation ignore d= ata contained in a Master Element and not ignore Descendant Elements, ev= en if they own CRC-32 is valid?
<= br>
For instance if a Matroska file has three metadata tags an= d each has a CRC value and so does the parent Tags element like this.

<Tags crc=3Dinvalid>
&nbs= p; <Tag crc=3Dvalid>
  <Tag crc=3Dvalid><= br>
  <Tag crc=3Dinvalid>
<Tags>= ;

We=E2=80=99re trying to say that even tho= ugh the contents of the <Tags> element is invalid, that the valid = child elements may still be used.
So to me this means that after discarding all invalid elements you end = up with something like this:

<Tags ><= br>
  <Tag crc=3Dvalid>
</Tags>=

As this is an incomplete document, I am st= ruggling to understand what it can be used for?

An invalid= descendant element would make all ancestor element invalid, but should = not necessary make all sibling elements unusable.


Best Regards,
Alexey
--9f80b438fbfe436e9be397f2b8e0eb8b-- From nobody Thu Jul 11 06:54: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 585451200A3 for ; Thu, 11 Jul 2019 06:54:02 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 E23wurKFnv58 for ; Thu, 11 Jul 2019 06:53:59 -0700 (PDT) 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 6AEB01200CD for ; Thu, 11 Jul 2019 06:53:59 -0700 (PDT) Received: from [146.96.19.240] (port=13116 helo=[10.10.201.45]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hlZWD-003oxr-O9; Thu, 11 Jul 2019 09:53:58 -0400 From: Dave Rice Message-Id: <89CEEC4A-78D9-40BF-8A4D-732C7A199F30@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AF05F1A0-7488-43C1-ADF5-5D1DACE7BE3E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 11 Jul 2019 09:53:52 -0400 In-Reply-To: <52b3f63f-fddb-4438-be5f-f61359307f98@www.fastmail.com> Cc: cellar@ietf.org To: Alexey Melnikov References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <52b3f63f-fddb-4438-be5f-f61359307f98@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.4 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] Second AD review of draft-ietf-cellar-ebml-10 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, 11 Jul 2019 13:54:03 -0000 --Apple-Mail=_AF05F1A0-7488-43C1-ADF5-5D1DACE7BE3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 11, 2019, at 9:36 AM, Alexey Melnikov = wrote: >=20 > Hi Dave, > I removed comments where we are in agreement. A few followups: >=20 > On Sat, Jul 6, 2019, at 6:23 PM, Dave Rice wrote: >> Hello Alexey, >>=20 >> Thanks much for providing this thorough review. I=E2=80=99ll try to = reply point by point below with references to either pull requests or = issues or offer followup questions. In a few places I ping Steve Lhomme = and Michael Richardson as the comments relate to text they originated in = their work. >>=20 >>> EBMLElementOccurrence =3D [EBMLMinOccurrence] "*" = [EBMLMaxOccurrence] >>> EBMLMinOccurrence =3D 1*DIGIT >>> EBMLMaxOccurrence =3D 1*DIGIT >>>=20 >>> Are there any upper limits on allowed values for these fields? Even = if you don't encode them using ABNF, it would be good to mention them in = an ABNF comment. >>>=20 >>> VariableParentOccurrence =3D [PathMinOccurrence] "*" = [PathMaxOccurrence] >>> PathMinOccurrence =3D 1*DIGIT >>> PathMaxOccurrence =3D 1*DIGIT >>>=20 >>> Same comment as above. >>=20 >> I looked for examples of that sort of commenting but didn=E2=80=99t = find much guidance. Eventually I simply appended " ; no upper limit=E2=80=9D= to each of the four referenced lines and added that to = https://github.com/cellar-wg/ebml-specification/pull/265 = . > I think this is the wrong fix. Is it sufficient for an implementation = to use 32 bit value to represent any of these? 64 bit value? > "no upper limit" is not going to be interoperable. The smallest possible EBML Element is 2 bytes (1 bytes Element ID, 1 = byte Element Data Size, and 0 bytes of Element Data). The upper limit of = how many occurrences would be determined by the limit of the Element = Data Size of the Parent Element. If the EBML Document has = EBMLMaxSizeLength as the default of 8, then the upper limit of an = Element Data Size is 72,057,594,037,927,934 bytes. Is the smallest = possible Element is 2 bytes, then the upper limit of that Element=E2=80=99= s occurrence would be 72,057,594,037,927,934 divided by two. So if EBMLMaxSizeLength =3D 8, then this is possible # 36,028,797,018,963,967 occurrences but this would overflow the Element Data Size of the Root Element # 36,028,797,018,963,968 occurrences However, EBML allows the EBML Document Type to set an EBMLMaxSizeLength = value higher than 8, and as that is incremented up the upper limit would = expand exponentially. In my draft I would considering "no upper limit=E2=80=9D and = 36,028,797,018,963,967 to effectively be the same or that the definition = does not define the limit but in practice it would be limited by the = capacity of the Element Data Size of the parent Element. >>> 11.1.10.1. label >>>=20 >>> The label provides a concise expression for human consumption that >>> describes what the value of the "" represents. >>>=20 >>> Is it worth adding a cross reference to the "lang" attribute here? >>=20 >> Do you mean to express the language of the term used within the = label? Currently the language of the label is undefined and since it is = an attribute that label is not repeatable. >=20 > To be honest I am not yet sure how I feel about "undefined language" = here. Need to think about that. > But either way, I think adding some text that "lang" attribute doesn't = apply would be helpful. In the case of Matroska, the labels are in English. In the EBML = definition we could say that the labels are in English unless the = definition of that associated EBML Document Type claims otherwise. >>> 12. Considerations for Reading EBML Data >>>=20 >>> If a Master Element contains a CRC-32 Element that doesn't = validate, >>> then the EBML Reader MAY ignore all contained data except for >>> Descendant Elements that contain their own valid CRC-32 Element. >>>=20 >>> I don't fully understand your use of "MAY ... except ..." here. >>> Can you elaborate on why would an implementation ignore data = contained in a Master Element and not ignore Descendant Elements, even = if they own CRC-32 is valid? >>=20 >> For instance if a Matroska file has three metadata tags and each has = a CRC value and so does the parent Tags element like this. >>=20 >> >> >> >> >> >>=20 >> We=E2=80=99re trying to say that even though the contents of the = element is invalid, that the valid child elements may still be = used. > So to me this means that after discarding all invalid elements you end = up with something like this: >=20 > > > >=20 > As this is an incomplete document, I am struggling to understand what = it can be used for? In that case, the valid Tags are still useful even if within a parent = element whos contents are invalid. Perhaps another example would be in = the Attachments Element: Poster Art Subtitle Font Here some bit damage occurs to the Poster Art so the Attachment and its = parent Attachments now have invalid crcs, however the subtitle font is = still ok and could be used in the presentation without an issue. >> An invalid descendant element would make all ancestor element = invalid, but should not necessary make all sibling elements unusable. >>=20 >=20 > Best Regards, > Alexey > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = --Apple-Mail=_AF05F1A0-7488-43C1-ADF5-5D1DACE7BE3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 11, 2019, at 9:36 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi = Dave,
I removed comments where we are in = agreement. A few followups:

On Sat, Jul 6, 2019, at 6:23 = PM, Dave Rice wrote:
Hello Alexey,

Thanks much for = providing this thorough review. I=E2=80=99ll try to reply point by point = below with references to either pull requests or issues or offer = followup questions. In a few places I ping Steve Lhomme and Michael = Richardson as the comments relate to text they originated in their = work.

EBMLElementOccurrence =    =3D [EBMLMinOccurrence] "*" [EBMLMaxOccurrence]
EBMLMinOccurrence =        =3D 1*DIGIT
EBMLMaxOccurrence =        =3D 1*DIGIT

Are = there any upper limits on allowed values for these fields? Even if you = don't encode them using ABNF, it would be good to mention them in an = ABNF comment.

VariableParentOccurrence =3D = [PathMinOccurrence] "*" [PathMaxOccurrence]
PathMinOccurrence        =3D= 1*DIGIT
PathMaxOccurrence =        =3D 1*DIGIT

Same= comment as above.

I looked for examples of = that sort of commenting but didn=E2=80=99t find much guidance. = Eventually I simply appended " ; no upper limit=E2=80=9D to each of = the four referenced lines and added that to https://github.com/cellar-wg/ebml-specification/pull/265= .
I think this is the wrong fix. Is it = sufficient for an implementation to use 32 bit value to represent any of = these? 64 bit value?
"no upper limit" is not going to be = interoperable.

The = smallest possible EBML Element is 2 bytes (1 bytes Element ID, 1 byte = Element Data Size, and 0 bytes of Element Data). The upper limit of how = many occurrences would be determined by the limit of the Element Data = Size of the Parent Element. If the EBML Document = has EBMLMaxSizeLength as the default of 8, then the upper limit of = an Element Data Size is 72,057,594,037,927,934 bytes. Is the = smallest possible Element is 2 bytes, then the upper limit of that = Element=E2=80=99s occurrence would be 72,057,594,037,927,934 = divided by two.

So if = EBMLMaxSizeLength =3D 8, then this is possible

<RootElement>
= <TwoByteElement/>  # 36,028,797,018,963,967 = occurrences
</RootElement>

but this would overflow the Element Data Size of = the Root Element
<RootElement>
= <TwoByteElement/>  # 36,028,797,018,963,968 = occurrences
</RootElement>

However, EBML allows the EBML Document Type to set = an EBMLMaxSizeLength value higher than 8, and as that is = incremented up the upper limit would expand exponentially.

In my draft I would considering "no upper limit=E2=80= =9D and 36,028,797,018,963,967 to effectively be the same or that the = definition does not define the limit but in practice it would be limited = by the capacity of the Element Data Size of the parent = Element.

11.1.10.1.  label

  The label provides a concise expression for human = consumption that
  describes= what the value of the "<enum>" represents.

Is it worth adding a = cross reference to the "lang" attribute here?

Do you mean to express the language of = the term used within the label? Currently the language of the label is = undefined and since it is an attribute that label is not repeatable.

To be = honest I am not yet sure how I feel about "undefined language" here. = Need to think about that.
But either way, I think adding some = text that "lang" attribute doesn't apply would be = helpful.

In the = case of Matroska, the labels are in English. In the EBML definition we = could say that the labels are in English unless the definition of that = associated EBML Document Type claims otherwise.

12. =  Considerations for Reading EBML Data

  If a Master = Element contains a CRC-32 Element that doesn't validate,
  then the EBML Reader MAY = ignore all contained data except for
  Descendant Elements that contain their own valid = CRC-32 Element.

I don't fully understand your use of = "MAY ... except ..." here.
Can you = elaborate on why would an implementation ignore data contained in a = Master Element and not ignore Descendant Elements, even if they own = CRC-32 is valid?

For instance if a = Matroska file has three metadata tags and each has a CRC value and so = does the parent Tags element like this.

<Tags = crc=3Dinvalid>
  <Tag = crc=3Dvalid>
  <Tag = crc=3Dvalid>
  <Tag = crc=3Dinvalid>
<Tags>

We=E2=80=99re trying to say that even though the contents of = the <Tags> element is invalid, that the valid child elements may = still be used.
So to = me this means that after discarding all invalid elements you end up with = something like this:

<Tags >
  <Tag crc=3Dvalid>
</Tags>

As this is an incomplete document, I am struggling to = understand what it can be used for?

In that case, the valid Tags are still useful even = if within a parent element whos contents are invalid. Perhaps another = example would be in the Attachments Element:

<Attachments crc=3Dinvalid>
= <Attachment crc=3Dinvalid>Poster = Art</Attachment>
<Attachment = crc=3Dvalid>Subtitle = Font</Attachment>
</Attachments>

Here some bit damage occurs to the Poster Art so = the Attachment and its parent Attachments now have invalid crcs, however = the subtitle font is still ok and could be used in the presentation = without an issue.

An invalid descendant element would make all ancestor = element invalid, but should not necessary make all sibling elements = unusable.


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

= --Apple-Mail=_AF05F1A0-7488-43C1-ADF5-5D1DACE7BE3E-- From nobody Mon Jul 15 11:42:14 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 EC75B1201CA; Mon, 15 Jul 2019 11:42:02 -0700 (PDT) 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_HELO_NONE=0.001, 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 TbgLR9ms8Mz9; Mon, 15 Jul 2019 11:42:01 -0700 (PDT) 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 E4BFC120129; Mon, 15 Jul 2019 11:41:48 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 3FAD8380BE; Mon, 15 Jul 2019 14:41:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A0EFD07; Mon, 15 Jul 2019 14:41:46 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org, draft-ietf-cellar-codec@ietf.org, draft-ietf-cellar-matroska@ietf.org, draft-ietf-cellar-tags@ietf.org, draft-weaver-cellar-flac@ietf.org In-Reply-To: <156319093112.17767.7817772653675881756.idtracker@ietfa.amsl.com> References: <156319093112.17767.7817772653675881756.idtracker@ietfa.amsl.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: [Cellar] expiring drafts 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, 15 Jul 2019 18:42:08 -0000 --=-=-= Content-Type: text/plain There are four drafts with impeding expiries: * draft-ietf-cellar-codec * draft-ietf-cellar-matroska * draft-ietf-cellar-tags * draft-weaver-cellar-flac Due to the the draft submission system being closed they won't actually expire until July 22, and you can't update them until that date. But, please send a refresh for the documents on July 22. I know that we are actively working on at least two of them, although attention is currently on getting the ebml edits done. Integers are cheap! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0syOoACgkQgItw+93Q 3WUP4QgAqCyK/HSpOfgHUU6IoHEIO+fj+0AWYrROLZX4juLcJ6+myuLdtupRdzbt eM0k0iA/5M88ElELml4SIDSaVvrXyQM6vMg3fnEVCq3oBsR78/xFBE3bjajUexKX 0vhAq2vlcdMwadU62Rd33G6ybaO8dlaP3QnKWBzZX8PcGYevYvA1H/dE4LV3e8GC lqpasuLlJHZDwyrHnwu8b0dadmYej8qR9NmR+2+Jv3DCfavL1SmFIqxBC4hrczGq SBD/htLyvqpWnW7soxg5+1cLXPOcCYj19bM7zmdpF5eHQlR+kWI/9IDX5Cs7ILxH G60qm1cunwdkTNcnkPCxWXNMlgE1rQ== =r2mE -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 15 13:31: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 B3633120106; Mon, 15 Jul 2019 13:31:55 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 AIgC1qzgIx9d; Mon, 15 Jul 2019 13:31:54 -0700 (PDT) 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 AF3DF12007C; Mon, 15 Jul 2019 13:31:54 -0700 (PDT) Received: from [146.96.19.240] (port=51220 helo=[10.10.201.45]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hn7dV-000adW-I3; Mon, 15 Jul 2019 16:31:53 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dave Rice In-Reply-To: <7601.1563216106@localhost> Date: Mon, 15 Jul 2019 16:31:47 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission , draft-ietf-cellar-codec@ietf.org, draft-ietf-cellar-matroska@ietf.org, draft-ietf-cellar-tags@ietf.org, draft-weaver-cellar-flac@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4119A416-E188-4293-A45A-561C30E0EEAB@dericed.com> References: <156319093112.17767.7817772653675881756.idtracker@ietfa.amsl.com> <7601.1563216106@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-1.0 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] expiring drafts 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, 15 Jul 2019 20:31:56 -0000 Hi Michael, > On Jul 15, 2019, at 2:41 PM, Michael Richardson = wrote: >=20 >=20 > There are four drafts with impeding expiries: > * draft-ietf-cellar-codec > * draft-ietf-cellar-matroska > * draft-ietf-cellar-tags > * draft-weaver-cellar-flac >=20 > Due to the the draft submission system being closed they won't = actually > expire until July 22, and you can't update them until that date. > But, please send a refresh for the documents on July 22. I can upload new versions at that time. Dave= From nobody Sat Jul 20 14:55:20 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 E12961201D8 for ; Sat, 20 Jul 2019 14:55:18 -0700 (PDT) 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_HELO_NONE=0.001, 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 tSNPTlUjT-6b for ; Sat, 20 Jul 2019 14:55:17 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E815E1201A0 for ; Sat, 20 Jul 2019 14:55:16 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id w7so26874902oic.3 for ; Sat, 20 Jul 2019 14:55:16 -0700 (PDT) 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=zhuX/vl1l2P+r/Ynaz1CAPuqEcCrxWPbnm8z6uRi3QI=; b=vXanpgjCgh0JPiDWtlGpU2BEb4jtSBDXSiwGH8rAY4y5c59vap6KP6vLyLY0V5mrNM 9WSkNhM50EPqS6pvnyouj6F6t9+DKTD78+zxp5hyVsR9a6JqD4fNUbEmgciQD7I/4eSJ Mdtw5oZhzpMKbguzo/UiWZYnruC8nsDsKOco2SbGl5keI4zBw6rbVTCVKONFN2oHkz9H A+0Mg9I8MwUJBl+KR8E8DhRRtDGFNH0h8BzK9KKxasvb9Rj/zQxtSmYr5Q+OL89eHvfo AUZOWEdU/VzkMKa5bG4e97LiTq+45Cn7VpJSy6rWTNgkZVnzoRtVxqN3wQsNZT0Nc3Gs SE6A== 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=zhuX/vl1l2P+r/Ynaz1CAPuqEcCrxWPbnm8z6uRi3QI=; b=da/iwjH/dA3NPZyDImGV35H9q2K29muODDHrxw/qrU8fOLbvWL3ZINP3tzwa1WBxjb OXYsaLPCwcfxZoJNKTHvVYx/txG16dRW3+Y5Ete/htaPS3DdCao4MrTIGbz5dq1zgpSm 7sH+91NJbpR/kCEF03NZ5qGu+ARYJzpK0uTjEt+DQPiEH30GdhQpTvUiIzgTan3bHYOV R5IGfTy3Vdcd2v0JK6lpUY5xc/00U+S5RpiltMX1n/lqidbELJwo6QHtBzBYn/ht7/yJ tdfSUb+2j41nTPSIVS5BK8jYz1fr4m+KDok5m0JRh0/EksnYTc8Yq/kB9S++b5xjewkX 0YWA== X-Gm-Message-State: APjAAAV3RbMFeVbs8opc/eucQKCMqq2DlBxeTOd4oOart+vv0tzt7qHo CCPzFP91VaVDH4mUoOyHpYtArUNPpuJ93UmR8YOP2PTH9ZY= X-Google-Smtp-Source: APXvYqzaz30XLKGYE3a6rFemNsrE9EXSJVZmt7/5yZPuIsyv/35i3/G+CmYYntrsNqEnzQBxw+wz+HpB6B1KK/JgqV4= X-Received: by 2002:aca:d415:: with SMTP id l21mr29581834oig.96.1563659715973; Sat, 20 Jul 2019 14:55:15 -0700 (PDT) MIME-Version: 1.0 From: Tony Arcieri Date: Sat, 20 Jul 2019 14:55:05 -0700 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000eb9748058e23e5eb" Archived-At: Subject: [Cellar] draft-ietf-cellar-ebml questions regarding "vints" 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, 20 Jul 2019 21:55:19 -0000 --000000000000eb9748058e23e5eb Content-Type: text/plain; charset="UTF-8" Hello, I recently came across draft-ietf-cellar-ebml and was pleased to see it specified a "prefix varint" format. It's a bit serendipitous, as I (as part of a personal, outside-of-IETF project) had written a similar specification which also called them "vints": https://github.com/clasp-lang/veriform/blob/master/spec/draft-veriform-spec.md#little-endian-prefixed-variable-width-integers I think there are a few places the "vints" described in this draft could potentially be improved (or perhaps I'm misunderstanding). The things I'd be interested in proposing are micro-optimizations. I'm curious if there's still time/interest in that sort of thing, and more generally comparing these two approaches, or has the ship already sailed? Notably, if I'm understanding correctly: draft-ietf-cellar-ebml vint decoding appears to involve a loop, whereas the ones I have spec'd can be done entirely with an unaligned load and a shift and does not require a loop. Regardless, "Cellar" looks quite interesting and I'm glad there's IETF work on specifying this sort of construction. -- Tony Arcieri --000000000000eb9748058e23e5eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, I recently came across=C2=A0draft-ietf-cellar-ebml = and was pleased to see it specified a "prefix varint" format. It&= #39;s a bit serendipitous, as I (as part of a personal, outside-of-IETF pro= ject) had written a similar specification which also called them "vint= s":

https://github.com/clasp-lang/veriform/blob/master/spec/dra= ft-veriform-spec.md#little-endian-prefixed-variable-width-integers

I think there are a few places the "vints" d= escribed in this draft could potentially be improved (or perhaps I'm mi= sunderstanding). The things I'd be interested in proposing are micro-op= timizations. I'm curious if there's still time/interest in that sor= t of thing, and more generally comparing these two approaches, or has the s= hip already sailed?

Notably, if I'm underst= anding correctly: draft-ietf-cellar-ebml vint decoding appears to involve a= loop, whereas the ones I have spec'd can be done entirely with an unal= igned load and a shift and does not require a loop.

Regardless, "Cellar" looks quite interesting and I'm glad t= here's IETF work on specifying this sort of construction.
--
Tony Arcieri
--000000000000eb9748058e23e5eb-- From nobody Sat Jul 20 16:09: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 212781200EF for ; Sat, 20 Jul 2019 16:09:09 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 j-qHFxGvH13P for ; Sat, 20 Jul 2019 16:09:07 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 0BE5A120096 for ; Sat, 20 Jul 2019 16:09:07 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id p17so35600320wrf.11 for ; Sat, 20 Jul 2019 16:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:mime-version:in-reply-to :content-transfer-encoding; bh=GGeZhzDAbrwTSSzoFGNcIBclg1Hvc/Xc5rJlI8RqUWg=; b=erkcqEYp+8kb1pRobHAro3kN5FxqzqvO2hMkNT4mwDKsM7dGAxu2YiKV8lkw2rxQ2b 1RI2MZ3kV2i985KYPT8w+F3IyY7PmbM981mrVkY2TE9275s9799ZkmI3+txPmOFHTd16 A0+gQKZGTK+bJcLyyqs18HiEnSZ9kP/23GNt6tgt5vsMXpgkaATPRprdyL5DNwj2wxpj 66376DqF4KDxihtTUS2ydehK21/Tjp/nJZ1xaza5DBUjlgvGn7dMs0wrJR3n+Yt+Qlwf PSmhrnFdZ0tfDNvhL5ddcmMQgyuX9DDDp38ZX8IyujZGXDXWqLEg5BVTy7bmEdfK+d3i idmA== 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 :mime-version:in-reply-to:content-transfer-encoding; bh=GGeZhzDAbrwTSSzoFGNcIBclg1Hvc/Xc5rJlI8RqUWg=; b=Ut0Qim9IfR/zyEe7u6zM2JYiYSCv1ZDt/c9U5cULzxY9adEvvYhAXb0ShiI/a98bQS gyDhopSRwo7kPMbgJCNx6OHO62WBuXwD+36Yj1QAWNGmmLjyBadYKtJiqveumO6UYT2D /4fPszhCRYP5VJYPlmtamAIFTAmmU85lw3GvhAyw0RgJIYCCyhuLCrGyShO8PVyGUHcc HVe91jCsjTkpfFIHxPnhNRU7+umWXKKTF7a3B3MoPxcLItIXb/8Nw2QR3tC7pJKw5Om3 Lt4suDvhN17M1/zop7eJecEPuWGaESCUOogQRKUSrgS/Hh5mN2sjj4YuhbFHdZzlWTRT cSvg== X-Gm-Message-State: APjAAAXGe00b3yzdhj+xRAsgZXvYaKvghU15QOsabuM6Y0BBR2Axd0EB wciXcj74mLSyXo74qlzJ07r+X55p X-Google-Smtp-Source: APXvYqw91SIkYcZX7JfJQArt8tM/k4s93Eog55Fj0EliSSlUgfn0o6SX/Iu6Srj7aR10484l8UBLBA== X-Received: by 2002:a5d:6144:: with SMTP id y4mr65673664wrt.84.1563664145425; Sat, 20 Jul 2019 16:09:05 -0700 (PDT) Received: from [127.0.0.1] (tor-exit-1.zbau.f3netze.de. [2a0b:f4c0:16c:1::1]) by smtp.gmail.com with ESMTPSA id g10sm25169365wrw.60.2019.07.20.16.09.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jul 2019 16:09:04 -0700 (PDT) To: cellar@ietf.org References: From: Andreas Rheinhardt Message-ID: Date: Sat, 20 Jul 2019 23:08:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] draft-ietf-cellar-ebml questions regarding "vints" 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, 20 Jul 2019 23:09:09 -0000 Hello, Tony Arcieri: > Hello, I recently came across draft-ietf-cellar-ebml and was pleased to see > it specified a "prefix varint" format. It's a bit serendipitous, as I (as > part of a personal, outside-of-IETF project) had written a similar > specification which also called them "vints": > > https://github.com/clasp-lang/veriform/blob/master/spec/draft-veriform-spec.md#little-endian-prefixed-variable-width-integers > > I think there are a few places the "vints" described in this draft could > potentially be improved (or perhaps I'm misunderstanding). The things I'd > be interested in proposing are micro-optimizations. I'm curious if there's > still time/interest in that sort of thing, and more generally comparing > these two approaches, or has the ship already sailed? > The whole aim of this working group is to create specifications for an already existing format: Matroska (defined more than a decade ago, probably billions of files in existence). Matroska is based on EBML and so that ship has definitely sailed. > Notably, if I'm understanding correctly: draft-ietf-cellar-ebml vint > decoding appears to involve a loop, whereas the ones I have spec'd can be > done entirely with an unaligned load and a shift and does not require a > loop. On a big-endian system (or more generally, on a system where one can easily perform unaligned big-endian loads -- I would count x86/x64 among them), one can read EBML's vint via a 64bit unaligned BE load, then one has to get the number of leading zeroes in the first (most serious) byte, mask the marker bit away and perform an appropriate right shift. On a little-endian system and your proposal, one can use a LE load, count the number of trailing zeroes in the least serious byte, mask the bytes that have been read but don't belong to the number away and perform a right shift. So it is pretty much the same, just for little-endian. The only difference is that you have the special-case of the first byte being all zero in order to encode the whole uint64_t range. That's not a concern for EBML. - Andreas From nobody Sat Jul 20 16:20:27 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 1C40F120096 for ; Sat, 20 Jul 2019 16:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 bZ1yUEonSOrX for ; Sat, 20 Jul 2019 16:20:24 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 238F012004F for ; Sat, 20 Jul 2019 16:20:24 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id x21so36449373otq.12 for ; Sat, 20 Jul 2019 16:20:24 -0700 (PDT) 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=VK7whhKwOT1NTJO+HpNYlrO4PSpH33MfF/PFxkqFE8g=; b=Ko74kNt+5YT+v1CH00JZECJa7l9PW+ckBPFxZOewvG6/Cos0kcafSwH7+a/4KV5zQ3 YS+XBEx9/o1bZcr0XnO6x2RWZ+5lGurKYBXOHZn4N5EIa9yi2tg0+/SNXKFzvIloZkTR NKtxpq6eJNPYLxZ3ZFB+U8Ab9QGXwSszJ4sc1Rbjq+4PTivoy14RtqHJak/9vTdGgZQA 27jOxkDCdJle74oNUgoT/ymc2/O8/iRAeLMt+vxYhDG3kJ+BVqLzH/Zwkj3Fi3IsDB+/ Rsnns4xjxpjTRdpO3iaK37QkPpEXvEF8gIwttGodI3cAG4/ZomYT1vMwQEPBSjjKGWgs Dbpw== 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=VK7whhKwOT1NTJO+HpNYlrO4PSpH33MfF/PFxkqFE8g=; b=sEUNwy3pgZioU53KZqAnhjK9WwH8KEw/4HmsPRMP2vUhhK1xkDOVcryP6znNp4RHdd Nc3LnQLqsksH+Za9ESt/P8I5ZHI2f6vtqDsnGJI4ApMEnfquvbtPjORtst49hhxc/t81 dyzqxxjN6xubKuITQDfDHwthPqjDv+aBkRjElzHg74gbPS8ZtcCl25/fkfAL4znONF9b 62LYqddwngKV7TD5NtQR5BXQJH/kiUAr3DfAC64W+bgFkEl3c6FPTkTW4lq35kgi9hxh bh4xF7zU0MBOzmOXx7W5HV06ZOtDt4IqAmBe68WOx+2DTnQeJHPCP43AH3qD3eGmjfZ8 hi/A== X-Gm-Message-State: APjAAAViwhIxyFb9R79Iu7+KdM0xICUOy79WHOwrPP1QSFbqdcqWSwOS zHoZnKaAW9m9Mj+aCAeCGpaWPX2uN7X7V9JENnw= X-Google-Smtp-Source: APXvYqwdA784JdrX29TnPko8uurZ5/ekpY1c7qQMjsNnkCTHVPtBbWiagA3mBp/m0nw10xRirjJW2IHAcphGlLOKPKE= X-Received: by 2002:a9d:5787:: with SMTP id q7mr4658623oth.75.1563664823394; Sat, 20 Jul 2019 16:20:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tony Arcieri Date: Sat, 20 Jul 2019 16:20:12 -0700 Message-ID: To: Andreas Rheinhardt Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="00000000000058a549058e2516f1" Archived-At: Subject: Re: [Cellar] draft-ietf-cellar-ebml questions regarding "vints" 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, 20 Jul 2019 23:20:26 -0000 --00000000000058a549058e2516f1 Content-Type: text/plain; charset="UTF-8" Thanks for the clarifications. Makes perfect sense. On Sat, Jul 20, 2019 at 4:09 PM Andreas Rheinhardt < andreas.rheinhardt@gmail.com> wrote: > Hello, > > Tony Arcieri: > > Hello, I recently came across draft-ietf-cellar-ebml and was pleased to > see > > it specified a "prefix varint" format. It's a bit serendipitous, as I (as > > part of a personal, outside-of-IETF project) had written a similar > > specification which also called them "vints": > > > > > https://github.com/clasp-lang/veriform/blob/master/spec/draft-veriform-spec.md#little-endian-prefixed-variable-width-integers > > > > I think there are a few places the "vints" described in this draft could > > potentially be improved (or perhaps I'm misunderstanding). The things I'd > > be interested in proposing are micro-optimizations. I'm curious if > there's > > still time/interest in that sort of thing, and more generally comparing > > these two approaches, or has the ship already sailed? > > > The whole aim of this working group is to create specifications for an > already existing format: Matroska (defined more than a decade ago, > probably billions of files in existence). Matroska is based on EBML > and so that ship has definitely sailed. > > > Notably, if I'm understanding correctly: draft-ietf-cellar-ebml vint > > decoding appears to involve a loop, whereas the ones I have spec'd can be > > done entirely with an unaligned load and a shift and does not require a > > loop. > > On a big-endian system (or more generally, on a system where one can > easily perform unaligned big-endian loads -- I would count x86/x64 > among them), one can read EBML's vint via a 64bit unaligned BE load, > then one has to get the number of leading zeroes in the first (most > serious) byte, mask the marker bit away and perform an appropriate > right shift. > > On a little-endian system and your proposal, one can use a LE load, > count the number of trailing zeroes in the least serious byte, mask > the bytes that have been read but don't belong to the number away and > perform a right shift. So it is pretty much the same, just for > little-endian. The only difference is that you have the special-case > of the first byte being all zero in order to encode the whole uint64_t > range. That's not a concern for EBML. > > - Andreas > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Tony Arcieri --00000000000058a549058e2516f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarifications. Makes perfect sense.
<= br>
On Sat,= Jul 20, 2019 at 4:09 PM Andreas Rheinhardt <andreas.rheinhardt@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">Hello,

Tony Arcieri:
> Hello, I recently came across draft-ietf-cellar-ebml and was pleased t= o see
> it specified a "prefix varint" format. It's a bit serend= ipitous, as I (as
> part of a personal, outside-of-IETF project) had written a similar
> specification which also called them "vints":
>
> https://github.com/clasp-lang/veriform/blob/m= aster/spec/draft-veriform-spec.md#little-endian-prefixed-variable-width-int= egers
>
> I think there are a few places the "vints" described in this= draft could
> potentially be improved (or perhaps I'm misunderstanding). The thi= ngs I'd
> be interested in proposing are micro-optimizations. I'm curious if= there's
> still time/interest in that sort of thing, and more generally comparin= g
> these two approaches, or has the ship already sailed?
>
The whole aim of this working group is to create specifications for an
already existing format: Matroska (defined more than a decade ago,
probably billions of files in existence). Matroska is based on EBML
and so that ship has definitely sailed.

> Notably, if I'm understanding correctly: draft-ietf-cellar-ebml vi= nt
> decoding appears to involve a loop, whereas the ones I have spec'd= can be
> done entirely with an unaligned load and a shift and does not require = a
> loop.

On a big-endian system (or more generally, on a system where one can
easily perform unaligned big-endian loads -- I would count x86/x64
among them), one can read EBML's vint via a 64bit unaligned BE load, then one has to get the number of leading zeroes in the first (most
serious) byte, mask the marker bit away and perform an appropriate
right shift.

On a little-endian system and your proposal, one can use a LE load,
count the number of trailing zeroes in the least serious byte, mask
the bytes that have been read but don't belong to the number away and perform a right shift. So it is pretty much the same, just for
little-endian. The only difference is that you have the special-case
of the first byte being all zero in order to encode the whole uint64_t
range. That's not a concern for EBML.

- Andreas

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


--
Tony Arcieri
--00000000000058a549058e2516f1-- From nobody Mon Jul 22 12:34: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 A1A5112011B; Mon, 22 Jul 2019 12:34:04 -0700 (PDT) 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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <156382404459.22683.4185294381231727239@ietfa.amsl.com> Date: Mon, 22 Jul 2019 12:34:04 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-matroska-03.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: Mon, 22 Jul 2019 19:34:05 -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-03.txt Pages : 161 Date : 2019-07-22 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-matroska-03 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 Mon Jul 22 12:34:18 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 3F0CA120144; Mon, 22 Jul 2019 12:34:05 -0700 (PDT) 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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <156382404518.22781.8082484582645881109@ietfa.amsl.com> Date: Mon, 22 Jul 2019 12:34:05 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-tags-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: Mon, 22 Jul 2019 19:34:05 -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-02.txt Pages : 20 Date : 2019-07-22 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-tags-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-tags-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 Mon Jul 22 12:34:31 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 5481C12014E; Mon, 22 Jul 2019 12:34:05 -0700 (PDT) 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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <156382404525.22796.4719925428057435768@ietfa.amsl.com> Date: Mon, 22 Jul 2019 12:34:05 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-codec-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: Mon, 22 Jul 2019 19:34:06 -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-02.txt Pages : 45 Date : 2019-07-22 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-codec-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-codec-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 Mon Jul 22 14:34:29 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 DD50B1200B6 for ; Mon, 22 Jul 2019 14:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 hZ6fKUzVzMPp for ; Mon, 22 Jul 2019 14:34:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00C312001B for ; Mon, 22 Jul 2019 14:34:26 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:1232:144:6e88:14ff:fe34:93bc]) by relay.sandelman.ca (Postfix) with ESMTPS id 35C131F44B; Mon, 22 Jul 2019 21:34:24 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 042D33B76; Mon, 22 Jul 2019 17:34:46 -0400 (EDT) From: Michael Richardson To: Tony Arcieri cc: cellar@ietf.org In-reply-to: References: Comments: In-reply-to Tony Arcieri message dated "Sat, 20 Jul 2019 14:55:05 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 22 Jul 2019 17:34:45 -0400 Message-ID: <2720.1563831285@dooku.sandelman.ca> Archived-At: Subject: Re: [Cellar] draft-ietf-cellar-ebml questions regarding "vints" 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, 22 Jul 2019 21:34:29 -0000 --=-=-= Content-Type: text/plain Tony Arcieri wrote: > Hello, I recently came across draft-ietf-cellar-ebml and was pleased to > see it specified a "prefix varint" format. It's a bit serendipitous, as > I (as part of a personal, outside-of-IETF project) had written a > similar specification which also called them "vints": > https://github.com/clasp-lang/veriform/blob/master/spec/draft-veriform-spec.md#little-endian-prefixed-variable-width-integers > I think there are a few places the "vints" described in this draft > could potentially be improved (or perhaps I'm misunderstanding). The > things I'd be interested in proposing are micro-optimizations. I'm > curious if there's still time/interest in that sort of thing, and more > generally comparing these two approaches, or has the ship already > sailed? Sorry, a) the ship has sailed, EBML is past WGLC. b) as was said, this is documenting an existing protocol.... if not we would have used CBOR. Is there a reason your document didn't use CBOR? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl02K/UACgkQlUzhVv38 QpBS+wf+K8oyjCwKgoydx7lLBHd7uRY5K4+SuGkS2jEa7jncbLyu0hwUlv7l2pd8 c/O8VHwJf2qL7wky3bita3MeDOV1EjnUnndw1UIMSiDs1fh52snrGNg5SRE1QMdn H4N5CiWf7AJ/0Cc9FyZFbtFCs1bKEuCax+aqJ1LF0XetTN+qRm2RpleRvoKCwMAb 9un9TTJq2NC2MXYct9+T2NsBcuvyH+4jG3q+K/rnrX6pfS2ZrnvxAGZvanPNwiQN U1tXm79XnvnhvQGMsXWVRnxEFAXflvbBDSDY09XSJsR7P0ibQyenrf45yWmLEkLC 9i8tlFrYSnVqmZFojZf/QbfzyPUXvg== =6p7w -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 22 18:03: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 3607D120045 for ; Mon, 22 Jul 2019 18:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 J0CRr8EOIZL3 for ; Mon, 22 Jul 2019 18:03:48 -0700 (PDT) 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 DA7F312001E for ; Mon, 22 Jul 2019 18:03:47 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id l12so31064436oil.1 for ; Mon, 22 Jul 2019 18:03:47 -0700 (PDT) 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=fLwEQ28lHH2uOfSHD2WWMD9Ob8S7As4VJUHmJkn8jEI=; b=qoGf24HOYHdgfm+HOGXV7aXmoQ+hewou2Y8BFShnfX2V1uMQAxcG82kF+TfcrA3rcA xJ8FfxaC3f+Jf8dVkyOzTWRjMAtWE4EV+j405a1EDBAzO+wcbKJvzze6/9/agHR3Elcr 8qaJro1YEwDp/nqd0vzvlMPL5n5CBndYRNvStmZBBsGoacztEnNccUXnuxk0jEKjExVZ 61kgQAiq7S004mY9vqjtKqieQZAxbS4dfNGKJra0W9LQbq4xkEOmL3fqCZk1C17UP2qD z25l1d2yOmTaPOGp6V9oNfRX3ai5y3+IYl9xMqKk669kYg9AxjKFUN6hdxRmlC/lbuT5 IN9A== 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=fLwEQ28lHH2uOfSHD2WWMD9Ob8S7As4VJUHmJkn8jEI=; b=rm1s413aCsSUhf6EZVKC+bu2kkk3TWkBNORqBY2HB2aF8vpfQs21t0atv1RdGIpVtR XqM1MEInvF4pHZPZzRD2B1WOTds+2fGAsiWvTw1UA766j7Eyn7A9owUYuUi6oYdZNY4m hlRQWH/SAiXH3cWb0tr/uBlDtaux8/r9EjvY2dndY1+48aJCzsyBbUX+JJTq2BLq5Vz1 n3TrUO002zIF0clUCBdJHcq5S6ieidz725mac/2usHXlOs19l1hvkgKEKH/gHfFTQTdD Qb13YbpkfgTyGzMj0llV3IEYsNZTIndDZIhpwALKyWY3xn1TTnKEprKeiQZhxT6rpeK1 uZLQ== X-Gm-Message-State: APjAAAVWk3flnbpZWfCTpUh1ywWSZj43Twd1UQjkR3hSWxN5vbpT7OhM tFPHcSriYJStNgzlAF1/F1+vT55G5bbvHf9GD90QvgXf X-Google-Smtp-Source: APXvYqyUUMe/RoFPgfdXJhcYKn1pJGhYpF9iQ9tl7VHljRbMueHORvk2lIFjwR0LLGv/HkBv9M+WVsiG6wK39MLSMlI= X-Received: by 2002:aca:5b86:: with SMTP id p128mr33217782oib.126.1563843826879; Mon, 22 Jul 2019 18:03:46 -0700 (PDT) MIME-Version: 1.0 References: <2720.1563831285@dooku.sandelman.ca> In-Reply-To: <2720.1563831285@dooku.sandelman.ca> From: Tony Arcieri Date: Mon, 22 Jul 2019 18:03:36 -0700 Message-ID: To: Michael Richardson Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000c911b6058e4ec305" Archived-At: Subject: Re: [Cellar] draft-ietf-cellar-ebml questions regarding "vints" 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, 23 Jul 2019 01:03:50 -0000 --000000000000c911b6058e4ec305 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 22, 2019 at 2:34 PM Michael Richardson wrote: > b) as was said, this is documenting an existing protocol.... if not we > would > have used CBOR. Is there a reason your document didn't use CBOR? I am exploring a different set of tradeoffs from the ones CBOR made. Most notably, what I'm working on is very much "schema first". I'm also working on an abstract object model that spans encodings, and CBOR is one of them. Think ASN, but made this millennium. This encoding is the "native" encoding of the object model, however CBOR is (or more like can, with some PoC code) also be supported. The primary purpose is content-aware hashing that works across different encodings, a problem e.g. JWT/CWT punted on completely, and my encoding is both size-optimal and ultimately must be computed anyway to verify content hashes from foreign encodings. Yes, [img:xkcd], I'm all too aware... My primary application is credentials and other cryptographically verifiable data. This is an area where the set of tradeoffs made by CBOR aren't working particularly well. One of the original goals of CBOR was to avoid multiple encodings ala ASN.1, however together with the absence of a schema language CBOR is rather suboptimal in this regard, and thus we get things like "Packed CBOR". I could keep going, e.g. my solutions to the problems in RFC 7049 2.4.4.2 take the diametrical opposite approach by enriching JSON with type annotations rather than complicating the binary protocol, but this probably isn't the appropriate venue for an extended CBOR rant. -- Tony Arcieri --000000000000c911b6058e4ec305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2019 at 2:34 PM Michael R= ichardson <= mcr+ietf@sandelman.ca> wrote:
b) as was said, this is doc= umenting an existing protocol.... if not we would
=C2=A0 =C2=A0have used CBOR.=C2=A0 Is there a reason your document didn'= ;t use CBOR?

I am exploring a different set= of tradeoffs from the ones CBOR made. Most notably, what I'm working o= n is very much "schema first".

I'm a= lso working on an abstract object model that spans encodings, and CBOR is o= ne of them. Think ASN, but made this millennium. This encoding is the "= ;native" encoding of the object model, however CBOR is (or more like c= an, with some PoC code) also be supported. The primary purpose is content-a= ware hashing that works across different encodings, a problem e.g. JWT/CWT = punted on completely, and my encoding is both size-optimal and ultimately m= ust be computed anyway to verify content hashes from foreign encodings. Yes= , [img:xkcd], I'm all too aware...

My primary = application is credentials and other cryptographically verifiable data. Thi= s is an area where the set of tradeoffs made by CBOR aren't working par= ticularly well. One of the original goals of CBOR was to avoid multiple enc= odings ala ASN.1, however together with the absence of a schema language CB= OR is rather suboptimal in this regard, and thus we get things like "P= acked CBOR".

I could keep going, e.g. my solu= tions to the problems in RFC 7049 2.4.4.2 take the diametrical opposite app= roach=C2=A0by enriching JSON with type annotations rather than complicating= the binary protocol, but this probably isn't the appropriate venue for= an extended CBOR rant.

--
Tony Arcieri
--000000000000c911b6058e4ec305-- From nobody Mon Jul 29 10:25:50 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 C2FA91203BE for ; Mon, 29 Jul 2019 10:25:48 -0700 (PDT) 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_HELO_NONE=0.001, 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 UeY3uzEZ4y1q for ; Mon, 29 Jul 2019 10:25:45 -0700 (PDT) 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 A950B1203BD for ; Mon, 29 Jul 2019 10:25:45 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E8603808A for ; Mon, 29 Jul 2019 13:25:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 11B41BDF for ; Mon, 29 Jul 2019 13:25:44 -0400 (EDT) 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] AGENDA 2019-07-30 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, 29 Jul 2019 17:25:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable CELLAR -- DRAFT AGENDA for Virtual Interim Meeting July 30, 2019 20:00 UTC INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-06/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-06-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. 2. Accept draft minutes from June 25 meeting (attached below) 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 2c) Roll call 4. WG status update * EBML -- still waiting on revised -11 document for AD evaluation. ACTION from last time: =3D=3D> issue #257, requested one more day to think about it. The c= hanges are fine in general, but want to make sure it precise enough. (= MB)=20 * Thank for reposting of draft-ietf-cellar-tags-02, draft-ietf-cellar-matroska-03 and draft-ietf-cellar-codec-02 * The personal draft-weaver-cellar-flac-00 did not get reposted. I believe that we adopted it, so it should have been reposted with a draft-ietf-cellar-flac-00! 5. Any remining EBML issues. 5. Work on Matroska issues. 6. Any other business. =3D=3D=3D=3D CELLAR -- DRAFT MINUTES for Virtual Interim Meeting June 25, 2019 20:00 UTC =09 INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-05/session/cel= lar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-05-sessa/ =09 WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes =09 =09 Present: 1) Michael Richardson 2) Moritz Bunkus 3) Martin Below 4) Steve Lhomme 5) Dave Rice 6) J=C3=A9r=C3=B4me Martinez =09=09 Regrets: 1) Reto Kromer =09 1. Note Well. 2. Accept draft minutes from May 28 meeting accepted without change. =09 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospace= Font=3Dtrue =09 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim =09 2c) Roll call =09 4. WG status update * MCR still need to help Martin on large pull request. * EBML changes... done. + issue #257, requested one more day to think about it. The changes are f= ine in general, but want to make sure it precise enough. (MB) * ffv1 has been submitted to IESG by AD. =09 5. Work on Matroska issues. 48 open issues 21 open pull requests https://github.com/cellar-wg/matroska-specification/issues =09=09 Next time, Steve will walk us through XSLT code to validate the specifica= tion. TAG: "format extension" suggestion that does not have to go into the main= spec, because it could be added as separate spec https://github.com/cell= ar-wg/matroska-specification/issues?q=3Dis%3Aissue+is%3Aopen+label%3A%22for= mat+extension%22 "format addition" something that has to go into main specification. = https://github.com/cellar-wg/matroska-specification/issues?q=3Dis%3Aissue+i= s%3Aopen+label%3A%22format+addition%22 =09 * As the WebM will not be defined, remove all of the WebM specific stuff. * MCR suggests removing it from the Matroska document, and leave the histo= ry for others. * MB: DivX is also not part of Matroska. Also concerned about how the Mat= roska project presents the WebM/DiVX vs core Matroska elements. The spec = will be huge, so take things out. * define how to add unpredictable data to the Matroska, so we could track t= hings that are added. Not just WebM, but also a libmotrsaka as well. * extension data would be on their own lines, and revision history would be= clearly. =09=09 6. Any other business. =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =3D=3D=3D=3D CELLAR -- DRAFT MINUTES for Virtual Interim Meeting May 28, 2019 20:00 UTC =09 INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-04/session/cel= lar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-04-sessa/ =09 WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. These notes at: https://github.com/cellar-wg/chair-notes =09 Present: 1) michael richardson 2) Steve Lhomme 3) Martin Below 4) Jerome Martinez 5) Dave Rice 6) Michael Niedermayer =09 Proposed Agenda: =09 1. Note Well. 2. Accept draft minutes from April 2 meeting =09 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospace= Font=3Dtrue =09 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) =09 2c) Roll call =09 4. WG status update - EBML seems to be getting some additional edits, is it done? These were the issues that are waiting for clarification: https://github.com/Matroska-Org/ebml-specification/issues?q=3Dis%3= Aissue+is%3Aopen+label%3Aclarifications We still have a few open. Can we close them now? Dave Rice expected to push version 10.... VERSION 10 released 2019-05-28 (https://datatracker.ietf.org/doc/draf= t-ietf-cellar-ebml/10/). Merged many issues. This addresses AD issues from Ben Campbell and Robert Sparks.... rema= ining 2 11.1.11. XML Schema for EBML Schema (Dave volunteers to complete th= is) The following "XSD" definition is in (add W3C citatio= n), and can be used to validate an EBML Schema using =09 The use of unknown-size requires to know the EBML Schema. Add an e= xample of unknown-size element. =09 Michael will contact Martin in the coming days/weeks to work on his large = chapter pull request. =09 5. Matroska document changes since last meeting. https://github.com/cellar-wg/matroska-specification/issues Can we close some of these, and/or get them sorted and prioritized? =09 a) Dave Rice to post request for volunteers, offers to mentor. b) MCR to mentor Martin on github-fu c) all to review pull requests on Matroska, look for conflicts and *dis= cussion* (new tag) that we can go through next time. d) MCR to ping Moritz about next time. =09 6. Started 4-week adopting call for Free Lossless Audio Codec draft-weaver-cellar-flac-00 will end at next virtual-interim meeting. =09 please post your opinion about the document? Does it fit into w= hat the charter asked for? =09 Q: ffv1. last meeting new AD? A: we are waiting for feedback. ACTION: mcr to bug AD about ffv1. =09 meeting ended 16:55. =09 =09 =09 =09 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0/LBcACgkQgItw+93Q 3WUltwf/UTDq7rzK49TXnhk0/73/9Do3XETIsyLop06coqlhJexAgClrzgi7BZV7 Vsus+SMhuB+uCKZG76NDm6s+ra6AR7SLUdmdHxMJL3xHL82heCGwSGld43ouK0zI eGgE5GvSDBlBLrnGHIHyXhILF/LAeDdISzRh83333vCpJRha1wPEp8C/YpIxnO7P RVAYXgYeAGNVs7cPKlY4FLtikTOb8UZNOPW+pyzyYLuuqbR7xReou3l4QcirQ+vo iVmSe24+NPj9fmFAxb2C7nwziw1nkN/xucAQEJFP50tEDUIwFXU6lX4CvQGVONWF cKxUu4t+zP2eNRXpwC7zQMQqqTaTLA== =x1QW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 29 20: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 E9E1F1200C3 for ; Mon, 29 Jul 2019 20:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=google.com header.b=e8XknlYS; dkim=pass (2048-bit key) header.d=gmail.com header.b=qWt7hXp0 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 a0Fw0reiVf7P for ; Mon, 29 Jul 2019 20:13:07 -0700 (PDT) Received: from mail-qt1-x849.google.com (mail-qt1-x849.google.com [IPv6:2607:f8b0:4864:20::849]) (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 CB457120044 for ; Mon, 29 Jul 2019 20:13:06 -0700 (PDT) Received: by mail-qt1-x849.google.com with SMTP id 41so51226671qtm.4 for ; Mon, 29 Jul 2019 20:13:06 -0700 (PDT) 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=dAqfpbFFtITZyy0EbCd3YgGE+jfNd+jRKIJGyJxBnOg=; b=e8XknlYSkbiHjWHkuSRLbpTh9wAwHMSWmHA+s0vvBDqmvH43+thWRX0IkWTUcuBFgZ FBHVEDRwL4lTQZCxvt3K5/Gecvv96v7GrhDoGuKzH18MkS40O82jpt8tvO91HC0pLsbO JbcBJKq1XHsOy7iNL3SaKx3x0/BfBJsyG6yAmz9utLtCvmgmYtqouCWB8D+zUaq9jTWL icfPPtAQ5EsKEtWevrj/yalYtYqQfJ5w6Uu/49v+ZI3LKWKcMVtp6eMU9RaaS9EKvYuP 2RadozYvs9feEEo2s6w65UpDUq4gmLDxZN1fpTtxangA9AUQgdYYK1J6gfJO5G9FhVBc Dvlg== 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=dAqfpbFFtITZyy0EbCd3YgGE+jfNd+jRKIJGyJxBnOg=; b=qWt7hXp0P6nE/BH9b8UeUUdXAcik6XViZwZzmSCnrT9N3WnsrZKfz/Wzs8Uqt1IHDr FNVZQ9dbyHmuBXLbSZZcjfh0py6oh19LM8YZpl6sCtQHh8e5nUCSkd5GZevphHOVRFDu sKNQldHyd/4C6eUDm+nN5o2C7ILGzavpt80cuxdnWNuEq/LqQURCpxMkd1uItghT+YG8 RXzPnG1J7wmJRczPH2xqXwGLeFCnHqLouKI59eP0RTAjGDzXbSvbokQRqAGbL3khxQpu bhRrINGYLx1oLmFSDJxNmFqZCuzh3OCX7pmJta+CXMYi46Om61dEFhdbUlIZ5VNLR1fd Mdjg== 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=dAqfpbFFtITZyy0EbCd3YgGE+jfNd+jRKIJGyJxBnOg=; b=TJHRR/+nSXB+S3kuKv7+lp43vPU+qQ1RB4y2zURtEwQBk4SEdd6uxlD3Of21g5ccwS 3jxnHTw0YwEDB/uycncsf9BxUu6U/+Jyqpcqgv9YWQR/o3F3qqNpRyUCwjGawSLXBx71 xL4wPymXvLOeX3KXVYcz+Dt3UbuFgDs+PwRCTg4v07uIbstBiap8OhH7ory3E4bLH7NC FfFCRsJgwyMqyrqYf3pbNXLDm7TbrIK2d+vmqBmBqqBZVA9kD/IXdc8ZEqmfcFGpS0bO 9dGTqv+JaqP1yZFowc2CbQ2U0OOl5pNcqbjr019vbNuRSJIAqaQGYRSYf38XehwFW17t 13yQ== X-Gm-Message-State: APjAAAUEXNQU9I/RzFJXw39o70r0IX1DoyDby7hZ0fh8qd/OmNAQeAey Ne5thZXoJbqAoj23oOs+U290vwbmJoapNcNPMMg= X-Google-Smtp-Source: APXvYqxJiSxtKoNgZZF7QQDBLjVm9MgCREUDLNkiIcbsy90hdPAKu46GQh/SzKz9nlLtmcBOwPTVcf+XebS/HL+HkHtS MIME-Version: 1.0 X-Received: by 2002:a05:6214:1447:: with SMTP id b7mr81390627qvy.89.1564456385497; Mon, 29 Jul 2019 20:13:05 -0700 (PDT) Reply-To: mcharlesr@gmail.com Sender: Google Calendar Message-ID: <0000000000001fd22c058edd6334@google.com> Date: Tue, 30 Jul 2019 03:13:05 +0000 From: mcharlesr@gmail.com To: cellar@ietf.org, tterriberry@mozilla.com Content-Type: multipart/mixed; boundary="0000000000001fd210058edd6333" Archived-At: Subject: [Cellar] Invitation: cellar-interim @ Monthly from 16:00 to 17:30 on the last Tuesday from Tue 2019-07-30 to Tue 2019-06-25 (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: Tue, 30 Jul 2019 03:13:09 -0000 --0000000000001fd210058edd6333 Content-Type: multipart/alternative; boundary="0000000000001fd20c058edd6331" --0000000000001fd20c058edd6331 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes You have been invited to the following event. Title: cellar-interim https://datatracker.ietf.org/wg/cellar/meetings/ When: Monthly from 16:00 to 17:30 on the last Tuesday from Tue 2019-07-30 to Tue 2019-06-25 Eastern Time - Toronto Where: https://appear.in/cellar-interim Calendar: cellar@ietf.org Who: * mcharlesr@gmail.com - organizer * cellar@ietf.org * tterriberry@mozilla.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=M200MzhwZjNlMGJ2aDE2b2cxOGtzMzMxYnEgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbTBhOGQwMDgyZGNmM2NmYzg3MTI5NWJlY2NmMDc0MDcxZDgwMGRiNjQ&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 send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding --0000000000001fd20c058edd6331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

You have been invited to the follo= wing event.

cellar-interim

Where
<= /tr>
= When
Monthly from 16= :00 to 17:30 on the last Tuesday from Tue 2019-07-30 to Tue 2019-06-25 Eastern Time - Toronto
https= ://appear.in/cellar-interim (map<= /a>)
Calendar
cellar@= ietf.org
Who
•
mcharlesr@gmail.com - organ= izer
&= #x2022;
=
cellar@ietf.org
tterriberry@mozilla.com

Going (cella= r@ietf.org)?   All events in this series: &= nbsp; Yes - Maybe - No = ;   more options &raqu= o;

Inv= itation from Google Calendar

You are receiving this courtesy email= at the account cellar@ietf.org because you are an attendee of this event.<= /p>

To stop receiving future updates for this event, decline this event. = Alternatively you can sign up for a Google account at https://www.google.co= m/calendar/ and control your notification settings for your entire calendar= .

Forwarding this invitation could allow any recipient to send a resp= onse to the organizer and be added to the guest list, or invite others rega= rdless of their own invitation status, or to modify your RSVP. Learn More.=

--0000000000001fd20c058edd6331 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:20190730T200000Z DTEND:20190730T213000Z RRULE:FREQ=MONTHLY;UNTIL=20190625;BYDAY=-1TU DTSTAMP:20190730T031305Z ORGANIZER;CN=mcharlesr@gmail.com:mailto:mcharlesr@gmail.com UID:3m438pf3e0bvh16og18ks331bq@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=mcharlesr@gmail.com;X-NUM-GUESTS=0:mailto:mcharlesr@gmail.com X-MICROSOFT-CDO-OWNERAPPTID:-691422894 CLASS:PUBLIC CREATED:20190730T031302Z DESCRIPTION:\nhttps://datatracker.ietf.org/wg/cellar/meetings/\n\n-::~:~::~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~ ::-\nPlease do not edit this section of the description.\n\nView your event at https://www.google.com/calendar/event?action=VIEW&eid=M200MzhwZjNlMGJ2a DE2b2cxOGtzMzMxYnEgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbTB hOGQwMDgyZGNmM2NmYzg3MTI5NWJlY2NmMDc0MDcxZDgwMGRiNjQ&ctz=America%2FToronto& hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20190730T031302Z 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 --0000000000001fd20c058edd6331-- --0000000000001fd210058edd6333 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMTkwNzMwVDIwMDAwMFoNCkRURU5EOjIwMTkwNzMw VDIxMzAwMFoNClJSVUxFOkZSRVE9TU9OVEhMWTtVTlRJTD0yMDE5MDYyNTtCWURBWT0tMVRVDQpE VFNUQU1QOjIwMTkwNzMwVDAzMTMwNVoNCk9SR0FOSVpFUjtDTj1tY2hhcmxlc3JAZ21haWwuY29t Om1haWx0bzptY2hhcmxlc3JAZ21haWwuY29tDQpVSUQ6M200MzhwZjNlMGJ2aDE2b2cxOGtzMzMx YnFAZ29vZ2xlLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElD SVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1jZWxsYXJAaWV0Zi5v cmc7WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmNlbGxhckBpZXRmLm9yZw0KQVRURU5ERUU7Q1VUWVBF PUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JT VlA9DQogVFJVRTtDTj10dGVycmliZXJyeUBtb3ppbGxhLmNvbTtYLU5VTS1HVUVTVFM9MDptYWls dG86dHRlcnJpYmVycnlAbW96aWxsYS5jDQogb20NCkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFM O1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPUFDQ0VQVEVEO1JTVlA9VFJVRQ0KIDtDTj1t Y2hhcmxlc3JAZ21haWwuY29tO1gtTlVNLUdVRVNUUz0wOm1haWx0bzptY2hhcmxlc3JAZ21haWwu Y29tDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6LTY5MTQyMjg5NA0KQ0xBU1M6UFVCTElD DQpDUkVBVEVEOjIwMTkwNzMwVDAzMTMwMloNCkRFU0NSSVBUSU9OOlxuaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy93Zy9jZWxsYXIvbWVldGluZ3MvXG5cbi06On46fjo6fg0KIDp+On46fjp+ On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46 fjp+On46On46fg0KIDo6LVxuUGxlYXNlIGRvIG5vdCBlZGl0IHRoaXMgc2VjdGlvbiBvZiB0aGUg ZGVzY3JpcHRpb24uXG5cblZpZXcgeW91ciBldmVudA0KICBhdCBodHRwczovL3d3dy5nb29nbGUu Y29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1NMjAwTXpod1pqTmxNR0oyYQ0KIERF MmIyY3hPR3R6TXpNeFluRWdZMlZzYkdGeVFHbGxkR1l1YjNKbiZ0b2s9TVRramJXTm9ZWEpzWlhO eVFHZHRZV2xzTG1OdmJUQg0KIGhPR1F3TURneVpHTm1NMk5tWXpnM01USTVOV0psWTJObU1EYzBN RGN4WkRnd01HUmlOalEmY3R6PUFtZXJpY2ElMkZUb3JvbnRvJg0KIGhsPWVuJmVzPTEuXG4tOjp+ On46On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+ Og0KIH46fjp+On46fjp+On46fjp+Ojp+On46Oi0NCkxBU1QtTU9ESUZJRUQ6MjAxOTA3MzBUMDMx MzAyWg0KTE9DQVRJT046aHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVyaW0NClNFUVVFTkNF OjANClNUQVRVUzpDT05GSVJNRUQNClNVTU1BUlk6Y2VsbGFyLWludGVyaW0NClRSQU5TUDpPUEFR VUUNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlRoaXMgaXMgYW4g ZXZlbnQgcmVtaW5kZXINClRSSUdHRVI6LVAwRFQwSDEwTTBTDQpFTkQ6VkFMQVJNDQpFTkQ6VkVW RU5UDQpFTkQ6VkNBTEVOREFSDQo= --0000000000001fd210058edd6333-- From nobody Mon Jul 29 20:13:56 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 E24561200CE for ; Mon, 29 Jul 2019 20:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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=google.com header.b=Gzz2RxBk; dkim=pass (2048-bit key) header.d=gmail.com header.b=hL6qRUtD 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 4E5W7252ncmI for ; Mon, 29 Jul 2019 20:13:52 -0700 (PDT) Received: from mail-qk1-x74a.google.com (mail-qk1-x74a.google.com [IPv6:2607:f8b0:4864:20::74a]) (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 DC48F120044 for ; Mon, 29 Jul 2019 20:13:51 -0700 (PDT) Received: by mail-qk1-x74a.google.com with SMTP id v4so53666171qkj.10 for ; Mon, 29 Jul 2019 20:13:51 -0700 (PDT) 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=mA13Mkr9+g+7SE4GJ3XwRXja6Od5/IJTXdHMl2GndEw=; b=Gzz2RxBk53c39VdCzTG/PK0ltN7lfpupjXzDDNaV7oSHwztl0/6bJSnR9SuexG1CoZ jOySvyVTXeuZHobuJkMTk9mm57GcPmo2n7Q9EJ9e6b2HF9q6S7ZZpO3QYdOGn+nf4afx 3hEZSj3SD+KBhmTeDMTLuZ2VUG57YJkb0C0ACrc8LI9EUuYdZXwV4Bg3xeYbVWBdimY5 kc3LW3C/pEcvG65V4QqshBaZ41aGdPIAbZ2JtSfSPiHWm1nxu9ZF4za35rw5IIJbGiSS aac1UlBSnRVdnrxtLeVQMOzq52wiBF4F6VU/Hbk9ENQhkpkrd4TNN6PaSV/jGyc4gieD RPDw== 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=mA13Mkr9+g+7SE4GJ3XwRXja6Od5/IJTXdHMl2GndEw=; b=hL6qRUtD0CHynHOewtwAQDoSDwhRlPH1kvtXrFyKnEzXuBBDxLSYP3a+Ey9C23kDnw GefTmYtB3vp6uj9gGqaXPPOpCfGEz9aCVc7A/0hqtMyLk7Oepq5S1/nA8rl9+t8GC38Y t4Nd7PomQffyFelcvEQwg6qpB/EXKo8DnRTzScEvuSfF8QSxHUqLrg7Peytm63fPmKLj UR+IrVeS5i2MehsJTPx3083PNNu/aI1sj4Vnt2TrWzKAkGnxKdGaFf9LFiMjjbqVDU2O O3ark8XMbJ1ehq1lAVI+Vh0ySK/xcWoJGL8gHb6fuhobj1mmdiWQ2/FMkPRoZW1xwfug 2S6g== 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=mA13Mkr9+g+7SE4GJ3XwRXja6Od5/IJTXdHMl2GndEw=; b=AufKFPfMpCf3+V/emDjKH1vx/hsp6K8LuZJb4y1x05USdnfxxuAeGaC1wiQz5/aCG4 CkatLt1hbZukDukRwJu633t3P9v88DGCnsx8+ULB8VmzJ+mR0HMZvU3AYN/VLvS+uZPT tv/bzlCa0MFzSczqJEH9WiU5RSQsFzvAuX9QGtMNRzjkafLtILoMAzKysnWYgLSGkO5K oPwMsrwBDofOPN1HiTuJqZth+UOikHIGlNmH4WSD9zv7qwQdsHamEIJzvrRFLszyL7nA nhE2wOuMzwVmmBQNcrz/Mvc8COgyAEe0U9/ly9Jf8OTMl1QbVVt6eJ5EicSZd+RTJfWI 9aYw== X-Gm-Message-State: APjAAAWLH14TH+euHBI1/xioUQJisQ9ZITiF9WPjGw8xr6sOrGj5x+c8 AAU+B6qXR1eKM6Dk+sZnRk9CfTCmWkF+Qrj6E5w= X-Google-Smtp-Source: APXvYqz6JSbNNWnmKT5GLdgdiI9XHnQgR7MYSBeyjsx6ya03JosMZEqlZjxWiw2jSymCsXUJngIzk2Bfiq0RvK8t+FFh MIME-Version: 1.0 X-Received: by 2002:ac8:19ac:: with SMTP id u41mr77890780qtj.46.1564456430736; Mon, 29 Jul 2019 20:13:50 -0700 (PDT) Reply-To: mcharlesr@gmail.com Sender: Google Calendar Message-ID: <000000000000d22e1b058edd6553@google.com> Date: Tue, 30 Jul 2019 03:13:50 +0000 From: mcharlesr@gmail.com To: cellar@ietf.org, tterriberry@mozilla.com Content-Type: multipart/mixed; boundary="000000000000d22e04058edd6552" Archived-At: Subject: [Cellar] Invitation: cellar-interim @ Tue 2019-07-30 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: Tue, 30 Jul 2019 03:13:54 -0000 --000000000000d22e04058edd6552 Content-Type: multipart/alternative; boundary="000000000000d22e01058edd6550" --000000000000d22e01058edd6550 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBj ZWxsYXItaW50ZXJpbQ0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2NlbGxhci9t ZWV0aW5ncy8NCldoZW46IFR1ZSAyMDE5LTA3LTMwIDE2OjAwIOKAkyAxNzozMCBFYXN0ZXJuIFRp bWUgLSBUb3JvbnRvDQpXaGVyZTogaHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVyaW0NCkNh bGVuZGFyOiBjZWxsYXJAaWV0Zi5vcmcNCldobzoNCiAgICAgKiBtY2hhcmxlc3JAZ21haWwuY29t IC0gb3JnYW5pemVyDQogICAgICogY2VsbGFyQGlldGYub3JnDQogICAgICogdHRlcnJpYmVycnlA bW96aWxsYS5jb20NCg0KRXZlbnQgZGV0YWlsczogIA0KaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9j YWxlbmRhci9ldmVudD9hY3Rpb249VklFVyZlaWQ9TkRCak5qVnlNWFIxWVROdllYRTFhbTl4ZERa cWRUVnJNVElnWTJWc2JHRnlRR2xsZEdZdWIzSm4mdG9rPU1Ua2piV05vWVhKc1pYTnlRR2R0WVds c0xtTnZiVFpoWmpNMU56RXhObVEwTURFeE1ESmxNbUpoTUdFNFltWXhPRGhoWVRFMFpHSTRORGN5 WldRJmN0ej1BbWVyaWNhJTJGVG9yb250byZobD1lbiZlcz0wDQoNCkludml0YXRpb24gZnJvbSBH b29nbGUgQ2FsZW5kYXI6IGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5kYXIvDQoNCllvdSBh cmUgcmVjZWl2aW5nIHRoaXMgY291cnRlc3kgZW1haWwgYXQgdGhlIGFjY291bnQgY2VsbGFyQGll dGYub3JnICANCmJlY2F1c2UgeW91IGFyZSBhbiBhdHRlbmRlZSBvZiB0aGlzIGV2ZW50Lg0KDQpU byBzdG9wIHJlY2VpdmluZyBmdXR1cmUgdXBkYXRlcyBmb3IgdGhpcyBldmVudCwgZGVjbGluZSB0 aGlzIGV2ZW50LiAgDQpBbHRlcm5hdGl2ZWx5IHlvdSBjYW4gc2lnbiB1cCBmb3IgYSBHb29nbGUg YWNjb3VudCBhdCAgDQpodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyLyBhbmQgY29udHJv bCB5b3VyIG5vdGlmaWNhdGlvbiBzZXR0aW5ncyBmb3IgIA0KeW91ciBlbnRpcmUgY2FsZW5kYXIu DQoNCkZvcndhcmRpbmcgdGhpcyBpbnZpdGF0aW9uIGNvdWxkIGFsbG93IGFueSByZWNpcGllbnQg dG8gc2VuZCBhIHJlc3BvbnNlIHRvICANCnRoZSBvcmdhbml6ZXIgYW5kIGJlIGFkZGVkIHRvIHRo ZSBndWVzdCBsaXN0LCBvciBpbnZpdGUgb3RoZXJzIHJlZ2FyZGxlc3MgIA0Kb2YgdGhlaXIgb3du IGludml0YXRpb24gc3RhdHVzLCBvciB0byBtb2RpZnkgeW91ciBSU1ZQLiBMZWFybiBtb3JlIGF0 ICANCmh0dHBzOi8vc3VwcG9ydC5nb29nbGUuY29tL2NhbGVuZGFyL2Fuc3dlci8zNzEzNSNmb3J3 YXJkaW5nDQo= --000000000000d22e01058edd6550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

You have been invited to the follo= wing event.

cellar-interim

= When
Tue 2019-07-30 = 16:00 =E2=80=93 17:30 Eastern Time - Toronto
Where
https://appear.in/cellar-interim (map)
Calendar
cellar@ietf.org
Who
•
•
<= /td>
mcharlesr@gmail= .com - organizer
•
cellar@ietf.org
tterriberry@mozilla.com

Going (cella= r@ietf.org)?   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 send a response to the organizer and be added to the gu= est list, or invite others regardless of their own invitation status, or to= modify your RSVP. Learn More.

 --000000000000d22e01058edd6550 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:20190730T200000Z DTEND:20190730T213000Z DTSTAMP:20190730T031350Z ORGANIZER;CN=mcharlesr@gmail.com:mailto:mcharlesr@gmail.com UID:40c65r1tua3oaq5joqt6ju5k12@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=mcharlesr@gmail.com;X-NUM-GUESTS=0:mailto:mcharlesr@gmail.com X-MICROSOFT-CDO-OWNERAPPTID:-1693561598 CLASS:PUBLIC CREATED:20190730T031347Z DESCRIPTION:\nhttps://datatracker.ietf.org/wg/cellar/meetings/\n\n-::~:~::~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~ ::-\nPlease do not edit this section of the description.\n\nView your event at https://www.google.com/calendar/event?action=VIEW&eid=NDBjNjVyMXR1YTNvY XE1am9xdDZqdTVrMTIgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbTZ hZjM1NzExNmQ0MDExMDJlMmJhMGE4YmYxODhhYTE0ZGI4NDcyZWQ&ctz=America%2FToronto& hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20190730T031347Z 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 --000000000000d22e01058edd6550-- --000000000000d22e04058edd6552 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMTkwNzMwVDIwMDAwMFoNCkRURU5EOjIwMTkwNzMw VDIxMzAwMFoNCkRUU1RBTVA6MjAxOTA3MzBUMDMxMzUwWg0KT1JHQU5JWkVSO0NOPW1jaGFybGVz ckBnbWFpbC5jb206bWFpbHRvOm1jaGFybGVzckBnbWFpbC5jb20NClVJRDo0MGM2NXIxdHVhM29h cTVqb3F0Nmp1NWsxMkBnb29nbGUuY29tDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xF PVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVFO0NOPWNl bGxhckBpZXRmLm9yZztYLU5VTS1HVUVTVFM9MDptYWlsdG86Y2VsbGFyQGlldGYub3JnDQpBVFRF TkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVE Uy1BQ1RJT047UlNWUD0NCiBUUlVFO0NOPXR0ZXJyaWJlcnJ5QG1vemlsbGEuY29tO1gtTlVNLUdV RVNUUz0wOm1haWx0bzp0dGVycmliZXJyeUBtb3ppbGxhLmMNCiBvbQ0KQVRURU5ERUU7Q1VUWVBF PUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9QUNDRVBURUQ7UlNWUD1U UlVFDQogO0NOPW1jaGFybGVzckBnbWFpbC5jb207WC1OVU0tR1VFU1RTPTA6bWFpbHRvOm1jaGFy bGVzckBnbWFpbC5jb20NClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDotMTY5MzU2MTU5OA0K Q0xBU1M6UFVCTElDDQpDUkVBVEVEOjIwMTkwNzMwVDAzMTM0N1oNCkRFU0NSSVBUSU9OOlxuaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9jZWxsYXIvbWVldGluZ3MvXG5cbi06On46fjo6 fg0KIDp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46 fjp+On46fjp+On46fjp+On46On46fg0KIDo6LVxuUGxlYXNlIGRvIG5vdCBlZGl0IHRoaXMgc2Vj dGlvbiBvZiB0aGUgZGVzY3JpcHRpb24uXG5cblZpZXcgeW91ciBldmVudA0KICBhdCBodHRwczov L3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1OREJqTmpWeU1Y UjFZVE52WQ0KIFhFMWFtOXhkRFpxZFRWck1USWdZMlZzYkdGeVFHbGxkR1l1YjNKbiZ0b2s9TVRr amJXTm9ZWEpzWlhOeVFHZHRZV2xzTG1OdmJUWg0KIGhaak0xTnpFeE5tUTBNREV4TURKbE1tSmhN R0U0WW1ZeE9EaGhZVEUwWkdJNE5EY3laV1EmY3R6PUFtZXJpY2ElMkZUb3JvbnRvJg0KIGhsPWVu JmVzPTEuXG4tOjp+On46On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+ On46fjp+On46fjp+Og0KIH46fjp+On46fjp+On46fjp+Ojp+On46Oi0NCkxBU1QtTU9ESUZJRUQ6 MjAxOTA3MzBUMDMxMzQ3Wg0KTE9DQVRJT046aHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVy aW0NClNFUVVFTkNFOjANClNUQVRVUzpDT05GSVJNRUQNClNVTU1BUlk6Y2VsbGFyLWludGVyaW0N ClRSQU5TUDpPUEFRVUUNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9O OlRoaXMgaXMgYW4gZXZlbnQgcmVtaW5kZXINClRSSUdHRVI6LVAwRFQwSDEwTTBTDQpFTkQ6VkFM QVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --000000000000d22e04058edd6552-- From nobody Tue Jul 30 12:39:06 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 2719C120154; Tue, 30 Jul 2019 12:38:56 -0700 (PDT) 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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <156451553597.14280.2391290417452880308@ietfa.amsl.com> Date: Tue, 30 Jul 2019 12:38:56 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-flac-00.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: Tue, 30 Jul 2019 19:38:56 -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 : Free Lossless Audio Codec Authors : Josh Coalson Andrew Weaver Filename : draft-ietf-cellar-flac-00.txt Pages : 31 Date : 2019-07-30 Abstract: This document defines FLAC, which stands for Free Lossless Audio Codec, a free, open source codec for lossless audio compression and decompression. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-flac-00 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-flac-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 30 12:47:13 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 1A975120091 for ; Tue, 30 Jul 2019 12:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 m4SNNv5qy-G3 for ; Tue, 30 Jul 2019 12:47:07 -0700 (PDT) Received: from 7.mo7.mail-out.ovh.net (7.mo7.mail-out.ovh.net [46.105.43.131]) (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 D88BC12001E for ; Tue, 30 Jul 2019 12:47:06 -0700 (PDT) Received: from player158.ha.ovh.net (unknown [10.109.143.216]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id D118D127EAC for ; Tue, 30 Jul 2019 21:47:04 +0200 (CEST) Received: from mediaarea.net (ip-109-41-3-172.web.vodafone.de [109.41.3.172]) (Authenticated sender: jerome@mediaarea.net) by player158.ha.ovh.net (Postfix) with ESMTPSA id DECB885C14FF for ; Tue, 30 Jul 2019 19:44:23 +0000 (UTC) SavedFromEmail: jerome@mediaarea.net Date: Tue, 30 Jul 2019 21:43:03 +0200 In-Reply-To: <16478.1564421144@localhost> Importance: normal From: Jerome Martinez To: cellar@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2205361660274490" X-Ovh-Tracer-Id: 11436891255055519889 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrleefgddufeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenuc Message-Id: <20190730194706.D88BC12001E@ietfa.amsl.com> Archived-At: Subject: Re: [Cellar] AGENDA 2019-07-30 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: Tue, 30 Jul 2019 19:47:12 -0000 ----_com.samsung.android.email_2205361660274490 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QXBvbG9naWVzIGJ1dCBJJ2xsIG5vdCBiZSBhYmxlIHRvIGpvaW4gdGhlIG1lZXRpbmcgdGhpcyB0 aW1lLkRyYWZ0IG1pbnV0ZXMgZnJvbSBsYXN0IG1lZXRpbmcgYXJlIGZpbmUgZm9yIG1lLCBhbmQg YXMgdXN1YWwgbXkgcXVlc3Rpb25zIHRvZGF5IHdvdWxkIGJlIGFib3V0IHRoZSBmb2xsb3cgdXAg b2YgZmZ2MSBzcGVjIHN0YXR1cy5Kw6lyw7RtZcKgU2VudCBmcm9tIG15IHNtYXJ0cGhvbmUKLS0t LS0tLS0gTWVzc2FnZSBkJ29yaWdpbmUgLS0tLS0tLS1EZSA6IE1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK2lldGZAc2FuZGVsbWFuLmNhPiBEYXRlIDogMjkvMDcvMjAxOSAgMTk6MjUgIChHTVQrMDE6 MDApIMOAIDogY2VsbGFyQGlldGYub3JnIE9iamV0IDogW0NlbGxhcl0gQUdFTkRBIDIwMTktMDct MzAgVmlydHVhbCBJbnRlcmltIG1lZXRpbmcgQ0VMTEFSIC0tIERSQUZUIEFHRU5EQSBmb3IgVmly dHVhbCBJbnRlcmltIE1lZXRpbmdKdWx5IDMwLCAyMDE5wqDCoMKgwqDCoMKgwqAgMjA6MDAgVVRD SU5GTzrCoMKgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIw MTktY2VsbGFyLTA2L3Nlc3Npb24vY2VsbGFywqDCoCBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9hZ2VuZGEtaW50ZXJpbS0yMDE5LWNlbGxhci0wNi1zZXNzYS9XRUIgQ09ORkVSRU5D RTrCoMKgIGh0dHBzOi8vYXBwZWFyLmluL2NlbGxhci1pbnRlcmltwqDCoCBUSEVSRSBJUyBOTyBU RUxFUEhPTkUgRElBTElOIChZb3UgY2FuIHRyeSB0aGlzIGF0IGFueSB0aW1lLinCoMKgIFRoZXNl IG5vdGVzIGF0OiBodHRwczovL2dpdGh1Yi5jb20vY2VsbGFyLXdnL2NoYWlyLW5vdGVzMS4gTm90 ZSBXZWxsLjIuIEFjY2VwdCBkcmFmdCBtaW51dGVzIGZyb20gSnVuZSAyNSBtZWV0aW5nIChhdHRh Y2hlZCBiZWxvdykzLiBMb2dpc3RpY3MgZm9yIE1lZXRpbmcuwqDCoCAyYSkgRXRoZXJwYWQgZm9y IG5vdGVzwqDCoMKgwqDCoMKgIGh0dHBzOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9ub3Rl cy1jZWxsYXItdmlydHVhbD91c2VNb25vc3BhY2VGb250PXRydWXCoMKgIDJiKSBBUFBFQVIuSU4g Zm9yIHZpZGVvIGFuZCBzY3JlZW4gc2hhcmluZy7CoMKgwqDCoMKgwqAgaHR0cHM6Ly9hcHBlYXIu aW4vY2VsbGFyLWludGVyaW3CoMKgIDJjKSBSb2xsIGNhbGw0LiBXRyBzdGF0dXMgdXBkYXRlwqDC oCAqIEVCTUwgLS0gc3RpbGwgd2FpdGluZyBvbiByZXZpc2VkIC0xMSBkb2N1bWVudCBmb3IgQUQg ZXZhbHVhdGlvbi5BQ1RJT04gZnJvbSBsYXN0IHRpbWU6wqDCoMKgwqDCoMKgIAk9PT4gaXNzdWUg IzI1NywgcmVxdWVzdGVkIG9uZSBtb3JlIGRheSB0byB0aGluayBhYm91dCBpdC4gVGhlIGNoYW5n ZXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGFyZSBmaW5lIGluIGdlbmVyYWwsIGJ1dCB3YW50IHRv IG1ha2Ugc3VyZSBpdCBwcmVjaXNlIGVub3VnaC4gKE1CKSDCoMKgICogVGhhbmsgZm9yIHJlcG9z dGluZyBvZiBkcmFmdC1pZXRmLWNlbGxhci10YWdzLTAyLMKgwqDCoMKgwqDCoMKgwqAgZHJhZnQt aWV0Zi1jZWxsYXItbWF0cm9za2EtMDPCoCBhbmQgZHJhZnQtaWV0Zi1jZWxsYXItY29kZWMtMDLC oMKgICogVGhlIHBlcnNvbmFsIGRyYWZ0LXdlYXZlci1jZWxsYXItZmxhYy0wMCBkaWQgbm90IGdl dCByZXBvc3RlZC7CoMKgwqDCoCBJIGJlbGlldmUgdGhhdCB3ZSBhZG9wdGVkIGl0LCBzbyBpdCBz aG91bGQgaGF2ZSBiZWVuIHJlcG9zdGVkIHdpdGggYcKgwqDCoMKgIGRyYWZ0LWlldGYtY2VsbGFy LWZsYWMtMDAhNS4gQW55IHJlbWluaW5nIEVCTUwgaXNzdWVzLjUuIFdvcmsgb24gTWF0cm9za2Eg aXNzdWVzLjYuIEFueSBvdGhlciBidXNpbmVzcy49PT09CUNFTExBUiAtLSBEUkFGVCBNSU5VVEVT IGZvciBWaXJ0dWFsIEludGVyaW0gTWVldGluZwlKdW5lIDI1LCAyMDE5wqDCoMKgwqDCoMKgwqAg MjA6MDAgVVRDCQlJTkZPOgnCoMKgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy9pbnRlcmltLTIwMTktY2VsbGFyLTA1L3Nlc3Npb24vY2VsbGFyCcKgwqAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvYWdlbmRhLWludGVyaW0tMjAxOS1jZWxsYXItMDUtc2Vzc2Ev CQlXRUIgQ09ORkVSRU5DRToJwqDCoCBodHRwczovL2FwcGVhci5pbi9jZWxsYXItaW50ZXJpbQnC oMKgIFRIRVJFIElTIE5PIFRFTEVQSE9ORSBESUFMSU4gKFlvdSBjYW4gdHJ5IHRoaXMgYXQgYW55 IHRpbWUuKQnCoMKgIFRoZXNlIG5vdGVzIGF0OiBodHRwczovL2dpdGh1Yi5jb20vY2VsbGFyLXdn L2NoYWlyLW5vdGVzCQkJUHJlc2VudDoJCTEpIE1pY2hhZWwgUmljaGFyZHNvbgkJMikgTW9yaXR6 IEJ1bmt1cwkJMykgTWFydGluIEJlbG93CQk0KSBTdGV2ZSBMaG9tbWUJCTUpIERhdmUgUmljZQkJ NikgSsOpcsO0bWUgTWFydGluZXoJCVJlZ3JldHM6wqDCoMKgIDEpIFJldG8gS3JvbWVyCQkxLiBO b3RlIFdlbGwuCTIuIEFjY2VwdCBkcmFmdCBtaW51dGVzIGZyb20gTWF5IDI4IG1lZXRpbmcJCWFj Y2VwdGVkIHdpdGhvdXQgY2hhbmdlLgkJMy4gTG9naXN0aWNzIGZvciBNZWV0aW5nLgnCoMKgIDJh KSBFdGhlcnBhZCBmb3Igbm90ZXMJwqDCoMKgwqDCoMKgIGh0dHBzOi8vZXRoZXJwYWQudG9vbHMu aWV0Zi5vcmcvcC9ub3Rlcy1jZWxsYXItdmlydHVhbD91c2VNb25vc3BhY2VGb250PXRydWUJCcKg wqAgMmIpIEFQUEVBUi5JTiBmb3IgdmlkZW8gYW5kIHNjcmVlbiBzaGFyaW5nLgnCoMKgwqDCoMKg wqAgaHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVyaW0JCcKgwqAgMmMpIFJvbGwgY2FsbAk0 LiBXRyBzdGF0dXMgdXBkYXRlCcKgwqAgKiBNQ1Igc3RpbGwgbmVlZCB0byBoZWxwIE1hcnRpbiBv biBsYXJnZSBwdWxsIHJlcXVlc3QuCcKgwqAgKiBFQk1MIGNoYW5nZXMuLi4gZG9uZS4JCSsgaXNz dWUgIzI1NywgcmVxdWVzdGVkIG9uZSBtb3JlIGRheSB0byB0aGluayBhYm91dCBpdC4gVGhlIGNo YW5nZXMgYXJlIGZpbmUgaW4gZ2VuZXJhbCwgYnV0IHdhbnQgdG8gbWFrZSBzdXJlIGl0IHByZWNp c2UgZW5vdWdoLiAoTUIpCcKgwqAgKiBmZnYxIGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBJRVNHIGJ5 IEFELgk1LiBXb3JrIG9uIE1hdHJvc2thIGlzc3Vlcy4JwqDCoMKgwqDCoCA0OCBvcGVuIGlzc3Vl cwnCoMKgwqDCoMKgIDIxIG9wZW4gcHVsbCByZXF1ZXN0cwkJaHR0cHM6Ly9naXRodWIuY29tL2Nl bGxhci13Zy9tYXRyb3NrYS1zcGVjaWZpY2F0aW9uL2lzc3VlcwkJCQlOZXh0IHRpbWUsIFN0ZXZl IHdpbGwgd2FsayB1cyB0aHJvdWdoIFhTTFQgY29kZSB0byB2YWxpZGF0ZSB0aGUgc3BlY2lmaWNh dGlvbi5UQUc6wqDCoMKgwqAgImZvcm1hdCBleHRlbnNpb24iwqDCoCBzdWdnZXN0aW9uIHRoYXQg ZG9lcyBub3QgaGF2ZSB0byBnbyBpbnRvIHRoZSBtYWluIHNwZWMsIGJlY2F1c2UgaXQgY291bGQg YmUgYWRkZWQgYXMgc2VwYXJhdGUgc3BlY8KgwqAgaHR0cHM6Ly9naXRodWIuY29tL2NlbGxhci13 Zy9tYXRyb3NrYS1zcGVjaWZpY2F0aW9uL2lzc3Vlcz9xPWlzJTNBaXNzdWUraXMlM0FvcGVuK2xh YmVsJTNBJTIyZm9ybWF0K2V4dGVuc2lvbiUyMgkiZm9ybWF0IGFkZGl0aW9uIsKgwqDCoMKgIHNv bWV0aGluZyB0aGF0IGhhcyB0byBnbyBpbnRvIG1haW4gc3BlY2lmaWNhdGlvbi7CoMKgIGh0dHBz Oi8vZ2l0aHViLmNvbS9jZWxsYXItd2cvbWF0cm9za2Etc3BlY2lmaWNhdGlvbi9pc3N1ZXM/cT1p cyUzQWlzc3VlK2lzJTNBb3BlbitsYWJlbCUzQSUyMmZvcm1hdCthZGRpdGlvbiUyMgkqIEFzIHRo ZSBXZWJNIHdpbGwgbm90IGJlIGRlZmluZWQsIHJlbW92ZSBhbGwgb2YgdGhlIFdlYk0gc3BlY2lm aWMgc3R1ZmYuCSogTUNSIHN1Z2dlc3RzIHJlbW92aW5nIGl0IGZyb20gdGhlIE1hdHJvc2thIGRv Y3VtZW50LCBhbmQgbGVhdmUgdGhlIGhpc3RvcnkgZm9yIG90aGVycy4JKiBNQjogRGl2WCBpcyBh bHNvIG5vdCBwYXJ0IG9mIE1hdHJvc2thLsKgIEFsc28gY29uY2VybmVkIGFib3V0IGhvdyB0aGUg TWF0cm9za2EgcHJvamVjdCBwcmVzZW50cyB0aGUgV2ViTS9EaVZYIHZzIGNvcmUgTWF0cm9za2Eg ZWxlbWVudHMuwqDCoCBUaGUgc3BlYyB3aWxsIGJlIGh1Z2UsIHNvIHRha2UgdGhpbmdzIG91dC4q IGRlZmluZSBob3cgdG8gYWRkIHVucHJlZGljdGFibGUgZGF0YSB0byB0aGUgTWF0cm9za2EsIHNv IHdlIGNvdWxkIHRyYWNrIHRoaW5ncyB0aGF0IGFyZSBhZGRlZC7CoCBOb3QganVzdCBXZWJNLCBi dXQgYWxzbyBhIGxpYm1vdHJzYWthIGFzIHdlbGwuKiBleHRlbnNpb24gZGF0YSB3b3VsZCBiZSBv biB0aGVpciBvd24gbGluZXMsIGFuZCByZXZpc2lvbiBoaXN0b3J5IHdvdWxkIGJlIGNsZWFybHku CQkJNi4gQW55IG90aGVyIGJ1c2luZXNzLgkJCQkJCQkJCQkJCT09PT0JQ0VMTEFSIC0tIERSQUZU IE1JTlVURVMgZm9yIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nCU1heSAyOCwgMjAxOcKgwqDCoMKg wqDCoMKgIDIwOjAwIFVUQwkJSU5GTzoJwqDCoCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvaW50ZXJpbS0yMDE5LWNlbGxhci0wNC9zZXNzaW9uL2NlbGxhcgnCoMKgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2FnZW5kYS1pbnRlcmltLTIwMTktY2VsbGFyLTA0 LXNlc3NhLwkJV0VCIENPTkZFUkVOQ0U6CcKgwqAgaHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWlu dGVyaW0JwqDCoCBUSEVSRSBJUyBOTyBURUxFUEhPTkUgRElBTElOCcKgwqAgWW91IGNhbiB0cnkg dGhpcyBhdCBhbnkgdGltZS4JwqDCoCBUaGVzZSBub3RlcyBhdDogaHR0cHM6Ly9naXRodWIuY29t L2NlbGxhci13Zy9jaGFpci1ub3RlcwkJUHJlc2VudDoJwqDCoMKgwqDCoMKgwqAgMSkgbWljaGFl bCByaWNoYXJkc29uCcKgwqDCoMKgwqDCoMKgIDIpIFN0ZXZlIExob21tZQnCoMKgwqDCoMKgwqDC oCAzKSBNYXJ0aW4gQmVsb3cJwqDCoMKgwqDCoMKgwqAgNCkgSmVyb21lIE1hcnRpbmV6CcKgwqDC oMKgwqDCoMKgIDUpIERhdmUgUmljZQnCoMKgwqDCoMKgwqDCoCA2KcKgIE1pY2hhZWwgTmllZGVy bWF5ZXIJCVByb3Bvc2VkIEFnZW5kYToJCTEuIE5vdGUgV2VsbC4JMi4gQWNjZXB0IGRyYWZ0IG1p bnV0ZXMgZnJvbSBBcHJpbCAyIG1lZXRpbmcJCTMuIExvZ2lzdGljcyBmb3IgTWVldGluZy4JwqDC oCAyYSkgRXRoZXJwYWQgZm9yIG5vdGVzCcKgwqDCoMKgwqDCoCBodHRwczovL2V0aGVycGFkLnRv b2xzLmlldGYub3JnL3Avbm90ZXMtY2VsbGFyLXZpcnR1YWw/dXNlTW9ub3NwYWNlRm9udD10cnVl CQnCoMKgIDJiKSBBUFBFQVIuSU4gZm9yIHZpZGVvIGFuZCBzY3JlZW4gc2hhcmluZy4JwqDCoMKg wqDCoMKgIGh0dHBzOi8vYXBwZWFyLmluL2NlbGxhci1pbnRlcmltCcKgwqDCoMKgwqDCoCAoYXMg YWdyZWVkIGxhc3QgbWVldGluZykJCcKgwqAgMmMpIFJvbGwgY2FsbAkJNC4gV0cgc3RhdHVzIHVw ZGF0ZQnCoMKgIC0gRUJNTCBzZWVtcyB0byBiZSBnZXR0aW5nIHNvbWUgYWRkaXRpb25hbCBlZGl0 cywgaXMgaXQgZG9uZT8JwqDCoMKgwqAgVGhlc2Ugd2VyZSB0aGUgaXNzdWVzIHRoYXQgYXJlIHdh aXRpbmcgZm9yIGNsYXJpZmljYXRpb246CcKgwqDCoMKgwqDCoMKgIGh0dHBzOi8vZ2l0aHViLmNv bS9NYXRyb3NrYS1PcmcvZWJtbC1zcGVjaWZpY2F0aW9uL2lzc3Vlcz9xPWlzJTNBaXNzdWUraXMl M0FvcGVuK2xhYmVsJTNBY2xhcmlmaWNhdGlvbnMJwqDCoMKgwqAgV2Ugc3RpbGwgaGF2ZSBhIGZl dyBvcGVuLsKgIENhbiB3ZSBjbG9zZSB0aGVtIG5vdz8JwqDCoMKgwqAgRGF2ZSBSaWNlIGV4cGVj dGVkIHRvIHB1c2ggdmVyc2lvbiAxMC4uLi4JwqDCoMKgwqAgVkVSU0lPTiAxMCByZWxlYXNlZCAy MDE5LTA1LTI4IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNl bGxhci1lYm1sLzEwLykuwqAgTWVyZ2VkIG1hbnkgaXNzdWVzLgnCoMKgwqDCoCBUaGlzIGFkZHJl c3NlcyBBRCBpc3N1ZXMgZnJvbSBCZW4gQ2FtcGJlbGwgYW5kIFJvYmVydCBTcGFya3MuLi4uIHJl bWFpbmluZyAyCcKgwqDCoMKgwqAgMTEuMS4xMS7CoCBYTUwgU2NoZW1hIGZvciBFQk1MIFNjaGVt YSAoRGF2ZSB2b2x1bnRlZXJzIHRvIGNvbXBsZXRlIHRoaXMpCcKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgVGhlIGZvbGxvd2luZyAiWFNEIiBkZWZpbml0aW9uIGlzIGluIDxGT1JNQVQ+IChhZGQgVzND IGNpdGF0aW9uKSwgYW5kIGNhbiBiZSB1c2VkIHRvIHZhbGlkYXRlIGFuIEVCTUwgU2NoZW1hIHVz aW5nIDxUT09MPgkJwqDCoMKgwqDCoMKgwqAgVGhlIHVzZSBvZiB1bmtub3duLXNpemUgcmVxdWly ZXMgdG8ga25vdyB0aGUgRUJNTCBTY2hlbWEuIEFkZCBhbiBleGFtcGxlIG9mIHVua25vd24tc2l6 ZSBlbGVtZW50LgkJTWljaGFlbCB3aWxsIGNvbnRhY3QgTWFydGluIGluIHRoZSBjb21pbmcgZGF5 cy93ZWVrcyB0byB3b3JrIG9uIGhpcyBsYXJnZSBjaGFwdGVyIHB1bGwgcmVxdWVzdC4JCTUuIE1h dHJvc2thIGRvY3VtZW50IGNoYW5nZXMgc2luY2UgbGFzdCBtZWV0aW5nLgnCoMKgIGh0dHBzOi8v Z2l0aHViLmNvbS9jZWxsYXItd2cvbWF0cm9za2Etc3BlY2lmaWNhdGlvbi9pc3N1ZXMJwqDCoCBD YW4gd2UgY2xvc2Ugc29tZSBvZiB0aGVzZSwgYW5kL29yIGdldCB0aGVtIHNvcnRlZCBhbmQgcHJp b3JpdGl6ZWQ/CQnCoMKgIGEpIERhdmUgUmljZSB0byBwb3N0IHJlcXVlc3QgZm9yIHZvbHVudGVl cnMsIG9mZmVycyB0byBtZW50b3IuCcKgwqAgYikgTUNSIHRvIG1lbnRvciBNYXJ0aW4gb24gZ2l0 aHViLWZ1CcKgwqAgYykgYWxsIHRvIHJldmlldyBwdWxsIHJlcXVlc3RzIG9uIE1hdHJvc2thLCBs b29rIGZvciBjb25mbGljdHMgYW5kICpkaXNjdXNzaW9uKiAobmV3IHRhZykgdGhhdCB3ZSBjYW4g Z28gdGhyb3VnaCBuZXh0IHRpbWUuCcKgwqAgZCkgTUNSIHRvIHBpbmcgTW9yaXR6IGFib3V0IG5l eHQgdGltZS4JCTYuIFN0YXJ0ZWQgNC13ZWVrIGFkb3B0aW5nIGNhbGwgZm9yIEZyZWUgTG9zc2xl c3MgQXVkaW8gQ29kZWMJwqDCoMKgwqDCoCBkcmFmdC13ZWF2ZXItY2VsbGFyLWZsYWMtMDAJwqDC oCB3aWxsIGVuZCBhdCBuZXh0IHZpcnR1YWwtaW50ZXJpbSBtZWV0aW5nLgkJwqDCoMKgwqDCoMKg wqDCoMKgwqAgcGxlYXNlIHBvc3QgeW91ciBvcGluaW9uIGFib3V0IHRoZSBkb2N1bWVudD8gRG9l cyBpdCBmaXQgaW50byB3aGF0IHRoZSBjaGFydGVyIGFza2VkIGZvcj8JCVE6IGZmdjEuIGxhc3Qg bWVldGluZyBuZXcgQUQ/CUE6IHdlIGFyZSB3YWl0aW5nIGZvciBmZWVkYmFjay4JQUNUSU9OOiBt Y3IgdG8gYnVnIEFEIGFib3V0IGZmdjEuCQltZWV0aW5nIGVuZGVkIDE2OjU1LgkJCQktLSBNaWNo YWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2Fy ZSBXb3JrcyAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19DZWxsYXIgbWFpbGluZyBsaXN0Q2VsbGFyQGlldGYub3Jn aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZWxsYXI= ----_com.samsung.android.email_2205361660274490 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5BcG9sb2dpZXMgYnV0IEknbGwgbm90IGJlIGFibGUgdG8gam9pbiB0aGUgbWVldGluZyB0 aGlzIHRpbWUuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPkRyYWZ0IG1pbnV0ZXMgZnJvbSBsYXN0IG1l ZXRpbmcgYXJlIGZpbmUgZm9yIG1lLCBhbmQgYXMgdXN1YWwgbXkgcXVlc3Rpb25zIHRvZGF5IHdv dWxkIGJlIGFib3V0IHRoZSBmb2xsb3cgdXAgb2YgZmZ2MSBzcGVjIHN0YXR1cy48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5Kw6lyw7RtZSZuYnNwOzwvZGl2 PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSIgZGlyPSJh dXRvIj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD1VVEYtOCI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3Ij5T ZW50IGZyb20gbXkgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiIGRpcj0iYXV0byI+PC9kaXY+PGRpdiBz dHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCIgZGlyPSJhdXRvIj48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIiBkaXI9ImF1dG8iPjwhLS0gb3Jp Z2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gTWVzc2FnZSBkJ29yaWdpbmUgLS0tLS0tLS08 L2Rpdj48ZGl2PkRlIDogTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3IraWV0ZkBzYW5kZWxtYW4u Y2EmZ3Q7IDwvZGl2PjxkaXY+RGF0ZSA6IDI5LzA3LzIwMTkgIDE5OjI1ICAoR01UKzAxOjAwKSA8 L2Rpdj48ZGl2PsOAIDogY2VsbGFyQGlldGYub3JnIDwvZGl2PjxkaXY+T2JqZXQgOiBbQ2VsbGFy XSBBR0VOREEgMjAxOS0wNy0zMCBWaXJ0dWFsIEludGVyaW0gbWVldGluZyA8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48L2Rpdj48YnI+Q0VMTEFSIC0tIERSQUZUIEFHRU5EQSBmb3IgVmlydHVhbCBJbnRl cmltIE1lZXRpbmc8YnI+SnVseSAzMCwgMjAxOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAyMDowMCBVVEM8YnI+PGJyPklORk86PGJyPiZuYnNwOyZuYnNwOyBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5LWNlbGxhci0wNi9z ZXNzaW9uL2NlbGxhcjxicj4mbmJzcDsmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvYWdlbmRhLWludGVyaW0tMjAxOS1jZWxsYXItMDYtc2Vzc2EvPGJyPjxicj5XRUIgQ09O RkVSRU5DRTo8YnI+Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vYXBwZWFyLmluL2NlbGxhci1pbnRlcmlt PGJyPiZuYnNwOyZuYnNwOyBUSEVSRSBJUyBOTyBURUxFUEhPTkUgRElBTElOIChZb3UgY2FuIHRy eSB0aGlzIGF0IGFueSB0aW1lLik8YnI+Jm5ic3A7Jm5ic3A7IFRoZXNlIG5vdGVzIGF0OiBodHRw czovL2dpdGh1Yi5jb20vY2VsbGFyLXdnL2NoYWlyLW5vdGVzPGJyPjxicj4xLiBOb3RlIFdlbGwu PGJyPjIuIEFjY2VwdCBkcmFmdCBtaW51dGVzIGZyb20gSnVuZSAyNSBtZWV0aW5nIChhdHRhY2hl ZCBiZWxvdyk8YnI+PGJyPjMuIExvZ2lzdGljcyBmb3IgTWVldGluZy48YnI+Jm5ic3A7Jm5ic3A7 IDJhKSBFdGhlcnBhZCBmb3Igbm90ZXM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGh0dHBzOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9ub3Rlcy1jZWxsYXItdmly dHVhbD91c2VNb25vc3BhY2VGb250PXRydWU8YnI+PGJyPiZuYnNwOyZuYnNwOyAyYikgQVBQRUFS LklOIGZvciB2aWRlbyBhbmQgc2NyZWVuIHNoYXJpbmcuPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBodHRwczovL2FwcGVhci5pbi9jZWxsYXItaW50ZXJpbTxicj48YnI+ Jm5ic3A7Jm5ic3A7IDJjKSBSb2xsIGNhbGw8YnI+PGJyPjQuIFdHIHN0YXR1cyB1cGRhdGU8YnI+ Jm5ic3A7Jm5ic3A7ICogRUJNTCAtLSBzdGlsbCB3YWl0aW5nIG9uIHJldmlzZWQgLTExIGRvY3Vt ZW50IGZvciBBRCBldmFsdWF0aW9uLjxicj5BQ1RJT04gZnJvbSBsYXN0IHRpbWU6PGJyPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAJPT0mZ3Q7IGlzc3VlICMyNTcsIHJlcXVl c3RlZCBvbmUgbW9yZSBkYXkgdG8gdGhpbmsgYWJvdXQgaXQuIFRoZSBjaGFuZ2VzPGJyPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBhcmUgZmluZSBpbiBnZW5lcmFsLCBidXQgd2FudCB0byBtYWtlIHN1cmUgaXQgcHJlY2lz ZSBlbm91Z2guIChNQikgPGJyPjxicj4mbmJzcDsmbmJzcDsgKiBUaGFuayBmb3IgcmVwb3N0aW5n IG9mIGRyYWZ0LWlldGYtY2VsbGFyLXRhZ3MtMDIsPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLWNlbGxhci1tYXRyb3NrYS0wMyZu YnNwOyBhbmQgZHJhZnQtaWV0Zi1jZWxsYXItY29kZWMtMDI8YnI+Jm5ic3A7Jm5ic3A7ICogVGhl IHBlcnNvbmFsIGRyYWZ0LXdlYXZlci1jZWxsYXItZmxhYy0wMCBkaWQgbm90IGdldCByZXBvc3Rl ZC48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYmVsaWV2ZSB0aGF0IHdlIGFkb3B0ZWQg aXQsIHNvIGl0IHNob3VsZCBoYXZlIGJlZW4gcmVwb3N0ZWQgd2l0aCBhPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLWNlbGxhci1mbGFjLTAwITxicj48YnI+NS4gQW55IHJl bWluaW5nIEVCTUwgaXNzdWVzLjxicj48YnI+NS4gV29yayBvbiBNYXRyb3NrYSBpc3N1ZXMuPGJy Pjxicj42LiBBbnkgb3RoZXIgYnVzaW5lc3MuPGJyPjxicj49PT09PGJyPglDRUxMQVIgLS0gRFJB RlQgTUlOVVRFUyBmb3IgVmlydHVhbCBJbnRlcmltIE1lZXRpbmc8YnI+CUp1bmUgMjUsIDIwMTkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjA6MDAgVVRDPGJyPgk8 YnI+CUlORk86PGJyPgkmbmJzcDsmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nL2ludGVyaW0tMjAxOS1jZWxsYXItMDUvc2Vzc2lvbi9jZWxsYXI8YnI+CSZuYnNwOyZu YnNwOyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9hZ2VuZGEtaW50ZXJpbS0yMDE5 LWNlbGxhci0wNS1zZXNzYS88YnI+CTxicj4JV0VCIENPTkZFUkVOQ0U6PGJyPgkmbmJzcDsmbmJz cDsgaHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVyaW08YnI+CSZuYnNwOyZuYnNwOyBUSEVS RSBJUyBOTyBURUxFUEhPTkUgRElBTElOIChZb3UgY2FuIHRyeSB0aGlzIGF0IGFueSB0aW1lLik8 YnI+CSZuYnNwOyZuYnNwOyBUaGVzZSBub3RlcyBhdDogaHR0cHM6Ly9naXRodWIuY29tL2NlbGxh ci13Zy9jaGFpci1ub3Rlczxicj4JPGJyPgk8YnI+CVByZXNlbnQ6PGJyPgkJMSkgTWljaGFlbCBS aWNoYXJkc29uPGJyPgkJMikgTW9yaXR6IEJ1bmt1czxicj4JCTMpIE1hcnRpbiBCZWxvdzxicj4J CTQpIFN0ZXZlIExob21tZTxicj4JCTUpIERhdmUgUmljZTxicj4JCTYpIErDqXLDtG1lIE1hcnRp bmV6PGJyPgkJPGJyPlJlZ3JldHM6PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAxKSBSZXRvIEtyb21l cjxicj48YnI+CTxicj4JMS4gTm90ZSBXZWxsLjxicj4JMi4gQWNjZXB0IGRyYWZ0IG1pbnV0ZXMg ZnJvbSBNYXkgMjggbWVldGluZzxicj4JCWFjY2VwdGVkIHdpdGhvdXQgY2hhbmdlLjxicj4JPGJy PgkzLiBMb2dpc3RpY3MgZm9yIE1lZXRpbmcuPGJyPgkmbmJzcDsmbmJzcDsgMmEpIEV0aGVycGFk IGZvciBub3Rlczxicj4JJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBz Oi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9ub3Rlcy1jZWxsYXItdmlydHVhbD91c2VNb25v c3BhY2VGb250PXRydWU8YnI+CTxicj4JJm5ic3A7Jm5ic3A7IDJiKSBBUFBFQVIuSU4gZm9yIHZp ZGVvIGFuZCBzY3JlZW4gc2hhcmluZy48YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBodHRwczovL2FwcGVhci5pbi9jZWxsYXItaW50ZXJpbTxicj4JPGJyPgkmbmJzcDsm bmJzcDsgMmMpIFJvbGwgY2FsbDxicj4JPGJyPjQuIFdHIHN0YXR1cyB1cGRhdGU8YnI+CSZuYnNw OyZuYnNwOyAqIE1DUiBzdGlsbCBuZWVkIHRvIGhlbHAgTWFydGluIG9uIGxhcmdlIHB1bGwgcmVx dWVzdC48YnI+CSZuYnNwOyZuYnNwOyAqIEVCTUwgY2hhbmdlcy4uLiBkb25lLjxicj4JCSsgaXNz dWUgIzI1NywgcmVxdWVzdGVkIG9uZSBtb3JlIGRheSB0byB0aGluayBhYm91dCBpdC4gVGhlIGNo YW5nZXMgYXJlIGZpbmUgaW4gZ2VuZXJhbCwgYnV0IHdhbnQgdG8gbWFrZSBzdXJlIGl0IHByZWNp c2UgZW5vdWdoLiAoTUIpPGJyPgkmbmJzcDsmbmJzcDsgKiBmZnYxIGhhcyBiZWVuIHN1Ym1pdHRl ZCB0byBJRVNHIGJ5IEFELjxicj4JPGJyPjUuIFdvcmsgb24gTWF0cm9za2EgaXNzdWVzLjxicj4J Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ4IG9wZW4gaXNzdWVzPGJyPgkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjEgb3BlbiBwdWxsIHJlcXVlc3RzPGJyPgkJaHR0cHM6 Ly9naXRodWIuY29tL2NlbGxhci13Zy9tYXRyb3NrYS1zcGVjaWZpY2F0aW9uL2lzc3Vlczxicj4J CTxicj4JCU5leHQgdGltZSwgU3RldmUgd2lsbCB3YWxrIHVzIHRocm91Z2ggWFNMVCBjb2RlIHRv IHZhbGlkYXRlIHRoZSBzcGVjaWZpY2F0aW9uLjxicj5UQUc6PGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAiZm9ybWF0IGV4dGVuc2lvbiImbmJzcDsmbmJzcDsgc3VnZ2VzdGlvbiB0aGF0IGRv ZXMgbm90IGhhdmUgdG8gZ28gaW50byB0aGUgbWFpbiBzcGVjLCBiZWNhdXNlIGl0IGNvdWxkIGJl IGFkZGVkIGFzIHNlcGFyYXRlIHNwZWMmbmJzcDsmbmJzcDsgaHR0cHM6Ly9naXRodWIuY29tL2Nl bGxhci13Zy9tYXRyb3NrYS1zcGVjaWZpY2F0aW9uL2lzc3Vlcz9xPWlzJTNBaXNzdWUraXMlM0Fv cGVuK2xhYmVsJTNBJTIyZm9ybWF0K2V4dGVuc2lvbiUyMjxicj4JImZvcm1hdCBhZGRpdGlvbiIm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc29tZXRoaW5nIHRoYXQgaGFzIHRvIGdvIGludG8gbWFp biBzcGVjaWZpY2F0aW9uLiZuYnNwOyZuYnNwOyBodHRwczovL2dpdGh1Yi5jb20vY2VsbGFyLXdn L21hdHJvc2thLXNwZWNpZmljYXRpb24vaXNzdWVzP3E9aXMlM0Fpc3N1ZStpcyUzQW9wZW4rbGFi ZWwlM0ElMjJmb3JtYXQrYWRkaXRpb24lMjI8YnI+CTxicj4qIEFzIHRoZSBXZWJNIHdpbGwgbm90 IGJlIGRlZmluZWQsIHJlbW92ZSBhbGwgb2YgdGhlIFdlYk0gc3BlY2lmaWMgc3R1ZmYuPGJyPgkq IE1DUiBzdWdnZXN0cyByZW1vdmluZyBpdCBmcm9tIHRoZSBNYXRyb3NrYSBkb2N1bWVudCwgYW5k IGxlYXZlIHRoZSBoaXN0b3J5IGZvciBvdGhlcnMuPGJyPgkqIE1COiBEaXZYIGlzIGFsc28gbm90 IHBhcnQgb2YgTWF0cm9za2EuJm5ic3A7IEFsc28gY29uY2VybmVkIGFib3V0IGhvdyB0aGUgTWF0 cm9za2EgcHJvamVjdCBwcmVzZW50cyB0aGUgV2ViTS9EaVZYIHZzIGNvcmUgTWF0cm9za2EgZWxl bWVudHMuJm5ic3A7Jm5ic3A7IFRoZSBzcGVjIHdpbGwgYmUgaHVnZSwgc28gdGFrZSB0aGluZ3Mg b3V0Ljxicj48YnI+KiBkZWZpbmUgaG93IHRvIGFkZCB1bnByZWRpY3RhYmxlIGRhdGEgdG8gdGhl IE1hdHJvc2thLCBzbyB3ZSBjb3VsZCB0cmFjayB0aGluZ3MgdGhhdCBhcmUgYWRkZWQuJm5ic3A7 IE5vdCBqdXN0IFdlYk0sIGJ1dCBhbHNvIGEgbGlibW90cnNha2EgYXMgd2VsbC48YnI+KiBleHRl bnNpb24gZGF0YSB3b3VsZCBiZSBvbiB0aGVpciBvd24gbGluZXMsIGFuZCByZXZpc2lvbiBoaXN0 b3J5IHdvdWxkIGJlIGNsZWFybHkuPGJyPjxicj4JCTxicj4JNi4gQW55IG90aGVyIGJ1c2luZXNz Ljxicj4JPGJyPgk8YnI+CTxicj4JPGJyPgk8YnI+CTxicj4JPGJyPgk8YnI+CTxicj4JPGJyPgk8 YnI+CT09PT08YnI+CUNFTExBUiAtLSBEUkFGVCBNSU5VVEVTIGZvciBWaXJ0dWFsIEludGVyaW0g TWVldGluZzxicj4JTWF5IDI4LCAyMDE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDIwOjAwIFVUQzxicj4JPGJyPglJTkZPOjxicj4JJm5ic3A7Jm5ic3A7IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktY2VsbGFyLTA0L3Nl c3Npb24vY2VsbGFyPGJyPgkmbmJzcDsmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvYWdlbmRhLWludGVyaW0tMjAxOS1jZWxsYXItMDQtc2Vzc2EvPGJyPgk8YnI+CVdFQiBD T05GRVJFTkNFOjxicj4JJm5ic3A7Jm5ic3A7IGh0dHBzOi8vYXBwZWFyLmluL2NlbGxhci1pbnRl cmltPGJyPgkmbmJzcDsmbmJzcDsgVEhFUkUgSVMgTk8gVEVMRVBIT05FIERJQUxJTjxicj4JJm5i c3A7Jm5ic3A7IFlvdSBjYW4gdHJ5IHRoaXMgYXQgYW55IHRpbWUuPGJyPgkmbmJzcDsmbmJzcDsg VGhlc2Ugbm90ZXMgYXQ6IGh0dHBzOi8vZ2l0aHViLmNvbS9jZWxsYXItd2cvY2hhaXItbm90ZXM8 YnI+CTxicj4JUHJlc2VudDo8YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAxKSBtaWNoYWVsIHJpY2hhcmRzb248YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAyKSBTdGV2ZSBMaG9tbWU8YnI+CSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzKSBNYXJ0aW4gQmVsb3c8YnI+CSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0KSBKZXJvbWUgTWFydGluZXo8YnI+CSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1KSBEYXZlIFJpY2U8YnI+ CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2KSZuYnNwOyBNaWNo YWVsIE5pZWRlcm1heWVyPGJyPgk8YnI+CVByb3Bvc2VkIEFnZW5kYTo8YnI+CTxicj4JMS4gTm90 ZSBXZWxsLjxicj4JMi4gQWNjZXB0IGRyYWZ0IG1pbnV0ZXMgZnJvbSBBcHJpbCAyIG1lZXRpbmc8 YnI+CTxicj4JMy4gTG9naXN0aWNzIGZvciBNZWV0aW5nLjxicj4JJm5ic3A7Jm5ic3A7IDJhKSBF dGhlcnBhZCBmb3Igbm90ZXM8YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBodHRwczovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnL3Avbm90ZXMtY2VsbGFyLXZpcnR1YWw/ dXNlTW9ub3NwYWNlRm9udD10cnVlPGJyPgk8YnI+CSZuYnNwOyZuYnNwOyAyYikgQVBQRUFSLklO IGZvciB2aWRlbyBhbmQgc2NyZWVuIHNoYXJpbmcuPGJyPgkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVyaW08YnI+CSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoYXMgYWdyZWVkIGxhc3QgbWVldGluZyk8 YnI+CTxicj4JJm5ic3A7Jm5ic3A7IDJjKSBSb2xsIGNhbGw8YnI+CTxicj4JNC4gV0cgc3RhdHVz IHVwZGF0ZTxicj4JJm5ic3A7Jm5ic3A7IC0gRUJNTCBzZWVtcyB0byBiZSBnZXR0aW5nIHNvbWUg YWRkaXRpb25hbCBlZGl0cywgaXMgaXQgZG9uZT88YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGVzZSB3ZXJlIHRoZSBpc3N1ZXMgdGhhdCBhcmUgd2FpdGluZyBmb3IgY2xhcmlmaWNhdGlv bjo8YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczov L2dpdGh1Yi5jb20vTWF0cm9za2EtT3JnL2VibWwtc3BlY2lmaWNhdGlvbi9pc3N1ZXM/cT1pcyUz QWlzc3VlK2lzJTNBb3BlbitsYWJlbCUzQWNsYXJpZmljYXRpb25zPGJyPgkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgV2Ugc3RpbGwgaGF2ZSBhIGZldyBvcGVuLiZuYnNwOyBDYW4gd2UgY2xvc2Ug dGhlbSBub3c/PGJyPgkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2ZSBSaWNlIGV4cGVjdGVk IHRvIHB1c2ggdmVyc2lvbiAxMC4uLi48YnI+CSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWRVJT SU9OIDEwIHJlbGVhc2VkIDIwMTktMDUtMjggKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtY2VsbGFyLWVibWwvMTAvKS4mbmJzcDsgTWVyZ2VkIG1hbnkgaXNzdWVz Ljxicj4JJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgYWRkcmVzc2VzIEFEIGlzc3VlcyBm cm9tIEJlbiBDYW1wYmVsbCBhbmQgUm9iZXJ0IFNwYXJrcy4uLi4gcmVtYWluaW5nIDI8YnI+CSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMS4xLjExLiZuYnNwOyBYTUwgU2NoZW1hIGZv ciBFQk1MIFNjaGVtYSAoRGF2ZSB2b2x1bnRlZXJzIHRvIGNvbXBsZXRlIHRoaXMpPGJyPgkmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhlIGZvbGxvd2luZyAiWFNEIiBkZWZpbml0aW9uIGlzIGluICZsdDtGT1JNQVQmZ3Q7 IChhZGQgVzNDIGNpdGF0aW9uKSwgYW5kIGNhbiBiZSB1c2VkIHRvIHZhbGlkYXRlIGFuIEVCTUwg U2NoZW1hIHVzaW5nICZsdDtUT09MJmd0Ozxicj4JPGJyPgkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHVzZSBvZiB1bmtub3duLXNpemUgcmVxdWlyZXMgdG8g a25vdyB0aGUgRUJNTCBTY2hlbWEuIEFkZCBhbiBleGFtcGxlIG9mIHVua25vd24tc2l6ZSBlbGVt ZW50Ljxicj4JPGJyPglNaWNoYWVsIHdpbGwgY29udGFjdCBNYXJ0aW4gaW4gdGhlIGNvbWluZyBk YXlzL3dlZWtzIHRvIHdvcmsgb24gaGlzIGxhcmdlIGNoYXB0ZXIgcHVsbCByZXF1ZXN0Ljxicj4J PGJyPgk1LiBNYXRyb3NrYSBkb2N1bWVudCBjaGFuZ2VzIHNpbmNlIGxhc3QgbWVldGluZy48YnI+ CSZuYnNwOyZuYnNwOyBodHRwczovL2dpdGh1Yi5jb20vY2VsbGFyLXdnL21hdHJvc2thLXNwZWNp ZmljYXRpb24vaXNzdWVzPGJyPgkmbmJzcDsmbmJzcDsgQ2FuIHdlIGNsb3NlIHNvbWUgb2YgdGhl c2UsIGFuZC9vciBnZXQgdGhlbSBzb3J0ZWQgYW5kIHByaW9yaXRpemVkPzxicj4JPGJyPgkmbmJz cDsmbmJzcDsgYSkgRGF2ZSBSaWNlIHRvIHBvc3QgcmVxdWVzdCBmb3Igdm9sdW50ZWVycywgb2Zm ZXJzIHRvIG1lbnRvci48YnI+CSZuYnNwOyZuYnNwOyBiKSBNQ1IgdG8gbWVudG9yIE1hcnRpbiBv biBnaXRodWItZnU8YnI+CSZuYnNwOyZuYnNwOyBjKSBhbGwgdG8gcmV2aWV3IHB1bGwgcmVxdWVz dHMgb24gTWF0cm9za2EsIGxvb2sgZm9yIGNvbmZsaWN0cyBhbmQgKmRpc2N1c3Npb24qIChuZXcg dGFnKSB0aGF0IHdlIGNhbiBnbyB0aHJvdWdoIG5leHQgdGltZS48YnI+CSZuYnNwOyZuYnNwOyBk KSBNQ1IgdG8gcGluZyBNb3JpdHogYWJvdXQgbmV4dCB0aW1lLjxicj4JPGJyPgk2LiBTdGFydGVk IDQtd2VlayBhZG9wdGluZyBjYWxsIGZvciBGcmVlIExvc3NsZXNzIEF1ZGlvIENvZGVjPGJyPgkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtd2VhdmVyLWNlbGxhci1mbGFjLTAw PGJyPgkmbmJzcDsmbmJzcDsgd2lsbCBlbmQgYXQgbmV4dCB2aXJ0dWFsLWludGVyaW0gbWVldGlu Zy48YnI+CTxicj4JJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHBsZWFzZSBwb3N0IHlvdXIgb3BpbmlvbiBhYm91dCB0aGUgZG9jdW1l bnQ/IERvZXMgaXQgZml0IGludG8gd2hhdCB0aGUgY2hhcnRlciBhc2tlZCBmb3I/PGJyPgk8YnI+ CVE6IGZmdjEuIGxhc3QgbWVldGluZyBuZXcgQUQ/PGJyPglBOiB3ZSBhcmUgd2FpdGluZyBmb3Ig ZmVlZGJhY2suPGJyPglBQ1RJT046IG1jciB0byBidWcgQUQgYWJvdXQgZmZ2MS48YnI+CTxicj4J bWVldGluZyBlbmRlZCAxNjo1NS48YnI+CTxicj4JPGJyPgk8YnI+CTxicj48YnI+PGJyPjxicj4t LSA8YnI+TWljaGFlbCBSaWNoYXJkc29uICZsdDttY3IrSUVURkBzYW5kZWxtYW4uY2EmZ3Q7LCBT YW5kZWxtYW4gU29mdHdhcmUgV29ya3M8YnI+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS08YnI+ PGJyPjxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPkNlbGxhciBtYWlsaW5nIGxpc3Q8YnI+Q2VsbGFyQGlldGYub3JnPGJyPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2VsbGFyPGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_2205361660274490-- From nobody Tue Jul 30 13:26:03 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 828BA120089 for ; Tue, 30 Jul 2019 13:26:01 -0700 (PDT) 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_HELO_NONE=0.001, 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 giCPuaYd0Y5h for ; Tue, 30 Jul 2019 13:25:59 -0700 (PDT) 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 8CA2E12001A for ; Tue, 30 Jul 2019 13:25:59 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 747DE3808A; Tue, 30 Jul 2019 16:25:33 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 155A514; Tue, 30 Jul 2019 16:25:58 -0400 (EDT) To: Alexey Melnikov , cellar@ietf.org References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> From: Michael Richardson Message-ID: Date: Tue, 30 Jul 2019 16:25:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 30 Jul 2019 20:26:01 -0000 On 2019-07-03 9:44 a.m., Alexey Melnikov wrote: > I think you need to be clearer on what you expect to appear on IANA's page. Do you expect a reference and/or description field in addition to a DocType name? I suspect you would also need the Change Controller field (who registered the value and can update the description). > > DocType string values of "matroska" and "webm" are RESERVED to the > IETF for future use. These can be assigned via the "IESG Approval" > or "RFC Required" policies [RFC8126]. > > The last sentence is odd, but then I realized that you only reserve these two names and will attempt to assign them separately in the future. I suppose the current text is Ok. > Hi, we struggled with how we should initialize the DocType registry, since we expect "matroska" to be used by draft-ietf-cellar-matroska, and we expect "webm" to only be given to some new work (from google) that would define that format. A decision as to who is the legitimate documentator of the (existing) "webm" DocType would be up to the IESG. This text was suggested by IANA! From nobody Tue Jul 30 15:50: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 910891201C9 for ; Tue, 30 Jul 2019 15:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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=google.com header.b=ueJV0n6c; dkim=pass (2048-bit key) header.d=gmail.com header.b=AMpfYzMn 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 tXbN34aXzvzJ for ; Tue, 30 Jul 2019 15:49:53 -0700 (PDT) Received: from mail-qt1-x849.google.com (mail-qt1-x849.google.com [IPv6:2607:f8b0:4864:20::849]) (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 3B9B61201C7 for ; Tue, 30 Jul 2019 15:49:53 -0700 (PDT) Received: by mail-qt1-x849.google.com with SMTP id y19so59837977qtm.0 for ; Tue, 30 Jul 2019 15:49:53 -0700 (PDT) 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=lZhfljDPeH/EgfZ95yXqjx3bgZ5p1aqP8HGn4ItZKqw=; b=ueJV0n6cQn0yw3Zj+7pB8jyruZ6xmWvJxE+4hYy92+7AZslEyAbFk0JB0FqssBTFa5 Axh4lsHeNnzmeMNiLl5hXFbNfZXG0BhCwam3XFt4Uf6xOHRNTbWLHt9PMmbqDSxskyov 8fMGnFZIJyZhj6Pr8MxtdQiGdY4NhK6hxA2z4w0vJUPzelRIS1ZZhMXQPUlLx4oJ+x80 Dtei9TVPAyx9QB8ewc3I3DpPvatS4lvK2p1MbRVbi+sZQV51Oztoaid4V8Rlh2csx5vX 4wXwLyly37MsRxEKZwKpPJcP7gpOplug0g24GK8i/s9cBSpd9hM1bQHOZpRRN9kEKsgi Cr4w== 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=lZhfljDPeH/EgfZ95yXqjx3bgZ5p1aqP8HGn4ItZKqw=; b=AMpfYzMnuDucpmUjQMSJMj7iEE2SVxXOykSSEYclkDBjvBgQmBzWfIsLLYZPoBd3JN 0s/8eotilNRLUjW+3GhKEQmdJn+DCCAREMnUOPWepRWpneVl1d9Urpv5n4UCbAzovMdv 1+itKfolyX65QWhQ5XyGn/uB4CP5hrAz6hpIRTX8qNHwZrf4shG9x9H6Lag8SA7kM230 BtKS9BFKTS9U+Y0ubeOjCpDLCRbhfwuwODXc990S/eDtQgRo/sR6C961+Azqj5Gsx4dP 8auSV3NGjrRmdRz1Hz8OetXiQucCSSMkRpkpCT/nhaT6EzUvAxulFOYcA/BdALDeO0x9 VTuw== 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=lZhfljDPeH/EgfZ95yXqjx3bgZ5p1aqP8HGn4ItZKqw=; b=eTJnR5/EdZJill7xWPvSWGta2+aHFPT4Timupeds1lMechKDT+qJhSZjhb6zaqwJ4f ic+ZV8gcvbiNnicfRtXWmLMXLnH3SbRva08xxoW1o6wsK3MoDg9Q3MjqiKwamQeC0IQT 1qyNs8pqJYJl0Y+51kfPMd8ty8NKrx/tJ+9xC/hb1H1Qr3cWzmxE3nU1nmu4X/8RrWC4 JWDpzvphlKkEjhP7WEzGmGNWs0BJtbxMLi5a3FNtNNy3e3fAJSNVZShuxtWjSzMk0aKJ B2AcqpMkNH0mU5AW2dj/YCmSZ+l/RR2d032va3u/MIriGY4KMf3Uu6ndk9dvOaTQ149Z jrEg== X-Gm-Message-State: APjAAAUGppcfmYkhtQd2k1Wdvslvt4Nf54/pQTQe6QdAKZghhCQgQUKG kO/uxHisXSQRZeSfjMgDiObtFSDHMXeiqgiPD38= X-Google-Smtp-Source: APXvYqz+7jS0Ja2ne5WUXvxW91Vi1uCKq8q51oOhr5NNJNTOw81s+l4m9J7jT9JhkOo3Rm+6aoyhQlB6Q+lhFirCcZ6D MIME-Version: 1.0 X-Received: by 2002:a37:a7d6:: with SMTP id q205mr76012554qke.44.1564526992207; Tue, 30 Jul 2019 15:49:52 -0700 (PDT) Reply-To: mcharlesr@gmail.com Sender: Google Calendar Message-ID: <0000000000009cb86e058eedd36b@google.com> Date: Tue, 30 Jul 2019 22:49:52 +0000 From: mcharlesr@gmail.com To: cellar@ietf.org, tterriberry@mozilla.com Content-Type: multipart/mixed; boundary="0000000000009cb855058eedd36a" Archived-At: Subject: [Cellar] Invitation: cellar-interim @ Monthly from 15:00 to 16:00 on the fourth Tuesday 4 times (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: Tue, 30 Jul 2019 22:49:56 -0000 --0000000000009cb855058eedd36a Content-Type: multipart/alternative; boundary="0000000000009cb851058eedd368" --0000000000009cb851058eedd368 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes You have been invited to the following event. Title: cellar-interim https://datatracker.ietf.org/wg/cellar/meetings/ When: Monthly from 15:00 to 16:00 on the fourth Tuesday 4 times Eastern Time - Toronto Where: https://appear.in/cellar-interim Calendar: cellar@ietf.org Who: * mcharlesr@gmail.com - organizer * cellar@ietf.org * tterriberry@mozilla.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=MzNsNGVmanNsZG9oNDFlOG43OWFwZWRpNWwgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbWUzYjM0ZWI4ZjcyZmQxODE2ZWI0NDQzYTk5MzJjNmUwNjcxNGMzMTU&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 send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding --0000000000009cb851058eedd368 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

You have been invited to the follo= wing event.

cellar-interim

tterriberry@mozilla.c= om
= When
Monthly from 15= :00 to 16:00 on the fourth Tuesday 4 times Easte= rn Time - Toronto
Where<= /div>
https://appear.in/cellar-interim<= /span> (map)
= Calendar
cellar@ietf.org
Who
&#= x2022;
<= div style=3D"margin:0 0 0.3em 0">mcharlesr@gmail.com - organizer
<= /td>
•
cellar@ietf.org
•

Going (cellar@ietf.org)?   Al= l events 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 send a response to the organizer and be added to the gu= est list, or invite others regardless of their own invitation status, or to= modify your RSVP. Learn More.

--0000000000009cb851058eedd368 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:VTIMEZONE TZID:Europe/Amsterdam X-LIC-LOCATION:Europe/Amsterdam BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=Europe/Amsterdam:20190827T210000 DTEND;TZID=Europe/Amsterdam:20190827T220000 RRULE:FREQ=MONTHLY;COUNT=4;BYDAY=4TU DTSTAMP:20190730T224952Z ORGANIZER;CN=mcharlesr@gmail.com:mailto:mcharlesr@gmail.com UID:33l4efjsldoh41e8n79apedi5l@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=mcharlesr@gmail.com;X-NUM-GUESTS=0:mailto:mcharlesr@gmail.com X-MICROSOFT-CDO-OWNERAPPTID:684494941 CLASS:PUBLIC CREATED:20190730T224948Z DESCRIPTION:https://datatracker.ietf.org/wg/cellar/meetings/\n\n-::~:~::~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~:: -\nPlease do not edit this section of the description.\n\nView your event a t https://www.google.com/calendar/event?action=VIEW&eid=MzNsNGVmanNsZG9oNDF lOG43OWFwZWRpNWwgY2VsbGFyQGlldGYub3Jn&tok=MTkjbWNoYXJsZXNyQGdtYWlsLmNvbWUzY jM0ZWI4ZjcyZmQxODE2ZWI0NDQzYTk5MzJjNmUwNjcxNGMzMTU&ctz=America%2FToronto&hl =en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20190730T224948Z 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 --0000000000009cb851058eedd368-- --0000000000009cb855058eedd36a Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VlRJTUVaT05FDQpUWklEOkV1cm9wZS9BbXN0ZXJkYW0NClgtTElDLUxPQ0FUSU9O OkV1cm9wZS9BbXN0ZXJkYW0NCkJFR0lOOkRBWUxJR0hUDQpUWk9GRlNFVEZST006KzAxMDANClRa T0ZGU0VUVE86KzAyMDANClRaTkFNRTpDRVNUDQpEVFNUQVJUOjE5NzAwMzI5VDAyMDAwMA0KUlJV TEU6RlJFUT1ZRUFSTFk7QllNT05USD0zO0JZREFZPS0xU1UNCkVORDpEQVlMSUdIVA0KQkVHSU46 U1RBTkRBUkQNClRaT0ZGU0VURlJPTTorMDIwMA0KVFpPRkZTRVRUTzorMDEwMA0KVFpOQU1FOkNF VA0KRFRTVEFSVDoxOTcwMTAyNVQwMzAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9OVEg9MTA7 QllEQVk9LTFTVQ0KRU5EOlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRU U1RBUlQ7VFpJRD1FdXJvcGUvQW1zdGVyZGFtOjIwMTkwODI3VDIxMDAwMA0KRFRFTkQ7VFpJRD1F dXJvcGUvQW1zdGVyZGFtOjIwMTkwODI3VDIyMDAwMA0KUlJVTEU6RlJFUT1NT05USExZO0NPVU5U PTQ7QllEQVk9NFRVDQpEVFNUQU1QOjIwMTkwNzMwVDIyNDk1MloNCk9SR0FOSVpFUjtDTj1tY2hh cmxlc3JAZ21haWwuY29tOm1haWx0bzptY2hhcmxlc3JAZ21haWwuY29tDQpVSUQ6MzNsNGVmanNs ZG9oNDFlOG43OWFwZWRpNWxAZ29vZ2xlLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtD Tj1jZWxsYXJAaWV0Zi5vcmc7WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmNlbGxhckBpZXRmLm9yZw0K QVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9 TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj10dGVycmliZXJyeUBtb3ppbGxhLmNvbTtYLU5V TS1HVUVTVFM9MDptYWlsdG86dHRlcnJpYmVycnlAbW96aWxsYS5jDQogb20NCkFUVEVOREVFO0NV VFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPUFDQ0VQVEVEO1JT VlA9VFJVRQ0KIDtDTj1tY2hhcmxlc3JAZ21haWwuY29tO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpt Y2hhcmxlc3JAZ21haWwuY29tDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6Njg0NDk0OTQx DQpDTEFTUzpQVUJMSUMNCkNSRUFURUQ6MjAxOTA3MzBUMjI0OTQ4Wg0KREVTQ1JJUFRJT046aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9jZWxsYXIvbWVldGluZ3MvXG5cbi06On46fjo6 fjp+DQogOn46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46 fjp+On46fjp+On46fjp+On46On46fjo6DQogLVxuUGxlYXNlIGRvIG5vdCBlZGl0IHRoaXMgc2Vj dGlvbiBvZiB0aGUgZGVzY3JpcHRpb24uXG5cblZpZXcgeW91ciBldmVudCBhDQogdCBodHRwczov L3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1Nek5zTkdWbWFu TnNaRzlvTkRGDQogbE9HNDNPV0Z3WldScE5Xd2dZMlZzYkdGeVFHbGxkR1l1YjNKbiZ0b2s9TVRr amJXTm9ZWEpzWlhOeVFHZHRZV2xzTG1OdmJXVXpZDQogak0wWldJNFpqY3labVF4T0RFMlpXSTBO RFF6WVRrNU16SmpObVV3TmpjeE5HTXpNVFUmY3R6PUFtZXJpY2ElMkZUb3JvbnRvJmhsDQogPWVu JmVzPTEuXG4tOjp+On46On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+ On46fjp+On46fjp+On46DQogfjp+On46fjp+On46fjp+Ojp+On46Oi0NCkxBU1QtTU9ESUZJRUQ6 MjAxOTA3MzBUMjI0OTQ4Wg0KTE9DQVRJT046aHR0cHM6Ly9hcHBlYXIuaW4vY2VsbGFyLWludGVy aW0NClNFUVVFTkNFOjANClNUQVRVUzpDT05GSVJNRUQNClNVTU1BUlk6Y2VsbGFyLWludGVyaW0N ClRSQU5TUDpPUEFRVUUNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9O OlRoaXMgaXMgYW4gZXZlbnQgcmVtaW5kZXINClRSSUdHRVI6LVAwRFQwSDEwTTBTDQpFTkQ6VkFM QVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --0000000000009cb855058eedd36a-- From nobody Tue Jul 30 15:52:03 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 B50F2120099 for ; Tue, 30 Jul 2019 15:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 m_wfsFG0hECW for ; Tue, 30 Jul 2019 15:51:58 -0700 (PDT) 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 4F7A7120090 for ; Tue, 30 Jul 2019 15:51:58 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 366EF3808A for ; Tue, 30 Jul 2019 18:51:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F101E14 for ; Tue, 30 Jul 2019 18:51:56 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: <16478.1564421144@localhost> References: <16478.1564421144@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] AGENDA 2019-07-30 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: Tue, 30 Jul 2019 22:52:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are the minutes from today's meeting. We tried to resolve issue #257 that was keeping us from issuing the EBML-11 document need for the AD review, but wind up creating issue #279. We tried to resolve Matroska issue #334 and related issue #308, but failed. An important thing is that we agreed to move the time of the meeting From=20"20:00UTC" which right now is 22:00 (10PM) Central European Daylight Savings Time (CET), to be anchored at 21:00 Amsterdam/Berlin time. That means that it stays at the same time in Europe, but bounces around slightly for North American types. (Only Oct. 29 is off) =3D=3D=3D=3D CELLAR -- DRAFT AGENDA for Virtual Interim Meeting July 30, 2019 20:00 UTC =09 Present: 1) Michael Richardson 2) Timothy B. Terriberry 3) Steve Lhomme 4) Martin Below 5) Dave Rice 6) Michael Niedermeier =09=09 Regrets: Jerome Martinez =09 INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-06/session/cel= lar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-06-sessa/ =09 WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes =09 1. Note Well. https://www.ietf.org/about/note-well/ =09=09 2. Accept draft minutes from June 25 meeting (attached below) No objections/changes, minutes passed. =09 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospace= Font=3Dtrue =09 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim =09 2c) Roll call =09 4. WG status update * EBML -- still waiting on revised -11 document for AD evaluation. ACTION from last time: =3D=3D> issue #257, requested one more day to think about i= t.=20 The changes are fine in general, but want to make sure it precise enough. = (MB)=20 =09 We created issue #279 to introduce some new text to better explain what a = Global Element is, and why it does not end an unlimited size Element. =09 * Thank for reposting of draft-ietf-cellar-tags-02, draft-ietf-cellar-matroska-03 and draft-ietf-cellar-codec-02 =09 * The personal draft-weaver-cellar-flac-00 did not get reposted. I believe that we adopted it, so it should have been reposted with a draft-ietf-cellar-flac-00! =09 reposted today, thank you. =09 5. Any remining EBML issues. =09 none known. =09 6. ffv1-07 could be reposted in v3 format. ACTION: mcr to ask DataTracker and RSE if they are ready for this. =09 7. Work on Matroska issues. =09 Closed issue #325 (merged). Discussed issue #334 and related issue #308. =09 8. Any other business. =09 Matroska Pull request #318 will be on the agenda for next time. =09 Meeting will be moved to an hour earlier, until the time changes. Currently it is 23:00 Berlin, so we will anchor the meeting to 22:00 Berli= n time. =09 =3D=3D=3D=3D CELLAR -- DRAFT AGENDA for Virtual Interim Meeting June 25, 2019 20:00 UTC =09=20=20=20=20=20=20=20=20 INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-05/ses= sion/cellar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-05-= sessa/ =09=20=20=20=20=20=20=20=20 WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes =09=20=20=20=20=20=20=20=20 =09=20=20=20=20=20=20=20=20 Present: 1) Michael Richardson 2) Moritz Bunkus 3) Martin Below 4) Steve Lhomme 5) Dave Rice 6) J=C3=A9r=C3=B4me Martinez =09=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Regrets: 1) Reto Kromer =09 =09=20=20=20=20=20=20=20=20 1. Note Well. 2. Accept draft minutes from May 28 meeting accepted without change. =09=20=20=20=20=20=20=20=20 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useM= onospaceFont=3Dtrue =09=20=20=20=20=20=20=20=20 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim =09=20=20=20=20=20=20=20=20 2c) Roll call =09=20=20=20=20=20=20=20=20 4. WG status update * MCR still need to help Martin on large pull request. * EBML changes... done. + issue #257, requested one more day to think about it. Th= e changes are fine in general, but want to make sure it precise enough. (MB) * ffv1 has been submitted to IESG by AD. =09=20=20=20=20=20=20=20=20 5. Work on Matroska issues. 48 open issues 21 open pull requests https://github.com/cellar-wg/matroska-specification/issues =09=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Next time, Steve will walk us through XSLT code to validat= e the specification. TAG: "format extension" suggestion that does not have to go into the mai= n spec, because it could be added as separate spec https://github.com/cel= lar-wg/matroska-specification/issues?q=3Dis%3Aissue+is%3Aopen+label%3A%22fo= rmat+extension%22 "format addition" something that has to go into main specifica= tion. https://github.com/cellar-wg/matroska-specification/issues?q=3Dis%3= Aissue+is%3Aopen+label%3A%22format+addition%22 =09=20=20=20=20=20=20=20=20 * As the WebM will not be defined, remove all of the WebM specific stuff. * MCR suggests removing it from the Matroska document, and leave t= he history for others. * MB: DivX is also not part of Matroska. Also concerned about how= the Matroska project presents the WebM/DiVX vs core Matroska elements. T= he spec will be huge, so take things out. =09 * define how to add unpredictable data to the Matroska, so we could track = things that are added. Not just WebM, but also a libmotrsaka as well. * extension data would be on their own lines, and revision history would b= e clearly. =09 =09=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 6. Any other business. =09=20=20=20=20=20=20=20=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1AygwACgkQgItw+93Q 3WWviwgAjqAKld2ObR6a4RHJ/SVkHRNw80TOFfwAge5gcMtcheRd9teUCCrP9Lqs /7ljr2kpO3qf+XAPU6guoBWDaHMKe8HCQXk/M2WKwkcvDpEyonSXphAvkdYoZ/9+ SrBnaCMFpIjw9VjsWfd7m7Ut6lCeKG3VWxaNFaYAvc14hA8mRamruuh8jxmuTDEI t/Op6L5lbbOtLBLfgaNrnjwu5cLn8zrU/LpsRki6fagAEYqTaUylnPgHX74/iOto yLbeTykC8sMAnVz8Ppvmz9eFxyJFaMXD60oc6fVnb1TNSvjTG04iqU4Sinu2fWRk Ya5tS0AuNmQvm3o6qqaLaBpCdJQ1xw== =4EFb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 30 22:55: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 9CDB8120025 for ; Tue, 30 Jul 2019 22:55:49 -0700 (PDT) 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_HELO_NONE=0.001, 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 xrXm7Xod0Pqg for ; Tue, 30 Jul 2019 22:55:48 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 98BB1120019 for ; Tue, 30 Jul 2019 22:55:47 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x6V5tjR2018081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 31 Jul 2019 07:55:45 +0200 Received: from Castor ([IPv6:2a02:aa13:4680:f280:8d68:4458:ddc1:183e]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x6V5ti6C064629 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2019 07:55:45 +0200 Date: Wed, 31 Jul 2019 07:55:45 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <5259.1564527116@localhost> 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] AGENDA 2019-07-30 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: Wed, 31 Jul 2019 05:55:50 -0000 Michael Richardson wrote: >An important thing is that we agreed to move the time of the >meeting >From "20:00UTC" which right now is 22:00 (10PM) Central >European Daylight Savings Time (CET), to be anchored at 21:00 >Amsterdam/Berlin time. Thank you very much indeed! Reto