From nobody Tue Sep 12 04:47:15 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8042F13219E for ; Tue, 12 Sep 2017 04:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no 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 nG0IliSt0355 for ; Tue, 12 Sep 2017 04:47:11 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) (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 85C60126DFE for ; Tue, 12 Sep 2017 04:47:11 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora2.lax.icann.org (Postfix) with ESMTPS id 372481E01E7 for ; Tue, 12 Sep 2017 11:47:11 +0000 (UTC) Received: by mail-io0-x231.google.com with SMTP id n69so43964387ioi.5 for ; Tue, 12 Sep 2017 04:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=waQ7SmCojkRiwE7TqzMmQrsYSaHapKmq69JzOfc0mtA=; b=JsO5FQnqdnuvjFppP+ZvdREir3ILGTgn+m1ilXiq0MmcppPEC6sP2coMmVnZBPErM/ zRd8R+rQ864l6FLW+Wtrp4xGJ88l5fwfkzqVnoHpi9nfVNzh8sKNZAI7kl5QXoaRGftp LzBOWhdvdGiXq1mL6N3AMRJ1tyEdO/294fhdnQ7lDmdhoRVbAZcqjDMrmxf7St+nt+cc lMRJBCmM823kgeRBuOqti6sue55ptwkfRYk0kZpJMB5CMpRTkC11W+5rySAGi8UPboBu 4hBh1m5qVl95T6Xe8yMn5F68ROOMXEp5iYTFQ5zZOi3qRNGe7YUo3mROHZkd32AMI082 x8zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=waQ7SmCojkRiwE7TqzMmQrsYSaHapKmq69JzOfc0mtA=; b=GwSnEaGawaoxp98eu9c4Jjil2aI+8BlmHZr3uTe+W5xSjpPhkzRYPK7x/4wHK+yhMU zZoYs9PxL2n85VoR+/ohicmyivMZSgdHc89AYpftIoq+xQq/Ytsc33nGIun6oiQmUydX tG5584Xyv4ESTweeIZP9OJghlqbbN1XgxVCcyHu/pC2A1Bu0zfOERm0M77HfhfX2bxO+ EJIqfpTxVqETRDoNjxH+fjyrauB9eKNXGc+LUlcQv9AoAAtsTaanYTvODU2EzgknSD5/ NcJt5Cm54FsrkJHEuE8Asx3ubuWtUpPhBKl0FKaTrhrOTxv7K6dyPAe1QijJuzpu1VPf 9apw== X-Gm-Message-State: AHPjjUg6NjgNWWWa+JV3iyFeRM87ExB2qiEiXGzOOI0RQGZyaoIKCQgw HNj2PzuXocFUCtW7TPpPpCmEmQIr4Bwp X-Google-Smtp-Source: AOwi7QAtPEevVRXzmk8xKDlMnNe4j6LtW6wgjV8ekDKENS7hVbsFNcBtGpx3aasIyaRtRu/LKqcMg7n2y0O2tK6tdtI= X-Received: by 10.202.181.195 with SMTP id e186mr15680856oif.290.1505216830232; Tue, 12 Sep 2017 04:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.13.1 with HTTP; Tue, 12 Sep 2017 04:47:09 -0700 (PDT) In-Reply-To: References: From: Bob Jolliffe Date: Tue, 12 Sep 2017 12:47:09 +0100 Message-ID: To: media-types@iana.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [media-types] Notice of intent to register a media type X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 11:47:13 -0000 Hello I submitted the application below on the web form at https://www.iana.org/form/media-types last week. There was no indication that the form had been accepted or not (it is possible I even submitted twice). Is there anyone on this list can confirm that the request for application/adx+xml has been properly received? Thank you Bob On 7 August 2017 at 15:21, Bob Jolliffe wrote: > Hello > > I have suggested a revised and simplified application below, taking > into account the valuable comments by Sean Leonard and Chris Lilley > regarding charset and RFC 7303. Hopefully this is now ok. > > Type name: application > > Subtype name: adx+xml > > Required parameters: none > > Optional parameters: charset (as for application/xml per RFC 7303) > > Encoding considerations: > > As per RFC 7303 > > Security considerations: > > See the security considerations for application/xml in RFC7303 > > Interoperability considerations: > > As for application/xml per RFC7303 > > Published specification: > > See http://ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_ADX_Rev2= .0_PC_2017-05-26.pdf > > Applications that use this media type: > > A wide variety of systems involved in routine public health reporting. > > Fragment identifier considerations: > None > > Additional information: > None > > Deprecated alias names for this type: > N/A > > > Magic number(s): > N/A > > > File extension(s): > N/A > > > Macintosh file type code(s): > N/A > > Person & email address to contact for further information: > > QRPH Technical committee : qrph@ihe.net > > > Intended usage: > > COMMON > > Restrictions on usage: > None > > Author: Bob Jolliffe and James Kariuki > > Change controller: QRPH Technical Committee qrph@ihe.net > > Provisional registration? (standards tree only): yes > > On 26 April 2017 at 10:51, Bob Jolliffe wrote: >> Thank you Martin for your quick reply. Taking baby steps, our first ste= p >> was going to be submitting a provisional registration, for which RFC6838 >> suggests we just need to have the media type name and contact email fill= ed >> on the template. >> >> Nevertheless, I have completed the template below in anticipation of the >> next step. If reviewers are satisfied we could then move directly to fo= rmal >> registration. Or else we proceed with provisional registration until th= e >> next edition of ADX profile is published later this year or early 2018. >> >> Regards >> Bob Jolliffe >> >> Type name: application >> >> Subtype name: adx+xml >> >> Required parameters: none >> >> >> Optional parameters: charset >> >> As per rfc3023 the use of charset is strongly recommended. >> >> "utf-8" and "utf-16" are the recommended values for maximum compatibil= ity >> >> with xml processors. >> >> Encoding considerations: >> >> As per application/xml (sec 3.2) of rfc 3023 >> >> Security considerations: >> >> As a subset of xml, application/adx+xml has all the same security >> considerations >> >> of xml as outlined in sec 10 of rfc 3023. >> >> >> The envisaged usage is for the transport of aggregate (statistical) pu= blic >> health data >> >> rather than individual medical record data which would require more >> stringent >> >> considerations relating to privacy. The ADX profile mandates the use = of >> transport level >> >> security when transported over the web. >> >> >> >> Interoperability considerations: >> >> Interpretation of the content of this media type presupposes that >> applications have exchanged >> >> structural metadata (primarily codelists) for the controlled vocabular= ies >> used in the data message. >> >> Published specification: >> >> The original specificaton is published at >> http://wiki.ihe.net/index.php/Aggregate_Data_Exchange. >> An updated publication profiling adx transport is expected 2017/2018 >> >> Applications that use this media type: >> >> A wide variety of systems involved in routine public health reporting. >> >> Fragment identifier considerations: >> None >> >> Additional information: >> None >> >> Deprecated alias names for this type: >> N/A >> >> >> Magic number(s): >> N/A >> >> >> File extension(s): >> N/A >> >> >> Macintosh file type code(s): >> N/A >> >> Person & email address to contact for further information: >> >> QRPH Technical committee : qrph@ihe.net >> >> >> Intended usage: >> >> COMMON, LIMITED USE >> >> (not too sure. There is no intention to limit the usage) >> >> Restrictions on usage: >> None >> >> Author: Bob Jolliffe and James Kariuki >> >> Change controller: QRPH Technical Committee qrph@ihe.net >> >> Provisional registration? (standards tree only): yes >> >> >> On 26 April 2017 at 08:06, Martin J. D=C3=BCrst = wrote: >>> >>> Hello Bob, >>> >>> Please send us your intended registration template directly in the mail >>> (not just a pointer, and preferably not an attachment). That will make = it >>> easier for the people on this list to give you feedback. >>> >>> Regards, Martin. >>> >>> >>> On 2017/04/25 17:15, Bob Jolliffe wrote: >>>> >>>> Good day. >>>> >>>> I am writing on behalf of the Technical Committee of Quality Research = and >>>> Public Health within IHE (Integrating the Healthcare Enterprise - >>>> http://ihe.net). >>>> >>>> Myself and James Kariuki (copied) are working on a profile for aggrega= te >>>> health data exchange within that committee. The profile (ADX) was >>>> originally published for trial implementation in 2015 ( >>>> http://wiki.ihe.net/index.php/Aggregate_Data_Exchange). We are curren= tly >>>> engaged in maintenance work updating and extending the profile. >>>> >>>> We have defined a particular content type for ADX data messages which = we >>>> would like to use the mime-type "application/adx+xml". >>>> >>>> Following the recommendations of RFC 6838 we have verified that this m= ime >>>> type is not currently registered. What we would like to do next, pend= ing >>>> feedback on this mail, is to complete a provisional registration. We >>>> would >>>> move that to a full registration following publication by the technica= l >>>> committee at the end of this cycle. >>>> >>>> The work of the QRPH TC can be viewed at >>>> http://wiki.ihe.net/index.php/Quality,_Research_and_Public_Health. >>>> >>>> The co-chairs of the TC, John Stamm and Derek Ritz, are copied on this >>>> mail. >>>> >>>> Please advise if we missing any procedural steps or any other feedback >>>> that >>>> might be useful. >>>> >>>> Regards >>>> Bob Jolliffe >>>> >>>> >>>> >>>> _______________________________________________ >>>> media-types mailing list >>>> media-types@ietf.org >>>> https://www.ietf.org/mailman/listinfo/media-types >>>> >>> >>> -- >>> Prof. Dr.sc. Martin J. D=C3=BCrst >>> Department of Intelligent Information Technology >>> College of Science and Engineering >>> Aoyama Gakuin University >>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara >>> 252-5258 Japan >> >> > > > > -- > I am travelling from Sat 24 June to Sunday 2 July. Access to my email > will be sporadic. Please be patient and I will respond when I can. From nobody Fri Sep 15 05:46:16 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEEC13307F for ; Thu, 14 Sep 2017 02:25:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_wBWSVBrNrf for ; Thu, 14 Sep 2017 02:25:28 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) (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 E8FDC13301F for ; Thu, 14 Sep 2017 02:25:27 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora8.dc.icann.org (Postfix) with ESMTPS id AA8BAC018D for ; Thu, 14 Sep 2017 09:25:26 +0000 (UTC) Received: by mail-wm0-x22b.google.com with SMTP id 189so4518329wmh.1 for ; Thu, 14 Sep 2017 02:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=tKB42fHLbPau1ElROdVG+ERgxY79YnThDOFpTelZGno=; b=HF9tDpi1f4GiQyeJFHgFSxtD1CCuNuT/P0n/+BWz4+mI84H78TkMph3pNgdFGVECqI FmYt+/E7HT15Iof4JEqjQU0NjmCr0O446zXftO+QaeRsfKmjzd5eCE8njT3y9v4Xg256 hpcmtev1k++BQjfDlumB5BjGhD5dKcg5tU06MxouEIayAD0KdtKuuo0caJBixSy4PaHa TpBjlShvbBzchGrO44vDxeM+GD725wU/VQuLRmKjWYDHqbknv0vHY8Fb9SpfIxu+5U0T H+PClZ/Kaih7WCMcfDuW5X0RuOr/qmfwCoqD3PD1azae9PBN9N+724fxriD0DbpPwLKA 0gFg== 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:cc; bh=tKB42fHLbPau1ElROdVG+ERgxY79YnThDOFpTelZGno=; b=O+A+sxnvmHAWILKoVPBHNt03GLtIh0Nh6mE9gueW5NRuWM8ryTr7cuXfgHQ8TfdNMq PV70BK+5aMDus2XQWn6sK4epuUWHeBEGm18zOiZM6J8MyKop4rx+G9MqvxJ8/MmuQDIG NVmXhBXuHxVahFSRakx/1pQfODz1dbiLdwIJ3C3c1Fe9Z3QRH8RItATL94L5MrtyPWAy GFJJ0/zhR/kC9RX415zoutfqY5uPiKZJWf3pCW0IsaaMxbUjjpYj8xcgJEZuOwqv7PJM 41MyWtFq+2dG6tC+PbCmzKHi6X+zSuPBePH8gkkGJ9tHAD69m/mAPzAhbb4j4DR5PL1f OxyA== X-Gm-Message-State: AHPjjUicgwVpBpyQ2yPvWpv8RkyuEKd8ktu2iz34TDc6qNQbBzZpOLUY K8IRppkbWqLICCikVlZ1ewJJT+wuOw2Rcs3DiWe9PZGE X-Google-Smtp-Source: AOwi7QDajzKyakhPeiTYPMjScoyNLpReIerPyjLUTet0cfueRn7psXPwU0U81fjpuWXOq2OQcznI3XD8BFpsIVxO2lI= X-Received: by 10.28.141.70 with SMTP id p67mr1199120wmd.118.1505381105884; Thu, 14 Sep 2017 02:25:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.113.66 with HTTP; Thu, 14 Sep 2017 02:25:05 -0700 (PDT) From: "Ali C. Begen" Date: Thu, 14 Sep 2017 12:25:05 +0300 Message-ID: To: ietf-types@iana.org Cc: Joey Parrish , "Christian Timmerer (ITEC)" , Alexey Melnikov Content-Type: multipart/alternative; boundary="001a11473e201179e5055922dad3" Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 05:46:15 -0700 Subject: [media-types] Need guidance on overloading an existing mime type parameter vs. defining a new parameter X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:25:30 -0000 --001a11473e201179e5055922dad3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, Alexey M. suggested that I wrote my question to this list. I hope to get some advice on something we are dealing with in MPEG. The core discussion is here: https://github.com/w3c/encrypted-media/issues/400 (At the bottom, there is the text we presented in the last mpeg meeting) I personally think overloading the codecs parameter to indicate every media future (the encryption scheme in this specific discussion but the main problem is broader) is not a good idea just for the sake of using it as implicit signaling. Admittedly, defining a new parameter is not perfect, either but maybe we can find a way to make it work nicely. What are your thoughts on this? Comments are welcome. Thanks. -acbegen m41135 (Joint contribution to July 2017 meeting by Comcast, Google and AAU/Bitmovin) Title: MIME Type Parameters for Signaling Encryption and Other Media Features 1) Introduction RFC 6381 specifies parameters that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. However, the MIME type parameters do not indicate the type of encryption. This could create a problem for the receivers when the encapsulating environment is not capable of declaring separately that the content is protected (such as in the MPD for DASH) since in that case the receivers cannot infer whether they can decode the media without first fetching and parsing the media tracks. ISO/IEC 14496-12 defect report (N16618) reported this issue, and the revised defect report (N16785) proposed an annex that defined certain rules on how to use MIME type parameters for ISOBMFF and derived specifications. The proposed annex in N16785 specifies the following: If the 4CC of a sample entry indicates protected content (e.g., =E2=80=98en= cv=E2=80=99, =E2=80=98enca=E2=80=99, =E2=80=98enct=E2=80=99 etc.), the =E2=80=98codecs= =E2=80=99 parameter value for that track is any the following values, separated by =E2=80=9C.=E2=80=9D: * the 4CC indicating protected content (e.g., =E2=80=98encv=E2=80=99); * the scheme-type (e.g., =E2=80=98cenc=E2=80=99); * the original_format (e.g., =E2=80=98avc1=E2=80=99), followed by any sub-p= arameters as defined for that original format As a result, the following values would be possible for the =E2=80=98codecs= =E2=80=99 parameter: encv.cbcs.avc1.402567 or encv.cenc.avc1.402567 The motivation here is that when a receiver reads such a value, it can determine whether it can decode the media (i.e., whether it supports the encryption mode). If it does not understand the value, by definition it will ignore the value and will not fetch the media to avoid waste of (server, network or time) resources. While the motivation for this approach seems just, overloading the =E2=80= =98codecs=E2=80=99 parameter value has several drawbacks and may lead us to more problems in the future. 2) Proposal A cleaner and more future-proof approach is to put the additional values out of the =E2=80=98codecs=E2=80=99 parameter. For example, to indicate the= encryption mode for the following existing media video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D we could rather say video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2=80=9Dcbc= s=E2=80=9D or video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2=80=9Dcen= c=E2=80=9D Indeed, the older receivers who do not understand the =E2=80=98encsheme=E2= =80=99 parameter will ignore it and may unnecessarily fetch the media (this is a behavior by design). However, we need to worry more about the newer clients who will understand this and other newly-defined parameters since very likely the usage will be dominated by such newer clients. Note that on the respective Github discussion page [1], other issues have also been listed for using the =E2=80=98codecs=E2=80=99 parameter to indica= te the encryption mode. They are: * The protection scheme is more related to the container than the codec. So, it should not be signaled as a part of the =E2=80=98codecs=E2=80=99 par= ameter. * Codec strings are currently container-independent, and the same string can be used with multiple containers. However, the protection scheme is not container-independent and this complicates the decoder APIs. * Codec strings are more likely to be passed around into deeper layers of a system than container. Implementations would need to strip this prefix before doing so. * Strings for some codecs are already quite long. While the above uses the encryption mode as the example, the same approach equally applies to other media features. For example, a media could be HDR or non-HDR, supports (or not) WCG, could be omnidirectional video, etc. One should not signal these types of features in the =E2=80=98codecs=E2=80=99 p= arameter. It is recommended that the MPEG community reaches an agreement on these principles at this meeting and the work is coordinated between the IETF, W3C and MPEG to implement the necessary changes as an update to RFC 6381. 3) References [1] https://github.com/w3c/encrypted-media/issues/400#issue --001a11473e201179e5055922dad3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

Alexey M. suggested that I wr= ote my question to this list. I hope to get some advice on something we are= dealing with in MPEG.

The core discussion is here= :
<= br>
(At the bottom, there is the text = we presented in the last mpeg meeting)

I personally think overloading t= he codecs parameter to indicate every media future (the encryption scheme i= n this specific discussion but the main problem is broader) is not a good i= dea just for the sake of using it as implicit signaling.

Admittedly, de= fining a new parameter is not perfect, either but maybe we can find a way t= o make it work nicely.

What are your t= houghts on this?=C2=A0Comments are = welcome.

Thanks.
-acbegen


m41135 (Joint con= tribution to July 2017 meeting by Comcast, Google and AAU/Bitmovin)<= br>

Title: MIME Type Parameters for Signaling Encryption and Other= Media Features

1) Introduction

RFC 6381 specifies parameters= that are used with various MIME types or type/subtype combinations to allo= w for unambiguous specification of the codecs employed by the media formats= contained within, or the profile(s) of the overall container format. Howev= er, the MIME type parameters do not indicate the type of encryption. This c= ould create a problem for the receivers when the encapsulating environment = is not capable of declaring separately that the content is protected (such = as in the MPD for DASH) since in that case the receivers cannot infer wheth= er they can decode the media without first fetching and parsing the media t= racks.

ISO/IEC 14496-12 defect report (N16618) reported this issue, = and the revised defect report (N16785) proposed an annex that defined certa= in rules on how to use MIME type parameters for ISOBMFF and derived specifi= cations.

The proposed annex in N16785 specifies the following:
= If the 4CC of a sample entry indicates protected content (e.g., =E2=80=98en= cv=E2=80=99, =E2=80=98enca=E2=80=99, =E2=80=98enct=E2=80=99 etc.), the =E2= =80=98codecs=E2=80=99 parameter value for that track is any the following v= alues, separated by =E2=80=9C.=E2=80=9D:
* the 4CC indicating protected = content (e.g., =E2=80=98encv=E2=80=99);
* the scheme-type (e.g., =E2=80= =98cenc=E2=80=99);
* the original_format (e.g., =E2=80=98avc1=E2=80=99),= followed by any sub-parameters as defined for that original format

= As a result, the following values would be possible for the =E2=80=98codecs= =E2=80=99 parameter:
encv.cbcs.avc1.402567
or
encv.cenc.avc1.402= 567

The motivation here is that when a receiver reads such a value, = it can determine whether it can decode the media (i.e., whether it supports= the encryption mode). If it does not understand the value, by definition i= t will ignore the value and will not fetch the media to avoid waste of (ser= ver, network or time) resources.

While the motivation for this appr= oach seems just, overloading the =E2=80=98codecs=E2=80=99 parameter value h= as several drawbacks and may lead us to more problems in the future.
2) Proposal

A cleaner and more future-proof approach is to put the= additional values out of the =E2=80=98codecs=E2=80=99 parameter. For examp= le, to indicate the encryption mode for the following existing media
vid= eo/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D
we could rather say
vi= deo/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2=80=9Dcbcs= =E2=80=9D
or
video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encsc= heme=3D=E2=80=9Dcenc=E2=80=9D

Indeed, the older receivers who do not= understand the =E2=80=98encsheme=E2=80=99 parameter will ignore it and may= unnecessarily fetch the media (this is a behavior by design). However, we = need to worry more about the newer clients who will understand this and oth= er newly-defined parameters since very likely the usage will be dominated b= y such newer clients.
Note that on the respective Github discussion page= [1], other issues have also been listed for using the =E2=80=98codecs=E2= =80=99 parameter to indicate the encryption mode. They are:
* The protec= tion scheme is more related to the container than the codec. So, it should = not be signaled as a part of the =E2=80=98codecs=E2=80=99 parameter.
* C= odec strings are currently container-independent, and the same string can b= e used with multiple containers. However, the protection scheme is not cont= ainer-independent and this complicates the decoder APIs.
* Codec strings= are more likely to be passed around into deeper layers of a system than co= ntainer. Implementations would need to strip this prefix before doing so.* Strings for some codecs are already quite long.
While the above uses= the encryption mode as the example, the same approach equally applies to o= ther media features. For example, a media could be HDR or non-HDR, supports= (or not) WCG, could be omnidirectional video, etc. One should not signal t= hese types of features in the =E2=80=98codecs=E2=80=99 parameter.

It= is recommended that the MPEG community reaches an agreement on these princ= iples at this meeting and the work is coordinated between the IETF, W3C and= MPEG to implement the necessary changes as an update to RFC 6381.

3= ) References
[1] https://github.com/w3c/encrypted-media/issues/400#issue --001a11473e201179e5055922dad3-- From nobody Tue Sep 19 04:44:42 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13901342D5 for ; Tue, 19 Sep 2017 04:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swjXse1HHwCS for ; Tue, 19 Sep 2017 04:44:34 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [192.0.33.72]) (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 AD3D8134235 for ; Tue, 19 Sep 2017 04:44:23 -0700 (PDT) Received: from mx-relay17-hz1.antispameurope.com (mx-relay17-hz1.antispameurope.com [94.100.132.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora2.lax.icann.org (Postfix) with ESMTPS id 427671E01E3 for ; Tue, 19 Sep 2017 11:44:23 +0000 (UTC) Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay17-hz1.antispameurope.com; Tue, 19 Sep 2017 13:43:36 +0200 Received: from mail.iis.fraunhofer.de (mail01.iis.fhg.de [153.96.171.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id 6E8752400083; Tue, 19 Sep 2017 13:43:35 +0200 (CEST) Received: from mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) by mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 13:43:34 +0200 Received: from mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a]) by mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a%12]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 13:43:34 +0200 From: "Neuendorf, Max" To: Paul Libbrecht CC: "media-types@iana.org" , Schuyler Quackenbush , "Hofmann, Ingo" Thread-Topic: [media-types] Proposal for registration of media type "audio/usac" Thread-Index: AdMVEwIalEwzA8tVSSaI+3du+A5npQBWUDMgAAlFxgAGqqFGoA== Date: Tue, 19 Sep 2017 11:43:34 +0000 Message-ID: <9538a6891a0c46aaaa338fc81bba9fa5@mail03.iis.fhg.de> References: <85263befc63f4747919a3efb035e766e@mail03.iis.fhg.de> <067d89103471467ea5ea71e478ea9043@mail03.iis.fhg.de> <65366D65-29B2-4B7C-ACEA-F8110940A28B@hoplahup.net> In-Reply-To: <65366D65-29B2-4B7C-ACEA-F8110940A28B@hoplahup.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [153.96.171.210] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-cloud-security-sender: max.neuendorf@iis.fraunhofer.de X-cloud-security-recipient: media-types@iana.org X-cloud-security-crypt: load encryption module X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay17-hz1.antispameurope.com with 91441101ACE5C X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.5.16 (pechora2.lax.icann.org [192.0.33.72]); Tue, 19 Sep 2017 11:44:23 +0000 (UTC) X-cloud-security: scantime:.1706 Archived-At: Subject: Re: [media-types] Proposal for registration of media type "audio/usac" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:44:38 -0000 Dear Paul, thanks for the feedback. Could you explain a bit further what exactly you p= ropose to add? Is this about copy&paste of raw data, similar to a picture o= r a text snippet? Please be aware that these MIME type proposals are for AA= C / USAC data only, something you rarely encounter, unless you're doing e.g= . shoutCast. Usually the data is encapsulated in an mp4 file, for which the= MIME type is well defined (e.g.: "audio/mp4; codecs=3Dmp4a.40.42"). Best regards, Max -----Original Message----- From: Paul Libbrecht [mailto:paul@hoplahup.net]=20 Sent: Wednesday, August 16, 2017 5:13 PM To: Neuendorf, Max Cc: media-types@iana.org; Schuyler Quackenbush Subject: Re: [media-types] Proposal for registration of media type "audio/u= sac" Dear Max, could I suggest that you add a Windows Clipboard Flavour name and a Macinto= sh Uniform Type Identifier for this registration and the audio/aac registra= tion? Sound files are pretty common and sound fragments can be commonly exchanged= over the clipboards. This would ensure a greater interoperability. As example registration with this information, SVG and MathML can be taken. These slots have not made its way to the registration templates yet; indeed= they only make sense for some types of information. Audio and video inform= ation is among them. thanks in advance. Paul > On 16 Aug 2017, at 10:51, Neuendorf, Max wrote: >=20 > I re-post with the actually proposed registration text. > USAC stands for "Unified Speech and Audio Coding", also referred to as Ex= tended High Efficiency Advanced Audio Coding (xHE-AAC). >=20 >=20 > 2.1 Full Name > Max Neuendorf >=20 > 2.2 E-Mail > max.neuendorf@iis.fraunhofer.de >=20 > 2.3 Type Name > "audio" >=20 > 2.4 Subtype Name > Standards Tree (no prefix) > "usac" >=20 > 2.5 Required Parameters > none >=20 > 2.6 Optional Parameters > none >=20 > 2.7 Encoding Considerations > Binary >=20 > Files are encoded binary USAC audio packed in the MPEG-4 audio format Low= Overhead Audio Transport Multiplex / Low Overhead Audio Stream (LATM/LOAS)= as defined in ISO/IEC 14496-3. > Files SHALL be transmitted without CR/LF conversion, 7-bit stripping, or = any other modification to the binary data. > Files MAY contain ID3v2.x frames at any LATM/LOAS frame boundary. > For use over the Internet, it is assumed that lower layers take care of t= ransmission errors, so audio/usac data MAY include USAC frames generated wi= thout the optional cyclic redundancy check (CRC) data. Bit rate not allocat= ed to CRC data can be allocated to audio data, thus yielding improved audio= quality. > The USAC audio data is binary data, and must be specifically encoded for = non-binary transport; the Base64 encoding is suitable when attaching to Ema= il. Note that the MPEG audio data typically does not yield further compress= ion when using file-based lossless compression, e.g. zip. >=20 > 2.8 Security Considerations > USAC is a tagged data format, and some tags are available for private use= . As such, arbitrary material could potentially be transferred in the USAC= stream, including executable content. Tagged data containing executable co= ntent SHOULD never be sent and MUST not be executed if it is received. > Note: The requirement that such content must not be executed on receipt i= s especially important since situations exist where content will be generat= ed independently and therefore could contain executable content that the se= nder or receiver is unaware of. > It is the responsibility of the decoder/player client to respect and appl= y appropriate file security and protection against any potential malicious = content. > audio/usac objects are not signed or encrypted internally. External secur= ity mechanisms must be employed to ensure content confidentiality and integ= rity. >=20 > 2.9 Interoperability Considerations > The AAC family of codec technologies is specified in ISO/IEC 13818-7 as A= AC LC Profile, in ISO/IEC 14496-3 as AAC, HE-AAC and HE-AAC v2 Profiles, an= d in ISO/IEC 23003-3 as xHE-AAC Profile. Implementations of the AAC family = of technologies have reference software for reading and writing the file fo= rmat and are available for a variety of computer platforms. >=20 > 2.10 Published specification > ISO/IEC 23003-3 > ISO/IEC 14496-3 > ISO/IEC 13818-7 >=20 > 2.11 Application Usage > USAC audio is device, platform, and vendor neutral and is supported by a = wide range of encoders and decoders/players, for example for Multimedia, HL= S Audio-Only Streams - IETF HTTP Live Streaming, SHOUTcast/Icecast2 Audio S= treams. >=20 > 2.12 (not required) Fragment Identifier Considerations > none >=20 > 2.13 (not required) Restrictions on Usage > none >=20 > 2.14 (not required) Provisional Registrations > none >=20 > 2.15 Additional Information >=20 > 2.15.1 Deprecated alias names for this type > none >=20 > 2.15.2 Magic number(s) > Syncword for LOAS AudioSyncStream() 0x2B7 (11bit sequence) > Syncword for LOAS EPAudioSyncStream() 0x4DE1 (16bit sequence) >=20 > 2.15.3 File extension(s) > .loas (preferred) > .xhe >=20 > 2.15.4 Macintosh File Type Code(s) > none >=20 > 2.15.5 Object Identifier(s) or OID(s) - See RFC 1494 > none >=20 > 2.16 Intended Usage > Common >=20 > 2.17 (not required) Other Information & Comments > none >=20 > 2.18 Contact Person > Provide the contact for further information. See RFC 6838 =A75.5. >=20 > 2.18.1 Contact Name > Max Neuendorf >=20 > 2.18.2 Contact Email Address > max.neuendorf@iis.fraunhofer.de >=20 > 2.18.3 Author/Change Controller (for standards tree registrations, this i= s typically the standards body) > ISO/IEC JTC1/SC29/WG11 ("MPEG") >=20 >=20 >=20 >=20 >=20 > -- > Max Neuendorf > Audio > Fraunhofer-Institut f=FCr Integrierte Schaltungen IIS > Am Wolfsmantel 33 | D-91058 Erlangen > max.neuendorf@iis.fraunhofer.de | +49 9131 776-6020 >=20 >=20 >=20 >=20 > -----Original Message----- > From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of Neue= ndorf, Max > Sent: Monday, August 14, 2017 5:38 PM > To: media-types@iana.org > Cc: Schuyler Quackenbush > Subject: [media-types] Proposal for registration of media type "audio/usa= c" >=20 > Dear experts, >=20 > As a representative of the Audio Subgroup of ISO/IEC JTC1/SC29/WG11, a.k.= a. MPEG, I would like to propose the registration of the mime type, or medi= a type: >=20 > "audio/usac" >=20 > MPEG has produced a resolution which describes the necessary fields for r= egistration. This resolution can be found here for public download: >=20 > http://mpeg.chiariglione.org/standards/mpeg-d/unified-speech-and-audio-co= ding/mime-type-registration-isoiec-23003-3-mpeg-d-usac >=20 > Please follow the download link for w17022.zip. >=20 > With this e-mail I would kindly like to invite experts to review and comm= ent on the proposal as recommended in RFC6838, 5.2. >=20 > We intend to register this mime type in the Standards Tree for types "reg= istered by a recognized standards-related organization". >=20 > Note that there is a related review request for registration of "audio/aa= c". >=20 > Any feedback is welcome. >=20 > Kind regards, > Max Neuendorf >=20 >=20 > -- > Max Neuendorf > Audio > Fraunhofer-Institut f=FCr Integrierte Schaltungen IIS > Am Wolfsmantel 33 | D-91058 Erlangen > max.neuendorf@iis.fraunhofer.de | +49 9131 776-6020 >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Tue Sep 19 05:00:34 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D91321C7 for ; Tue, 19 Sep 2017 05:00:33 -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, 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 ZS0IOYH_Y3gt for ; Tue, 19 Sep 2017 05:00:26 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [192.0.33.72]) (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 B9CD0134218 for ; Tue, 19 Sep 2017 05:00:26 -0700 (PDT) Received: from mx-relay15-hz1.antispameurope.com (mx-relay15-hz1.antispameurope.com [94.100.132.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora2.lax.icann.org (Postfix) with ESMTPS id 822321E01E3 for ; Tue, 19 Sep 2017 12:00:25 +0000 (UTC) Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay15-hz1.antispameurope.com; Tue, 19 Sep 2017 13:51:01 +0200 Received: from mail.iis.fraunhofer.de (mail03.iis.fhg.de [153.96.171.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id D9C722400081; Tue, 19 Sep 2017 13:50:59 +0200 (CEST) Received: from mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) by mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 13:50:59 +0200 Received: from mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a]) by mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a%12]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 13:50:59 +0200 From: "Neuendorf, Max" To: Paul Libbrecht CC: "media-types@iana.org" , Schuyler Quackenbush , "Hofmann, Ingo" Thread-Topic: [media-types] Proposal for registration of media type "audio/usac" Thread-Index: AdMVEwIalEwzA8tVSSaI+3du+A5npQBWUDMgAAlFxgAAL0dqwAATHGiABmh7aVA= Date: Tue, 19 Sep 2017 11:50:58 +0000 Message-ID: <602bbece57664556a3ec06c7e70723aa@mail03.iis.fhg.de> References: <85263befc63f4747919a3efb035e766e@mail03.iis.fhg.de> <067d89103471467ea5ea71e478ea9043@mail03.iis.fhg.de> <65366D65-29B2-4B7C-ACEA-F8110940A28B@hoplahup.net> <82651627b03c42f6945ee347e2e0227b@mail03.iis.fhg.de> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [153.96.171.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-cloud-security-sender: max.neuendorf@iis.fraunhofer.de X-cloud-security-recipient: media-types@iana.org X-cloud-security-crypt: load encryption module X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay15-hz1.antispameurope.com with 19C5720205E60 X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.5.16 (pechora2.lax.icann.org [192.0.33.72]); Tue, 19 Sep 2017 12:00:25 +0000 (UTC) X-cloud-security: scantime:.4523 Archived-At: Subject: Re: [media-types] Proposal for registration of media type "audio/usac" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 12:00:33 -0000 SGkgUGF1bCwNCg0KSSdsbCB0cnkgdG8gYW5zd2VyIHRoZSBsYXN0IHBhcnQgb2YgeW91ciBtYWls Og0KDQoiDQo+IE1heWJlIGJvdGgsIGF1ZGlvL2FhYyBhbmQgYXVkaW8vdXNhYywgd2lsbCBmYWxs IHVuZGVyIHB1YmxpYy5tcGVnLTQtYXVkaW8uIE5vdCBzdXJlLCB0aG91Z2gsIGJlY2F1c2UgdGhv c2UgbWlnaHQgYXNzdW1lIHRoYXQgdGhlIGF1ZGlvIGNvbWVzIGluIGFuIE1QNCBGaWxlIENvbnRh aW5lci4gVGhhdCBpcyBzcGVjaWZpY2FsbHkgbm90IHRoZSBjYXNlIGZvciBhdWRpby9hYWMgYW5k IGF1ZGlvL3VzYWMuDQoNClRoYXQgc2VlbXMgdHJpY2t5IHRoZW4uIE1heWJlIHNwZWNpZnkgbW9y ZSB0aGFuIG9uZSBjbGlwYm9hcmQgZmxhdm91cj8/DQpTby4gSWYgaXQgaXMgbm90IHRoZSBjYXNl LCB0aGF0IG1wNC1jb250YWluZXJzIGFyZSBhbHdheXMgdXNlZOKApiBBcmUgYWxsIG90aGVyIGNv bnRhaW5lciBmb3JtYXRzIHJlY29nbmlzYWJsZSBieSBwZW9wbGUgd2hvIHdvdWxkIGFwcGx5IHRo ZXNlIG1lZGlhLXR5cGVzPw0KdGhhbmtzIGluIGFkdmFuY2UuDQpQYXVsDQoiDQoNClRoZSBvdGhl ciB0d28gKHJlbGV2YW50KSAoY29udGFpbmVyKSBmb3JtYXRzIGFyZSBBRFRTIGZvciAoYXVkaW8v YWFjKSBhbmQgTEFUTS9MT0FTIChmb3IgYXVkaW8vYWFjIGFuZCBhdWRpby91c2FjKS4gQm90aCBh cmUgcXVpdGUgbGVhbiBidXQgaGF2ZSBhIHN5bmN3b3JkIChzZWUgTWFnaWMgTnVtYmVycykgYW5k IHNob3VsZCBiZSBmYWlybHkgZWFzeSB0byBzcG90Lg0KDQpCZXN0LA0KTWF4DQoNCg0KLS0gDQpN YXjCoE5ldWVuZG9yZg0KQXVkaW8NCkZyYXVuaG9mZXItSW5zdGl0dXQgZsO8ciBJbnRlZ3JpZXJ0 ZSBTY2hhbHR1bmdlbiBJSVMNCkFtIFdvbGZzbWFudGVsIDMzIHwgRC05MTA1OMKgRXJsYW5nZW4N Cm1heC5uZXVlbmRvcmZAaWlzLmZyYXVuaG9mZXIuZGXCoHwgKzQ5IDkxMzEgNzc2LTYwMjANCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIExpYmJyZWNodCBbbWFp bHRvOnBhdWxAaG9wbGFodXAubmV0XSANClNlbnQ6IEZyaWRheSwgQXVndXN0IDE4LCAyMDE3IDEy OjU0IEFNDQpUbzogTmV1ZW5kb3JmLCBNYXgNCkNjOiBtZWRpYS10eXBlc0BpYW5hLm9yZzsgU2No dXlsZXIgUXVhY2tlbmJ1c2gNClN1YmplY3Q6IFJlOiBbbWVkaWEtdHlwZXNdIFByb3Bvc2FsIGZv ciByZWdpc3RyYXRpb24gb2YgbWVkaWEgdHlwZSAiYXVkaW8vdXNhYyINCg0KSGVsbG8gTWF4LA0K DQo+IE9uIDE3IEF1ZyAyMDE3LCBhdCAxMzo1MCwgTmV1ZW5kb3JmLCBNYXggPG1heC5uZXVlbmRv cmZAaWlzLmZyYXVuaG9mZXIuZGU+IHdyb3RlOg0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIHN1 Z2dlc3Rpb25zLiBJIHdpbGwgaGF2ZSB0byBsb29rIGludG8gdGhhdC4gSXQncyBub3QgbXkgaG9t ZSB0dXJmLg0KPiANCj4gSSBoYWQgYSBxdWljayBnbGFuY2UgYXQgQXBwbGUncyBVUklzIGFuZCBp dCBzZWVtcyB0aGV5IG5lZWQgdG8gYmUgcmVnaXN0ZXJlZCBieSBBcHBsZS4NCg0KSSBkb27igJl0 IHRoaW5rIHNvLg0KVGhpcyBkb2N1bWVudDoNCglodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20v bGlicmFyeS9jb250ZW50L2RvY3VtZW50YXRpb24vRmlsZU1hbmFnZW1lbnQvQ29uY2VwdHVhbC91 bmRlcnN0YW5kaW5nX3V0aXMvdW5kZXJzdGFuZF91dGlzX2RlY2xhcmUvdW5kZXJzdGFuZF91dGlz X2RlY2xhcmUuaHRtbCMvL2FwcGxlX3JlZi9kb2MvdWlkL1RQNDAwMDEzMTktQ0gyMDQtU1cxDQpz YXlzOg0KCSJNYWMgYXBwcyBjYW4gYWRkIG5ldyB1bmlmb3JtIHR5cGUgaWRlbnRpZmllcnMgZm9y IHByb3ByaWV0YXJ5IGRhdGEgZm9ybWF0cy4gWW91IGRlY2xhcmUgbmV3IFVUSXMgaW4gdGhlICBp bmZvcm1hdGlvbiBwcm9wZXJ0eSBsaXN0IChpbmZvLnBsaXN0KSBmaWxlIG9mIGEgYnVuZGxlLiBZ b3UgY2FuIGRlY2xhcmUgbmV3IFVUSXMgaW4gYW55IG9mIHRoZSBmb2xsb3dpbmc64oCdDQoNCkFu ZCBpdCBzYXlzIHF1aXRlIGxhdGVyIChTeXN0ZW0gRGVjbGFyZWQgVVRJcyk6DQoJTm90ZTogVGhl c2UgdGFibGVzIGxpc3Qgb25seSBVVElzIGRlY2xhcmVkIGJ5IHRoZSBzeXN0ZW0uIE90aGVyIFVU SXMgbWF5IGJlIGRlY2xhcmVkIHByaXZhdGVseSBieSBBcHBsZSBhcHBsaWNhdGlvbnMgKE1haWws IGZvciBleGFtcGxlKSBhbmQgdGhpcmQtcGFydHkgZGV2ZWxvcGVycy4NCg0KUmVnaXN0cmF0aW9u IG9mIDQtbGV0dGVyLWNvZGVzLCB0aGUgYW5jZXN0b3Igb2YgVVRJcyB3aGljaCBpcyBzdGlsbCBp biBtZWRpYS10eXBlLXJlZ2lzdHJhdGlvbnMsIHdhcyBpbmRlZWQgbmVjZXNzYXJ5Lg0KDQo+IE1h eWJlIGJvdGgsIGF1ZGlvL2FhYyBhbmQgYXVkaW8vdXNhYywgd2lsbCBmYWxsIHVuZGVyIHB1Ymxp Yy5tcGVnLTQtYXVkaW8uIE5vdCBzdXJlLCB0aG91Z2gsIGJlY2F1c2UgdGhvc2UgbWlnaHQgYXNz dW1lIHRoYXQgdGhlIGF1ZGlvIGNvbWVzIGluIGFuIE1QNCBGaWxlIENvbnRhaW5lci4gVGhhdCBp cyBzcGVjaWZpY2FsbHkgbm90IHRoZSBjYXNlIGZvciBhdWRpby9hYWMgYW5kIGF1ZGlvL3VzYWMu DQoNCg0KVGhhdCBzZWVtcyB0cmlja3kgdGhlbi4gTWF5YmUgc3BlY2lmeSBtb3JlIHRoYW4gb25l IGNsaXBib2FyZCBmbGF2b3VyPz8NCg0KU28uIElmIGl0IGlzIG5vdCB0aGUgY2FzZSwgdGhhdCBt cDQtY29udGFpbmVycyBhcmUgYWx3YXlzIHVzZWTigKYgQXJlIGFsbCBvdGhlciBjb250YWluZXIg Zm9ybWF0cyByZWNvZ25pc2FibGUgYnkgcGVvcGxlIHdobyB3b3VsZCBhcHBseSB0aGVzZSBtZWRp YS10eXBlcz8NCg0KdGhhbmtzIGluIGFkdmFuY2UuDQoNClBhdWwNCg== From nobody Tue Sep 19 06:33:31 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4F13431E for ; Tue, 19 Sep 2017 06:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvmTXo_ppcO4 for ; Tue, 19 Sep 2017 06:33:26 -0700 (PDT) Received: from mx-relay22-hz1.antispameurope.com (mx-relay22-hz1.antispameurope.com [94.100.132.222]) (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 E8DCF13431A for ; Tue, 19 Sep 2017 06:33:24 -0700 (PDT) Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay22-hz1.antispameurope.com; Tue, 19 Sep 2017 15:33:20 +0200 Received: from mail.iis.fraunhofer.de (mail03.iis.fhg.de [153.96.171.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id 84B9F2400082; Tue, 19 Sep 2017 15:33:19 +0200 (CEST) Received: from mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) by mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 15:33:19 +0200 Received: from mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a]) by mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a%12]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 15:33:19 +0200 From: "Neuendorf, Max" To: Sean Leonard , "media-types@ietf.org" CC: Schuyler Quackenbush , "Hofmann, Ingo" Thread-Topic: [media-types] Proposal for registration of media type "audio/aac" Thread-Index: AdMVEPVSndRFqJcNTtaZO1drMOGNsgAn7bOAAC2S4XAA7ERlAAXJZt/Q Date: Tue, 19 Sep 2017 13:33:18 +0000 Message-ID: References: <24436b2c95ff493d8e5cdde1b2cab20a@mail03.iis.fhg.de> <8aab6f0a-47cc-1c77-5109-c926c0b91148@seantek.com> <3e1ce81e-e4fe-e767-fd42-171714800946@seantek.com> In-Reply-To: <3e1ce81e-e4fe-e767-fd42-171714800946@seantek.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [153.96.171.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-cloud-security-sender: max.neuendorf@iis.fraunhofer.de X-cloud-security-recipient: media-types@ietf.org X-cloud-security-crypt: load encryption module X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay22-hz1.antispameurope.com with A4A5C1189919 X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4 X-cloud-security: scantime:.2238 Archived-At: Subject: Re: [media-types] Proposal for registration of media type "audio/aac" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 13:33:29 -0000 RGVhciBTZWFuLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suDQoNClRoYXQgZG90IGlz IG9mIGNvdXJzZSBub3QgYW4gaXNzdWUuIEknbGwgZml4IGl0LiBUaGFua3MgZm9yIHBvaW50aW5n IChzaWMhKSB0aGlzIG91dCA7LSkNCg0KUmVnYXJkaW5nIHRoZSBNYWdpYyBOdW1iZXJzLCBTeW5j d29yZHM6DQpJbiB0aGUgd2F5IHRoYXQgeW91IChpLmUuIFJGQzY4MzgpIGRlc2NyaWJlIHRoZSBN YWdpYyBOdW1iZXJzLCBJIHdvdWxkIHNheSB0aGF0IHRoZSBTeW5jd29yZHMgdGhhdCBJIGxpc3Rl ZCBhcmUgcHJvYmFibHkgbm90IHRvIGJlIGxpc3RlZCB0aGVyZS4NCk9uZSBjb3VsZCBzYXkgdGhh dCBpdCBpcyBpbiB0aGUgdmVyeSBuYXR1cmUgb2YgU3luY3dvcmRzIHRoYXQgdGhleSBtYXkgb2Nj dXIgYW55d2hlcmUgd2l0aGluIHRoZSByZWNlaXZlZCBtZWRpYSBzdHJlYW0gKHRob3VnaCB0aHVz IGluZGljYXRpbmcgdGhlIHN0YXJ0IG9mIGEgbmV3IGZyYW1lKS4gSWRlYWxseSBvZiBjb3Vyc2Us IHRoZSBzeW5jd29yZCBpcyBhdCB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhlIGRhdGEuIERlY29k ZXJzIGNhbm5vdCByZWx5IG9uIHRoaXMsIHRob3VnaC4NCkkgdHJpZWQgdG8gY2FwdHVyZSB0aGlz IGFzcGVjdCBieSB1c2luZyAiU0hPVUxEIiBpbnN0ZWFkIG9mICJTSEFMTCIgaW4gdGhlIGZvbGxv d2luZzogDQoNCiJSZWNlaXZlcnMgY2FuIGRpc3Rpbmd1aXNoIHRoZSB0d28gW0FEVFMgb3IgTEFU TVUvTE9BU10gYnkgaW5zcGVjdGluZyB0aGUgYmluYXJ5IGRhdGEgc3RyZWFtIGFuZCBzZWFyY2hp bmcgZm9yIHRoZSBzeW5jd29yZHMgYXMgbGlzdGVkIGluIHN1YmNsYXVzZSAiTWFnaWMgbnVtYmVy KHMpIi4gDQpUaGUgc3luY3dvcmQgU0hPVUxEIGJlIHRoZSBmaXJzdCBiaXRzIHRoYXQgYXJlIHJl Y2VpdmVkIGZyb20gYSBzZXJ2ZXIgd2hlbiByZXF1ZXN0aW5nIGRhdGEgaWRlbnRpZmllZCB3aXRo IHRoaXMgbWltZSB0eXBlLiINCg0KSW4gc2hvcnQsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBnaXZl IGEgcmVsaWFibGUgYnl0ZSBvZmZzZXQgYXQgd2hpY2ggdGhlIHN5bmN3b3JkcyBjYW4gYmUgZm91 bmQuIEluIGNvbnNlcXVlbmNlIEkgd291bGQgY29uY2x1ZGUgdGhhdCBJIHJlbW92ZSB0aGUgc3lu Y3dvcmRzIGZyb20gdGhlIE1hZ2ljIE51bWJlcnMgc2VjdGlvbiBhbmQgbWVyZ2UgdGhlbSBpbnRv IHRoZSBzZWN0aW9uIEVuY29kaW5nIENvbnNpZGVyYXRpb25zLg0KDQpJbiBhZGRpdGlvbiwgaXQg aXMgb2YgY291cnNlIGFsd2F5cyBwb3NzaWJsZSB0aGF0IHRoZSBzeW5jd29yZCBvY2N1cnMgaW4g dGhlIG1lZGlhIHN0cmVhbSBieSBwdXJlIGNoYW5jZS4gU28gdGhlIGRldGVjdGlvbiBvZiB0aGUg cHJlc2VuY2Ugb2YgdGhpcyBtYWdpYyBudW1iZXIgYW55d2hlcmUgaW4gdGhlIHN0cmVhbSBkb2Vz IG5vdCBhbHdheXMgX3JlbGlhYmx5XyBpZGVudGlmeSB0aGUgZm9ybWF0IHR5cGUuDQoNCg0KQmVz dCwNCk1heA0KDQoNCi0tIA0KTWF4wqBOZXVlbmRvcmYNCkF1ZGlvDQpGcmF1bmhvZmVyLUluc3Rp dHV0IGbDvHIgSW50ZWdyaWVydGUgU2NoYWx0dW5nZW4gSUlTDQpBbSBXb2xmc21hbnRlbCAzMyB8 IEQtOTEwNTjCoEVybGFuZ2VuDQptYXgubmV1ZW5kb3JmQGlpcy5mcmF1bmhvZmVyLmRlwqB8ICs0 OSA5MTMxIDc3Ni02MDIwDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBtZWRpYS10eXBlcyBbbWFpbHRvOm1lZGlhLXR5cGVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTZWFuIExlb25hcmQNClNlbnQ6IE1vbmRheSwgQXVndXN0IDIxLCAyMDE3IDQ6NTQg QU0NClRvOiBtZWRpYS10eXBlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttZWRpYS10eXBlc10g UHJvcG9zYWwgZm9yIHJlZ2lzdHJhdGlvbiBvZiBtZWRpYSB0eXBlICJhdWRpby9hYWMiDQoNClVw b24gcmV2aWV3IG9mIHRoaXMsIHRoZSBvbmx5IHNob3dzdG9wcGVyIGlzIHRoYXQgdGhlIGNoYXJh Y3RlciDigKIgaXMgDQpwcmVzZW50IGluIHRoZSByZWdpc3RyYXRpb24sIHdoaWNoIEkgYmVsaWV2 ZSBpcyBub3QgYWxsb3dlZC4gT25seSANCnByaW50YWJsZSBBU0NJSSBjaGFyYWN0ZXJzIGFyZSBh bGxvd2VkIGluIHJlZ2lzdHJhdGlvbnMgYXQgdGhpcyB0aW1lLiANCihJdCdzIGEgcGVkYW50aWMg Y29uY2VybiwgYnV0IHRoYXQncyB0aGUgd2F5IGl0IGlzLiBSRkMgNjgzOC90aGUgDQpyZWdpc3Ry YXRpb24gcHJvY2VkdXJlIHNob3VsZCBwcm9iYWJseSBiZSB1cGRhdGVkIGF0IHNvbWUgcG9pbnQu KQ0KDQpBcyBhIHN1Z2dlc3Rpb24vY29uY2VybiwgSSB0aGluayB0aGF0IHRoZSBtYWdpYyBudW1i ZXIocykgZmllbGQgc2hvdWxkIA0Kc3BlY2lmeSB0aGUgcG9zaXRpb24gb2YgdGhvc2UgYnl0ZXMg aW4gdGhlIGJ5dGUgc3RyZWFtLCB3aXRob3V0IA0KcmVmZXJlbmNlIHRvIHN0cnVjdHVyZXMgaW4g dGhlIGZvcm1hdCBpdHNlbGYuIFJGQyA2ODM4IHNheXM6ICJNYWdpYyANCm51bWJlcnMgYXJlIGJ5 dGUgc2VxdWVuY2VzIHRoYXQgYXJlIGFsd2F5cyBwcmVzZW50IGF0IGEgZ2l2ZW4gcGxhY2UgaW4g DQp0aGUgZmlsZSBhbmQgdGh1cyBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSBlbnRpdGllcyBhcyBi ZWluZyBvZiBhIGdpdmVuIA0KbWVkaWEgdHlwZS4iIEJhc2ljYWxseSB0aGUgaWRlYSBpczogaWYg eW91IGhhdmUgYSByYW5kb20gYmxvYiBvZiBieXRlcyANCmFuZCBhIG1lZGlhIHR5cGUgc2Vydmlj ZSAoZS5nLiwgSFRUUCwgZS1tYWlsIGNsaWVudCkgdHJpZXMgdG8gc2VydmUgaXQsIA0KY2FuIHRo ZSBzZXJ2aWNlIHNuaWZmIHRoZSBjb250ZW50IHdpdGhvdXQga25vd2luZyBtdWNoIG9mIGFueXRo aW5nIGFib3V0IA0Kd2hhdCBpdCBpcywgYW5kIHNlcnZlIGl0IGFzIHRoaXMgbWVkaWEgdHlwZT8g U28sIHRoaXMgZmllbGQgc2hvdWxkIHNheSANCndoZXJlIDB4MkI3IG9jY3VycyBhcyBhbiBleGFj dCBvZmZzZXQgZnJvbSB0aGUgYmVnaW5uaW5nIG9mIHRoZSBjb250ZW50LCANCm9yIGEgd2F5IHRv IHVzZSB0aGUgZmlyc3QgZmV3IGJ5dGVzIG9mIHRoZSBjb250ZW50IHRvIGZpZ3VyZSBvdXQgdGhl IA0KdmFyaWFibGUgb2Zmc2V0Lg0KDQpSZWdhcmRzLA0KDQpTZWFuDQoNCk9uIDgvMTYvMjAxNyAx OjM0IEFNLCBOZXVlbmRvcmYsIE1heCB3cm90ZToNCj4gSGkgU2VhbiwNCj4NCj4gdGhhbmtzIGZv ciB0aGUgcXVpY2sgcmVzcG9uc2UuDQo+DQo+IEFBQyBpcyBzaG9ydCBmb3IgIkFkdmFuY2VkIEF1 ZGlvIENvZGluZyIuDQo+IEkgcmVhbGl6ZSB0aGF0IHRoaXMgaXMgbm90IGV4cGxpY2l0bHkgc3Bl bGxlZCBvdXQgaW4gdGhlIHJlZ2lzdHJhdGlvbi4gTmVlZHMgdG8gYmUgZml4ZWQuDQo+IEFBQyBp cyBhIGpvaW50IGRldmVsb3BtZW50IG9mIGEgbGFyZ2VyIGdyb3VwIG9mIGNvbXBhbmllcywgbW9z dCBub3RhYmx5IEZyYXVuaG9mZXIgSUlTLCBEb2xieSwgYW5kIFBoaWxpcHMuDQo+DQo+IFRoZXJl IGFyZSB2YXJpb3VzICJmbGF2b3JzIiBvZiBBQUMuDQo+IFRoaXMgbWVkaWEgdHlwZSB0YXJnZXRz IE1QRUctNCBBQUMgKElTTy9JRUMgMTQ0OTYtMykuDQo+IEl0IGlzIGEgc3VjY2Vzc29yIG9mIE1Q RUctMiBBQUMgKElTTy9JRUMgMTM4MTgtNykgd2hpY2ggVGhvbWFzIEVkd2FyZHMgY29ycmVjdGx5 IHBvaW50ZWQgdG8uDQo+DQo+IE9uIHRoZSB2YXJpb3VzIGZpbGUgZXh0ZW5zaW9uOiBJIGFtIGd1 ZXNzaW5nIHRoZXkgYWxsIGluZGljYXRlIG1wNCBmaWxlcyAobWVkaWEgaW4gTVA0LUZpbGVmb3Jt YXQpIHdpdGggdmFyaW91cyBjb250ZW50Lg0KPiBlLmcuIG00djogTVBFRy00IHZpZGVvIChwb3Nz aWJseSB3aXRoIGF1ZGlvKSwgbTRhOiBNUEVHLTQgYXVkaW8gb25seSwgbTRiOiBBdWRpbyBCb29r cyAocG9zc2libHkgRFJNIHByb3RlY3RlZCkuDQo+DQo+IFRoZSBwcmVzZW50IHJlZ2lzdHJhdGlv biBpcyBmb3IgYXVkaW8gd2hpY2ggaXMgTk9UIGluIE1QNC1GaWxlZm9ybWF0LCBidXQgaW4gTEFU TS9MT0FTIG9yIEFEVFMgZm9ybWF0IGluc3RlYWQuDQo+IEF1ZGlvIChhbHNvIEFBQykgaW4gTVA0 LUZpbGVmb3JtYXQgaXMgc2lnbmFsZWQgdGhyb3VnaCBhdWRpby9tcDQgd2l0aCBhbiBhcHByb3By aWF0ZSBwYXJhbWV0ZXIgKGUuZy4gbXA0YS40MC4yKS4NCj4NCj4NCj4gSGVyZSBjb21lcyB0aGUg cHJvcG9zZWQgdGV4dCBmb3IgdGhlIHJlZ2lzdHJhdGlvbjoNCj4NCj4gMi4xCUZ1bGwgTmFtZQ0K PiBNYXggTmV1ZW5kb3JmDQo+DQo+IDIuMglFLU1haWwNCj4gbWF4Lm5ldWVuZG9yZkBpaXMuZnJh dW5ob2Zlci5kZQ0KPg0KPiAyLjMJVHlwZSBOYW1lDQo+ICJhdWRpbyINCj4NCj4gMi40CVN1YnR5 cGUgTmFtZQ0KPiBTdGFuZGFyZHMgVHJlZSAobm8gcHJlZml4KQ0KPiAiYWFjIg0KPg0KPiAyLjUJ UmVxdWlyZWQgUGFyYW1ldGVycw0KPiBub25lDQo+DQo+IDIuNglPcHRpb25hbCBQYXJhbWV0ZXJz DQo+IG5vbmUNCj4NCj4gMi43CUVuY29kaW5nIENvbnNpZGVyYXRpb25zDQo+IEJpbmFyeQ0KPg0K PiBGaWxlcyBhcmUgZW5jb2RlZCBiaW5hcnkgQUFDIGF1ZGlvIHBhY2tlZCBpbiBvbmUgb2YgdGhl IGZvbGxvd2luZyBNUEVHLTQgYXVkaW8gZm9ybWF0cw0KPiDigKIJTG93IE92ZXJoZWFkIEF1ZGlv IFRyYW5zcG9ydCBNdWx0aXBsZXggLyBMb3cgT3ZlcmhlYWQgQXVkaW8gU3RyZWFtIChMQVRNL0xP QVMpIGFzIGRlZmluZWQgaW4gSVNPL0lFQyAxNDQ5Ni0zDQo+IOKAoglBdWRpbyBEYXRhIFRyYW5z cG9ydCBTdHJlYW0gKEFEVFMpIGFzIGRlZmluZWQgaW4gSVNPL0lFQyAxNDQ5Ni0zDQo+IFJlY2Vp dmVycyBjYW4gZGlzdGluZ3Vpc2ggdGhlIHR3byBieSBpbnNwZWN0aW5nIHRoZSBiaW5hcnkgZGF0 YSBzdHJlYW0gYW5kIHNlYXJjaGluZyBmb3IgdGhlIHN5bmN3b3JkcyBhcyBsaXN0ZWQgaW4gc3Vi Y2xhdXNlICJNYWdpYyBudW1iZXIocykiLg0KPiBUaGUgc3luY3dvcmQgU0hPVUxEIGJlIHRoZSBm aXJzdCBiaXRzIHRoYXQgYXJlIHJlY2VpdmVkIGZyb20gYSBzZXJ2ZXIgd2hlbiByZXF1ZXN0aW5n IGRhdGEgaWRlbnRpZmllZCB3aXRoIHRoaXMgbWltZSB0eXBlLg0KPiBFbmNvZGVkIGF1ZGlvIGZp bGVzIHBhY2tlZCBpbiBMQVRNL0xPQVMgZm9ybWF0IFNIT1VMRCBoYXZlIHRoZSBmaWxlIGV4dGVu c2lvbiAiLmxvYXMiLg0KPiBFbmNvZGVkIGF1ZGlvIGZpbGVzIHBhY2tlZCBpbiBBRFRTIGZvcm1h dCBTSE9VTEQgaGF2ZSB0aGUgZmlsZSBleHRlbnNpb24gIi5hYWMiLg0KPiBGaWxlcyBTSEFMTCBi ZSB0cmFuc21pdHRlZCB3aXRob3V0IENSL0xGIGNvbnZlcnNpb24sIDctYml0IHN0cmlwcGluZywg b3IgYW55IG90aGVyIG1vZGlmaWNhdGlvbiB0byB0aGUgYmluYXJ5IGRhdGEuDQo+IEZpbGVzIE1B WSBjb250YWluIElEM3YyLnggZnJhbWVzIGF0IGFueSBmcmFtZSBib3VuZGFyeS4NCj4gRm9yIHVz ZSBvdmVyIHRoZSBJbnRlcm5ldCwgaXQgaXMgYXNzdW1lZCB0aGF0IGxvd2VyIGxheWVycyB0YWtl IGNhcmUgb2YgdHJhbnNtaXNzaW9uIGVycm9ycywgc28gYXVkaW8vYWFjIGRhdGEgTUFZIGluY2x1 ZGUgZnJhbWVzIHdpdGhvdXQgdGhlIG9wdGlvbmFsIGN5Y2xpYyByZWR1bmRhbmN5IGNoZWNrIChD UkMpLg0KPiBUaGUgQUFDIGF1ZGlvIGRhdGEgaXMgYmluYXJ5IGRhdGEsIGFuZCBtdXN0IGJlIHNw ZWNpZmljYWxseSBlbmNvZGVkIGZvciBub24tYmluYXJ5IHRyYW5zcG9ydDsgdGhlIEJhc2U2NCBl bmNvZGluZyBpcyBzdWl0YWJsZSB3aGVuIGF0dGFjaGluZyB0byBFbWFpbC4gTm90ZSB0aGF0IHRo ZSBNUEVHIGF1ZGlvIGRhdGEgdHlwaWNhbGx5IGRvZXMgbm90IHlpZWxkIGZ1cnRoZXIgY29tcHJl c3Npb24gd2hlbiB1c2luZyBmaWxlLWJhc2VkIGxvc3NsZXNzIGNvbXByZXNzaW9uLCBlLmcuIHpp cC4NCj4NCj4gMi44CVNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+IEFBQyBpcyBhIHRhZ2dlZCBk YXRhIGZvcm1hdCwgYW5kIHNvbWUgdGFncyBhcmUgYXZhaWxhYmxlIGZvciBwcml2YXRlIHVzZSAo ZS5nLiB0aGUgRGF0YSBTdHJlYW0gRWxlbWVudCkuICBBcyBzdWNoLCBhcmJpdHJhcnkgbWF0ZXJp YWwgY291bGQgcG90ZW50aWFsbHkgYmUgdHJhbnNmZXJyZWQgaW4gdGhlIEFBQyBzdHJlYW0sIGlu Y2x1ZGluZyBleGVjdXRhYmxlIGNvbnRlbnQuIFRhZ2dlZCBkYXRhIGNvbnRhaW5pbmcgZXhlY3V0 YWJsZSBjb250ZW50IFNIT1VMRCBuZXZlciBiZSBzZW50IGFuZCBNVVNUIG5vdCBiZSBleGVjdXRl ZCBpZiBpdCBpcyByZWNlaXZlZC4NCj4gTm90ZTogVGhlIHJlcXVpcmVtZW50IHRoYXQgc3VjaCBj b250ZW50IG11c3Qgbm90IGJlIGV4ZWN1dGVkIG9uIHJlY2VpcHQgaXMgZXNwZWNpYWxseSBpbXBv cnRhbnQgc2luY2Ugc2l0dWF0aW9ucyBleGlzdCB3aGVyZSBjb250ZW50IHdpbGwgYmUgZ2VuZXJh dGVkIGluZGVwZW5kZW50bHkgYW5kIHRoZXJlZm9yZSBjb3VsZCBjb250YWluIGV4ZWN1dGFibGUg Y29udGVudCB0aGF0IHRoZSBzZW5kZXIgb3IgcmVjZWl2ZXIgaXMgdW5hd2FyZSBvZi4NCj4gSXQg aXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBkZWNvZGVyL3BsYXllciBjbGllbnQgdG8gcmVz cGVjdCBhbmQgYXBwbHkgYXBwcm9wcmlhdGUgZmlsZSBzZWN1cml0eSBhbmQgcHJvdGVjdGlvbiBh Z2FpbnN0IGFueSBwb3RlbnRpYWwgbWFsaWNpb3VzIGNvbnRlbnQuDQo+IGF1ZGlvL2FhYyBvYmpl Y3RzIGFyZSBub3Qgc2lnbmVkIG9yIGVuY3J5cHRlZCBpbnRlcm5hbGx5LiBFeHRlcm5hbCBzZWN1 cml0eSBtZWNoYW5pc21zIG11c3QgYmUgZW1wbG95ZWQgdG8gZW5zdXJlIGNvbnRlbnQgY29uZmlk ZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuDQo+DQo+IDIuOQlJbnRlcm9wZXJhYmlsaXR5IENvbnNp ZGVyYXRpb25zDQo+IFRoZSBBQUMgZmFtaWx5IG9mIGNvZGVjIHRlY2hub2xvZ2llcyBpcyBzcGVj aWZpZWQgaW4gSVNPL0lFQyAxMzgxOC03IGFzIEFBQyBMQyBQcm9maWxlLCBpbiBJU08vSUVDIDE0 NDk2LTMgYXMgQUFDLCBIRS1BQUMgYW5kIEhFLUFBQyB2MiBQcm9maWxlcy4gSW1wbGVtZW50YXRp b25zIG9mIHRoZSBBQUMgZmFtaWx5IG9mIHRlY2hub2xvZ2llcyBoYXZlIHJlZmVyZW5jZSBzb2Z0 d2FyZSBmb3IgcmVhZGluZyBhbmQgd3JpdGluZyB0aGUgZmlsZSBmb3JtYXQgYW5kIGFyZSBhdmFp bGFibGUgZm9yIGEgdmFyaWV0eSBvZiBjb21wdXRlciBwbGF0Zm9ybXMuDQo+IDIuMTAJUHVibGlz aGVkIHNwZWNpZmljYXRpb24NCj4gSVNPL0lFQyAxNDQ5Ni0zDQo+IElTTy9JRUMgMTM4MTgtNw0K Pg0KPiAyLjExCUFwcGxpY2F0aW9uIFVzYWdlDQo+IEFBQyBhdWRpbyBpcyBkZXZpY2UsIHBsYXRm b3JtLCBhbmQgdmVuZG9yIG5ldXRyYWwgYW5kIGlzIHN1cHBvcnRlZCBieSBhIHdpZGUgcmFuZ2Ug b2YgZW5jb2RlcnMgYW5kIGRlY29kZXJzL3BsYXllcnMsIGZvciBleGFtcGxlIGZvciBNdWx0aW1l ZGlhLCBITFMgQXVkaW8tT25seSBTdHJlYW1zIC0gSUVURiBIVFRQIExpdmUgU3RyZWFtaW5nLCBT SE9VVGNhc3QvSWNlY2FzdDIgQXVkaW8gU3RyZWFtcy4NCj4NCj4gMi4xMgkobm90IHJlcXVpcmVk KSBGcmFnbWVudCBJZGVudGlmaWVyIENvbnNpZGVyYXRpb25zDQo+IG5vbmUNCj4NCj4gMi4xMwko bm90IHJlcXVpcmVkKSBSZXN0cmljdGlvbnMgb24gVXNhZ2UNCj4gbm9uZQ0KPg0KPiAyLjE0CShu b3QgcmVxdWlyZWQpIFByb3Zpc2lvbmFsIFJlZ2lzdHJhdGlvbnMNCj4gbm9uZQ0KPg0KPiAyLjE1 CUFkZGl0aW9uYWwgSW5mb3JtYXRpb24NCj4NCj4gMi4xNS4xCURlcHJlY2F0ZWQgYWxpYXMgbmFt ZXMgZm9yIHRoaXMgdHlwZQ0KPiBub25lDQo+DQo+IDIuMTUuMglNYWdpYyBudW1iZXIocykNCj4g U3luY3dvcmQgZm9yIExPQVMgQXVkaW9TeW5jU3RyZWFtKCkgMHgyQjcgKDExYml0IHNlcXVlbmNl KQ0KPiBTeW5jd29yZCBmb3IgTE9BUyBFUEF1ZGlvU3luY1N0cmVhbSgpIDB4NERFMSAoMTZiaXQg c2VxdWVuY2UpDQo+IFN5bmN3b3JkIGZvciBBRFRTIGFkdHNfc2VxdWVuY2UoKSAweEZGRiAoMTJi aXQgc2VxdWVuY2UpDQo+DQo+IDIuMTUuMwlGaWxlIGV4dGVuc2lvbihzKQ0KPiAuYWR0cyBvciAu YWFjIChpZiBwYXlsb2FkIGlzIHBhY2tlZCBpbiBBRFRTIGZvcm1hdCkNCj4gLmxvYXMgb3IgLmFz cyAoaWYgcGF5bG9hZCBpcyBwYWNrZWQgaW4gTEFUTS9MT0FTIGZvcm1hdCkNCj4NCj4gMi4xNS40 CU1hY2ludG9zaCBGaWxlIFR5cGUgQ29kZShzKQ0KPiBub25lDQo+DQo+IDIuMTUuNQlPYmplY3Qg SWRlbnRpZmllcihzKSBvciBPSUQocykg4oCUIFNlZSBSRkMgMTQ5NA0KPiBub25lDQo+DQo+IDIu MTYJSW50ZW5kZWQgVXNhZ2UNCj4gQ29tbW9uDQo+DQo+IDIuMTcJKG5vdCByZXF1aXJlZCkgT3Ro ZXIgSW5mb3JtYXRpb24gJiBDb21tZW50cw0KPiBub25lDQo+DQo+IDIuMTgJQ29udGFjdCBQZXJz b24NCj4gUHJvdmlkZSB0aGUgY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbi4gU2VlIFJG QyA2ODM4IMKnNS41Lg0KPg0KPiAyLjE4LjEJQ29udGFjdCBOYW1lDQo+IE1heCBOZXVlbmRvcmYN Cj4NCj4gMi4xOC4yCUNvbnRhY3QgRW1haWwgQWRkcmVzcw0KPiBtYXgubmV1ZW5kb3JmQGlpcy5m cmF1bmhvZmVyLmRlDQo+DQo+IDIuMTguMwlBdXRob3IvQ2hhbmdlIENvbnRyb2xsZXIgKGZvciBz dGFuZGFyZHMgdHJlZSByZWdpc3RyYXRpb25zLCB0aGlzIGlzIHR5cGljYWxseSB0aGUgc3RhbmRh cmRzIGJvZHkpDQo+IElTTy9JRUMgSlRDMS9TQzI5L1dHMTEgKGEuIGsuIGEuICJNUEVHIikNCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbWVkaWEtdHlwZXMgbWFpbGluZyBsaXN0DQptZWRpYS10eXBlc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWRpYS10eXBlcw0K From nobody Mon Sep 25 06:01:57 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD301342FE for ; Mon, 25 Sep 2017 06:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 J9gIlonbvA5v for ; Mon, 25 Sep 2017 06:01:53 -0700 (PDT) Received: from mx-relay22-hz1.antispameurope.com (mx-relay22-hz1.antispameurope.com [94.100.132.222]) (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 7F74F1342F8 for ; Mon, 25 Sep 2017 06:01:50 -0700 (PDT) Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay22-hz1.antispameurope.com; Mon, 25 Sep 2017 15:01:48 +0200 Received: from mail.iis.fraunhofer.de (mail01.iis.fhg.de [153.96.171.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id B05162400081; Mon, 25 Sep 2017 15:01:47 +0200 (CEST) Received: from mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) by mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 25 Sep 2017 15:01:47 +0200 Received: from mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a]) by mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a%12]) with mapi id 15.00.1263.000; Mon, 25 Sep 2017 15:01:47 +0200 From: "Neuendorf, Max" To: Chris Lilley , "media-types@ietf.org" Thread-Topic: [media-types] Proposal for registration of media type "audio/usac" Thread-Index: AdMVEwIalEwzA8tVSSaI+3du+A5npQBWUDMgAAOCaYAH3rUgYA== Date: Mon, 25 Sep 2017 13:01:46 +0000 Message-ID: <57c2101eb6014490b86025ebf38fac53@mail03.iis.fhg.de> References: <85263befc63f4747919a3efb035e766e@mail03.iis.fhg.de> <067d89103471467ea5ea71e478ea9043@mail03.iis.fhg.de> <6dfee3e5-2bcb-aaf7-eb24-03ba21c4568b@w3.org> In-Reply-To: <6dfee3e5-2bcb-aaf7-eb24-03ba21c4568b@w3.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [153.96.171.210] Content-Type: multipart/alternative; boundary="_000_57c2101eb6014490b86025ebf38fac53mail03iisfhgde_" MIME-Version: 1.0 X-cloud-security-sender: max.neuendorf@iis.fraunhofer.de X-cloud-security-recipient: media-types@ietf.org X-cloud-security-crypt: load encryption module X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay22-hz1.antispameurope.com with D7C34118608A X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4 X-cloud-security: scantime:.1453 Archived-At: Subject: Re: [media-types] Proposal for registration of media type "audio/usac" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:01:55 -0000 --_000_57c2101eb6014490b86025ebf38fac53mail03iisfhgde_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDaHJpcywNCg0KSSBmaW5hbGx5IGhhZCBzb21lIHRpbWUgdG8gaGF2ZSBhIGxvb2sgYXQg dGhpcyBhbmQgZGlzY3VzcyB0aGlzIGluLWhvdXNlIHdpdGggc29tZSBtZWRpYSB0cmFuc3BvcnQg ZXhwZXJ0cy4NCg0KQWZ0ZXIgcmV2aWV3IG9mIHRoZSBsaW5rZWQgVzNDIHNwZWMsIHdlIGNvbmNs dWRlZCB0aGF0IGl0IGlzIHByb2JhYmx5IG5vdCBhcHBsaWNhYmxlIGZvciBhdWRpby91c2FjIG5v ciBhdWRpby9hYWMuDQpBdCBsZWFzdCB3ZSBoYWQgbm8gaWRlYSBob3cgdG8gc2Vuc2libHkgb3Ig cHJhY3RpY2FsbHkgbWFrZSB1c2Ugb2YgdGhlIGRlc2NyaWJlZCBtZWRpYSBmcmFnbWVudCBzeW50 YXggaW4gY29tYmluYXRpb24gd2l0aCB0aGUgYSBwYWNrZXRlZCBzdHJlYW0sIHN1Y2ggYXMgTEFU TS9MT0FTLg0KDQpBZG1pdHRlZGx5IEkgaGFkIG9yaWdpbmFsbHkgbGVmdCB0aGlzIHBhcnQgb2Yg dGhlIGFwcGxpY2F0aW9uIGJsYW5rLCBiZWNhdXNlIGl0IHNhaWQg4oCcKG5vdCByZXF1aXJlZCni gJ0gYW5kIGFsc28gSSB3YXMgbm90IHN1cmUgd2hhdCB0aGlzIHdhcyBhYm91dC4gKEFuZCBhbHNv IHRoZXJlIHdlcmUgbm8gc2ltaWxhciBlbnRyaWVzIGZvciBhdWRpby9tcGVnLikNCg0KQ2FuIHlv dSBnaXZlIHNvbWUgcmVmZXJlbmNlIGZvciB0aGUgcHJhY3RpY2FsIHJlbGV2YW5jZSBvZiB0aGVz ZSBtZWRpYSBmcmFnbWVudHMsIGUuZy4gZXhhbXBsZXMgb2Ygd2hlcmUgdGhpcyBpcyBiZWluZyB1 c2VkPw0KT3RoZXJ3aXNlLCBJIHdvdWxkIGJlIGluY2xpbmVkIHRvIGtlZXAgdGhpcyBmaWVsZCBv ZiB0aGUgYXBwbGljYXRpb24gZW1wdHkuDQoNClRoYW5rcyBhbmQgQmVzdCwNCk1heA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWF4IE5ldWVuZG9yZg0KQXVkaW8NCkZyYXVu aG9mZXItSW5zdGl0dXQgZsO8ciBJbnRlZ3JpZXJ0ZSBTY2hhbHR1bmdlbiBJSVMNCkFtIFdvbGZz bWFudGVsIDMzIHwgRC05MTA1OCBFcmxhbmdlbg0KbWF4Lm5ldWVuZG9yZkBpaXMuZnJhdW5ob2Zl ci5kZTxtYWlsdG86bWF4Lm5ldWVuZG9yZkBpaXMuZnJhdW5ob2Zlci5kZT4gfCArNDkgOTEzMSA3 NzYtNjAyMA0KDQpGcm9tOiBtZWRpYS10eXBlcyBbbWFpbHRvOm1lZGlhLXR5cGVzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpcyBMaWxsZXkNClNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDE2LCAyMDE3IDI6MjggUE0NClRvOiBtZWRpYS10eXBlc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFttZWRpYS10eXBlc10gUHJvcG9zYWwgZm9yIHJlZ2lzdHJhdGlvbiBvZiBtZWRpYSB0eXBl ICJhdWRpby91c2FjIg0KDQoNCg0KT24gMTYtQXVnLTE3IDExOjUxLCBOZXVlbmRvcmYsIE1heCB3 cm90ZToNCg0KMi4xMiAgICAgICAobm90IHJlcXVpcmVkKSBGcmFnbWVudCBJZGVudGlmaWVyIENv bnNpZGVyYXRpb25zDQoNCm5vbmUNCg0KSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCBNZWRpYSBG cmFnbWVudHMgd291bGQgYmUgYXBwbGljYWJsZSBoZXJlOyBmb3IgZXhhbXBsZSwgbGlua2luZyB0 byBhIHBhcnRpY3VsYXIgcG9pbnQgaW4gYW4gYXVkaW8gZmlsZSAocmF0aGVyIHRoYW4ganVzdCB0 aGUgYmVnaW5uaW5nKS4NCg0KaHR0cHM6Ly93d3cudzMub3JnL1RSL21lZGlhLWZyYWdzLw0KDQoN Cg0KLS0NCkNocmlzDQo= --_000_57c2101eb6014490b86025ebf38fac53mail03iisfhgde_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj azt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwMjA2MCI+RGVhciBDaHJpcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkkgZmluYWxseSBoYWQg c29tZSB0aW1lIHRvIGhhdmUgYSBsb29rIGF0IHRoaXMgYW5kIGRpc2N1c3MgdGhpcyBpbi1ob3Vz ZSB3aXRoIHNvbWUgbWVkaWEgdHJhbnNwb3J0IGV4cGVydHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5BZnRlciByZXZp ZXcgb2YgdGhlIGxpbmtlZCBXM0Mgc3BlYywgd2UgY29uY2x1ZGVkIHRoYXQgaXQgaXMgcHJvYmFi bHkgbm90IGFwcGxpY2FibGUgZm9yIGF1ZGlvL3VzYWMgbm9yIGF1ZGlvL2FhYy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwMjA2MCI+QXQgbGVhc3Qgd2UgaGFkIG5vIGlkZWEgaG93IHRvIHNlbnNp Ymx5IG9yIHByYWN0aWNhbGx5IG1ha2UgdXNlIG9mIHRoZSBkZXNjcmliZWQgbWVkaWEgZnJhZ21l bnQgc3ludGF4IGluIGNvbWJpbmF0aW9uIHdpdGggdGhlIGEgcGFja2V0ZWQgc3RyZWFtLCBzdWNo IGFzIExBVE0vTE9BUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkFkbWl0dGVkbHkgSSBoYWQgb3JpZ2luYWxseSBsZWZ0 IHRoaXMgcGFydCBvZiB0aGUgYXBwbGljYXRpb24gYmxhbmssIGJlY2F1c2UgaXQgc2FpZCDigJwo bm90IHJlcXVpcmVkKeKAnSBhbmQgYWxzbyBJIHdhcyBub3Qgc3VyZSB3aGF0IHRoaXMgd2FzIGFi b3V0LiAoQW5kIGFsc28NCiB0aGVyZSB3ZXJlIG5vIHNpbWlsYXIgZW50cmllcyBmb3IgYXVkaW8v bXBlZy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDAyMDYwIj5DYW4geW91IGdpdmUgc29tZSByZWZlcmVuY2UgZm9yIHRoZSBwcmFj dGljYWwgcmVsZXZhbmNlIG9mIHRoZXNlIG1lZGlhIGZyYWdtZW50cywgZS5nLiBleGFtcGxlcyBv ZiB3aGVyZSB0aGlzIGlzIGJlaW5nIHVzZWQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2 MCI+T3RoZXJ3aXNlLCBJIHdvdWxkIGJlIGluY2xpbmVkIHRvIGtlZXAgdGhpcyBmaWVsZCBvZiB0 aGUgYXBwbGljYXRpb24gZW1wdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5UaGFua3MgYW5kIEJlc3QsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDIwNjAiPk1heA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI0MCUiIGFs aWduPSJsZWZ0Ij4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+TWF4 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPk5l dWVuZG9yZjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw MjA2MCI+QXVkaW88L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw MjA2MCI+RnJhdW5ob2Zlci1JbnN0aXR1dCBmw7xyIEludGVncmllcnRlIFNjaGFsdHVuZ2VuIElJ Uzwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PGJyPg0KPC9zcGFuPjxz cGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkFtIFdvbGZz bWFudGVsIDMzIHwgRC05MTA1ODwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDIwNjAiPkVybGFuZ2VuPC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1h aWx0bzptYXgubmV1ZW5kb3JmQGlpcy5mcmF1bmhvZmVyLmRlIiB0aXRsZT0iQ2xpY2sgdG8gc2Vu ZCBlbWFpbCB0byBOZXVlbmRvcmYsIE1heCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpi bGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWF4Lm5ldWVuZG9yZkBpaXMuZnJhdW5ob2Zlci5k ZTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2 MCI+fA0KICYjNDM7NDkgOTEzMSA3NzYtNjAyMDwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiA8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiBtZWRpYS10eXBlcyBbbWFpbHRvOm1lZGlhLXR5cGVzLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzIExpbGxleTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAxNiwgMjAxNyAyOjI4IFBNPGJyPg0KPGI+VG86PC9i PiBtZWRpYS10eXBlc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21lZGlhLXR5 cGVzXSBQcm9wb3NhbCBmb3IgcmVnaXN0cmF0aW9uIG9mIG1lZGlhIHR5cGUgJnF1b3Q7YXVkaW8v dXNhYyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pk9uIDE2LUF1Zy0xNyAxMTo1MSwgTmV1ZW5kb3JmLCBNYXggd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4yLjEyJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChub3QgcmVxdWlyZWQpIEZyYWdtZW50IElkZW50 aWZpZXIgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5ub25lPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgTWVkaWEg RnJhZ21lbnRzIHdvdWxkIGJlIGFwcGxpY2FibGUgaGVyZTsgZm9yIGV4YW1wbGUsIGxpbmtpbmcg dG8gYSBwYXJ0aWN1bGFyIHBvaW50IGluIGFuIGF1ZGlvIGZpbGUgKHJhdGhlciB0aGFuIGp1c3Qg dGhlIGJlZ2lubmluZykuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48YSBocmVmPSJodHRwczovL3d3dy53My5vcmcvVFIvbWVkaWEtZnJhZ3MvIj5odHRwczov L3d3dy53My5vcmcvVFIvbWVkaWEtZnJhZ3MvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tLTxicj4NCkNocmlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_57c2101eb6014490b86025ebf38fac53mail03iisfhgde_-- From nobody Mon Sep 25 12:05:36 2017 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC75F134554 for ; Mon, 25 Sep 2017 12:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01] 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 SFNa5y90myQG for ; Mon, 25 Sep 2017 12:05:32 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 0E6BD1344D8 for ; Mon, 25 Sep 2017 12:05:31 -0700 (PDT) Received: from 31-39-184.wireless.csail.mit.edu ([128.31.39.184]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dwYh9-000FUg-5f; Mon, 25 Sep 2017 19:05:31 +0000 To: "Neuendorf, Max" , "media-types@ietf.org" References: <85263befc63f4747919a3efb035e766e@mail03.iis.fhg.de> <067d89103471467ea5ea71e478ea9043@mail03.iis.fhg.de> <6dfee3e5-2bcb-aaf7-eb24-03ba21c4568b@w3.org> <57c2101eb6014490b86025ebf38fac53@mail03.iis.fhg.de> From: Chris Lilley Message-ID: <5611e6b5-13de-e5cf-f56b-c4ab1c6d8bad@w3.org> Date: Mon, 25 Sep 2017 15:05:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <57c2101eb6014490b86025ebf38fac53@mail03.iis.fhg.de> Content-Type: multipart/alternative; boundary="------------F2C87273B99E61F650A30907" Content-Language: en-US Archived-At: Subject: Re: [media-types] Proposal for registration of media type "audio/usac" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:05:35 -0000 This is a multi-part message in MIME format. --------------F2C87273B99E61F650A30907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Max, Thanks for looking into this. On 25-Sep-17 09:01, Neuendorf, Max wrote: > > Dear Chris, > > I finally had some time to have a look at this and discuss this > in-house with some media transport experts. > > After review of the linked W3C spec, we concluded that it is probably > not applicable for audio/usac nor audio/aac. > > At least we had no idea how to sensibly or practically make use of the > described media fragment syntax in combination with the a packeted > stream, such as LATM/LOAS. > Because it is not practicable to seek on a stream? > > Admittedly I had originally left this part of the application blank, > because it said “(not required)” and also I was not sure what this was > about. (And also there were no similar entries for audio/mpeg.) > It is a relatively recent specification, and also a lot of media type registrations tend to not think about fragment identifiers until long after registration, if at all. > > Can you give some reference for the practical relevance of these media > fragments, e.g. examples of where this is being used? > > Otherwise, I would be inclined to keep this field of the application > empty. > An implementation report is available, with the implementations that were tested before Media Fragments became a W3C Recommendation: https://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/ There is also a use cases and requirements document: https://www.w3.org/TR/media-frags-reqs/ I'm happy that you examined fragment identifiers for this media type; if having done so you have concluded that they are not applicable here then I am satisfied. > Thanks and Best, > > Max > > ------------------------------------------------------------------------ > > *Max**Neuendorf* > Audio > Fraunhofer-Institut für Integrierte Schaltungen IIS > Am Wolfsmantel 33 | D-91058Erlangen > max.neuendorf@iis.fraunhofer.de > | +49 9131 776-6020 > > *From:*media-types [mailto:media-types-bounces@ietf.org] *On Behalf Of > *Chris Lilley > *Sent:* Wednesday, August 16, 2017 2:28 PM > *To:* media-types@ietf.org > *Subject:* Re: [media-types] Proposal for registration of media type > "audio/usac" > > On 16-Aug-17 11:51, Neuendorf, Max wrote: > > 2.12       (not required) Fragment Identifier Considerations > > none > > I would have thought that Media Fragments would be applicable here; > for example, linking to a particular point in an audio file (rather > than just the beginning). > > https://www.w3.org/TR/media-frags/ > > -- > Chris > -- Chris Lilley @svgeesus Technical Director @ W3C W3C Strategy Team, Core Web Design W3C Architecture & Technology Team, Core Web & Media --------------F2C87273B99E61F650A30907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Max,

Thanks for looking into this.

On 25-Sep-17 09:01, Neuendorf, Max wrote:

Dear Chris,

 

I finally had some time to have a look at this and discuss this in-house with some media transport experts.

 

After review of the linked W3C spec, we concluded that it is probably not applicable for audio/usac nor audio/aac.

At least we had no idea how to sensibly or practically make use of the described media fragment syntax in combination with the a packeted stream, such as LATM/LOAS.

Because it is not practicable to seek on a stream?

 

Admittedly I had originally left this part of the application blank, because it said “(not required)” and also I was not sure what this was about. (And also there were no similar entries for audio/mpeg.)

It is a relatively recent specification, and also a lot of media type registrations tend to not think about fragment identifiers until long after registration, if at all.

 

Can you give some reference for the practical relevance of these media fragments, e.g. examples of where this is being used?

Otherwise, I would be inclined to keep this field of the application empty.

An implementation report is available, with the implementations that were tested before Media Fragments became a W3C Recommendation:

https://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/

There is also a use cases and requirements document:
https://www.w3.org/TR/media-frags-reqs/

I'm happy that you examined fragment identifiers for this media type; if having done so you have concluded that they are not applicable here then I am satisfied.


 

Thanks and Best,

Max

 

Max Neuendorf
Audio
Fraunhofer-Institut für Integrierte Schaltungen IIS
Am Wolfsmantel 33 | D-91058 Erlangen
max.neuendorf@iis.fraunhofer.de | +49 9131 776-6020

From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of Chris Lilley
Sent: Wednesday, August 16, 2017 2:28 PM
To: media-types@ietf.org
Subject: Re: [media-types] Proposal for registration of media type "audio/usac"

 

 

On 16-Aug-17 11:51, Neuendorf, Max wrote:

2.12       (not required) Fragment Identifier Considerations
none

I would have thought that Media Fragments would be applicable here; for example, linking to a particular point in an audio file (rather than just the beginning).

https://www.w3.org/TR/media-frags/

 

--
Chris

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media
--------------F2C87273B99E61F650A30907--