Re: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail) - order and transparency

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 19 January 2021 18:39 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C932A3A16AB for <mmusic@ietfa.amsl.com>; Tue, 19 Jan 2021 10:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fDAjRm7_zf8N for <mmusic@ietfa.amsl.com>; Tue, 19 Jan 2021 10:39:35 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2049.outbound.protection.outlook.com [40.107.22.49]) (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 A25B23A16B0 for <mmusic@ietf.org>; Tue, 19 Jan 2021 10:39:35 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BLaMYOxTW6m4rrwl8IJbaTInBNHXfx4ZfEMwPupjUb6KJn8+aaFJ71t6o/4i7vspHxdKXP7qmm5xuRJJ4l2RCpSu2ljQ+0I31FprA8X4f+k58r7ITr+66tCVD9jLF2CN8b36ove6ISB//QrEs7kysbRqqzHn18Lzu43elY4fbSiEyJh+/p5tprR9X9awXB2+qTZAB6aTpve6oauN1mvzhwa7SOygHfDkSc3BWXDKeBZE62y3F0BjeN18pYGBC2DTfG7tuK/gDe3uLRqT419GwVPgT9S95RmYz/56coAJymBg361KdR8tx2BWASuxN2/j8/ib3YhWF2bHxpMCxK2UGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wrr0fFoh/Z4gbMSN12TG41I3O06+0J6eVco/1L37Yu4=; b=iMjDdZGZjU0ng4XmJTIpt9Zu4A8M5KkB+C3KKuddR83nw+LovtxwaapYdtAvOMyGgo0c3O28FHiNtBisEvCNtn/1WVfztyj2tJCUFayhs4zn+eqBwYrAuYTlkuE/p2egyx2l8ishouoDL3vUsAuZ5AVDtqRqWx1D4KzzeOWLX9A4oOdYEd9hcVfauiS7lP4QaV0QA8GpFeITdJXKFvZuOcxocQx9Bcxq/KSmMOv1cL4OrueepF+4lCD94hXdWei1e0PJrqFTPecPkXNXMRat5rKswmE7C1VbLEKFlAguKOHAXnKQajUivOHmiVxTt8NmNFjVo6TMgTcACJ4AgDXdzw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wrr0fFoh/Z4gbMSN12TG41I3O06+0J6eVco/1L37Yu4=; b=QA9gDbPqA4D5k66lo73jVYXuosLEE+++1QosyYC+rhpZqX9PS8QzLFewJxVVLhB7NvjzfKLLxsdiGrXJLddp0klwiU4+jBzSSttMYjDlnVavI6WHy/VoOb3+PFMh1DZbMvpm36QKX8ts8wXBug8k6CtNjqLS5I54TiPgoTgnWU0=
Received: from (2603:10a6:208:4c::18) by AM0PR07MB4020.eurprd07.prod.outlook.com (2603:10a6:208:50::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.5; Tue, 19 Jan 2021 18:39:29 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::e0b4:28dd:684:daf6]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::e0b4:28dd:684:daf6%7]) with mapi id 15.20.3784.011; Tue, 19 Jan 2021 18:39:28 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rabhishek(RohitAbhishek)" <rabhishek@tencent.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail) - order and transparency
Thread-Index: AdbuklzAS4pRjUpxSam9dBa2EC3I1A==
Date: Tue, 19 Jan 2021 18:39:28 +0000
Message-ID: <AM0PR07MB3860EAC9D4AC5343B36E576493A30@AM0PR07MB3860.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tencent.com; dkim=none (message not signed) header.d=none;tencent.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bc80923b-e32f-478e-2821-08d8bca98dee
x-ms-traffictypediagnostic: AM0PR07MB4020:
x-microsoft-antispam-prvs: <AM0PR07MB402027F52C88D4CB58E455E693A30@AM0PR07MB4020.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EOjcBRYqVxQielAKRw1IKrB+AFsQ+jHeVRCphkihQYSATRuEQGcKtaj0raZdahi+twy+o190NOAg9F4OgjQ5+MgkiOJg9+sxB6mY0oICS/MK0NhSXN4cpzXWbXa2H/drsQVu5i9GhG9gNzDatRQuFia3NMTtebcOX3/n7bU6FJ3lz3wnQ/fYbANBfCJP/MJoueuWAepSlk9k5jFjfMnmFVmKZrh+1/SlNBCQMDqq3euK7pzZ1+klksZr5KEFY/UkuXbXgYIsnEUxFkwocWu9qIQXMz+1D5qU+lyCqX5Zp12fUedhCydJFgMEzg+W0RzxaM687pJYkRLXwNy21r7zKUu6gkuSQNdXvAM7WOTaXRBrusg+BVj4xk6IF/qvDJdMNP/VN5yEO+lFogf3kox/chtijUm+jdO4fhOSJWC1H6u9TT2cLHvPPbCnsgytDEWbrXIYKReEFbqaHM1NtKaiew==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(39860400002)(136003)(376002)(5660300002)(6506007)(83380400001)(53546011)(52536014)(66556008)(33656002)(66446008)(76116006)(15650500001)(64756008)(66946007)(66476007)(2906002)(7696005)(71200400001)(66574015)(26005)(316002)(8936002)(186003)(478600001)(8676002)(30864003)(966005)(86362001)(110136005)(4001150100001)(9686003)(55016002)(44832011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Q9ditXAwj+VZSxB5yBQbpewmNzWQGL60uOQPShi7MuB8fAnS4vL407sC4qR1d7VM3vV5gjQmDUqLYza6tQGYyw6n9PP8E/TTyHsh4LzxrWfc4E9uUkBUQp+zabi9jhNuFP1EV0/yI/dUpGuArvMmjLHfOGbKtdKl7JBFwMrluLu+bNOYsvM5d2pq7jImLL1+VLK7VgzsAgwwemoFBSKLNAnJiF+TIQ7aXrJ1838T5nZIOv8H8knWUO/R5aPNSIlqr2keOiq8RC0nF9PDITVVeMxcBZ3/elz0N0dG77yFnk7XRdAB47sztJPpb/UCpCLLAFxgF7JXjIngiJ3VhS5z8LG8h48OcxYIciPWTI/qs5G3/N0oqS1YR9xtaNOO/3/nv89/kTUdluE9ShFo16m2esFycFXhKKHMjikChp6iJV72OB6o/MmcJwLuEIKTpTNXKKidu3GkmXeK1xioT7n5cATciHA358SA/cixaqCqJz+o/rVwOmkexg07Nb7ZbhVKh3bZXlp7MOy91nAdB6F0w7y6kCrNfkEyxYwexsZVI3fkvcDTQY4kQ4yL54tOp73Fw/BSW94kwCpspa+wlOvpa3C8kLXhTLVqdvexf+45qRz5iykQn4KfQTTfJA9YOHX512cc3ntK8NmcqCDDTvAx5DixKq/8rcbG5YmcNKVbzlwuNjfL4WJZwlLW4feLZ7TXe92xRp2YjVY4s6PCqHlaMbIZAAeiycJMcVIh/V1QsqxhjnUsKrFKW5JtTyALlDa97wAYMq51mDR2prtO3wn+uaLtyxgd8oLb9q6iuvwA9OGVurE1h0V/xuIxub2OTny7BuOnrB/20wNe/cqAqkJVqOr76S19JtbeaOu8EnMLxqMS0VtiWhQ7qH7W9+QpJ7lnOfRPxUw+vQCd+EvO62DFL8lXtQcy2ooPaQRV5aET4NAIZf8Rv7JJf2ympKC4+EmphNFI0hJlddQQAdEiBENV0ZNxzlrXR9sBw9sLm5E9Jok=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bc80923b-e32f-478e-2821-08d8bca98dee
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2021 18:39:28.8615 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /7WyW3hoT7POQie0pzHiWo+m2G0daR3uW33GQMqp3m7wVQfZdC+efCihYu+iF4h99boNohe2n8IJV40n8ySgycuEpCh+4HODY6ZNVR4wi/o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4020
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/r3OYWuZk8l6BJBmjQ5weyPYI3wU>
Subject: Re: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail) - order and transparency
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2021 18:39:39 -0000

Hi,

...

>>    Finally, ISTM that you don't need to treat the background document as a 
>>    special case. The grouping mechanism can be used to identify all the 
>>    media streams participating in this superposition mechanism, including 
>>    the one you are considering to be the background.
>>
>>    IIUC the scheme you describe defines the result of superposition based 
>>    on the transparency values of the individual streams, so that no other 
>>    ordering mechanism is needed. (Do I have that right?) If so, isn't the 
>>    background just the media stream with tranparency = 100?
>
> Rohit: The ordering mechanism will be needed. Suppose we have a background X with transparency=100, and a superimposed media A with transparency=50. 
> A over X would mean that X would visible partially through A, however X over A would mean that A wouldn't show through X.

That is my understanding too, after I started to look a little bit more into this: for each stream within the group, we need the order value AND the transparency value.

Regards,

Christer




    > Best Regards,
    > Rohit
    > 
    > On 1/14/21, 9:25 AM, "mmusic on behalf of Paul Kyzivat" <mailto:mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:
    > 
    >      On 1/14/21 4:54 AM, Christer Holmberg wrote:
    >      > Hi,
    >      >
    >      >> One more thing, regarding transparency:
    >      >>
    >      >> I'm fuzzy on how this is intended to work. I would think that each superposition layer would have some parts that are fully transparent.
    >      >> (Transparent pixels.) And then the transparency attribute would apply to the parts that aren't fully transparent. But that is only a guess. I think you need to say more about how the superposition is supposed to work.
    >      >
    >      > Isn't "transparent background" information carried within the video stream (codec or container) itself?
    > 
    >      That is my impression, but I don't really know. But the transparency
    >      attribute must do *something*.
    > 
    >      The draft needs to explain better.
    > 
    >        Thanks,
    >        Paul
    > 
    >      > Regards,
    >      >
    >      > Christer
    >      >
    >      >
    >      >
    >      > On 12/14/20 11:21 AM, Paul Kyzivat wrote:
    >      >> Rohit,
    >      >>
    >      >> Here are a few more points I forgot:
    >      >>
    >      >> 1) syntax
    >      >>
    >      >> In section 3 you repeat the syntax for the 'mid' attribute from RFC5888.
    >      >> I guess you don't intend it to be normative, but it gave me that
    >      >> impression.
    >      >>
    >      >> I don't think you need to repeat the syntax here. It should be
    >      >> sufficient to mention that you follow RFC5888 in use of the 'mid'
    >      >> attribute to identify the media sections that are to be included in
    >      >> the superposition.
    >      >>
    >      >> Similarly in section 5, I suggest that you only provide ABNF for the
    >      >> additions to syntax required for your extension. Specifically:
    >      >>
    >      >>     semantics =/ "superposition" <semantics as defined in RFC5888>
    >      >>
    >      >> (Everything else is inherited from RFC5888.)
    >      >>
    >      >> 2) applicability
    >      >>
    >      >> Regarding the following in section 3:
    >      >>
    >      >>      ... An application that receives a session
    >      >>      description that contains "m" lines grouped together using "S"
    >      >>      semantics MUST superimpose the corresponding media streams on top
    >      >> of
    >      >>      the background media stream.
    >      >>
    >      >> You need to recognize that because this feature is an extension its
    >      >> requirements can only apply to those that implement the extension. Its
    >      >> best to call that out specifically.
    >      >>
    >      >> Also, please give some thought to what will happen a device supporting
    >      >> this negotiates a session with a device that doesn't. The
    >      >> non-supporting device will treat these as independent media streams.
    >      >> If that is a problem for you then we need to discuss strategies for
    >      >> avoiding that situation.
    >      >>
    >      >> 3) differing size/resolution
    >      >>
    >      >> How the overlaying will work seems well defined if the image width and
    >      >> height in pixels and pixel shape is the same for all the media streams
    >      >> in the superposition group. But what if they aren't?
    >      >>
    >      >> I think the document should specify what should happen in such cases.
    >      >>
    >      >>       Thanks,
    >      >>       Paul
    >      >>
    >      >> On 12/13/20 3:54 PM, Paul Kyzivat wrote:
    >      >>> On 12/12/20 2:06 PM, Christer Holmberg wrote:
    >      >>>> Hi,
    >      >>>>
    >      >>>> A few comments (some of which I gave already previously):
    >      >>>
    >      >>> Christer covered most of what I wanted to say. I'll just add a few
    >      >>> tweaks below.
    >      >>>
    >      >>>> Q1:
    >      >>>>
    >      >>>> In Section 1, where you talk about the limitations of the mechanism,
    >      >>>> you should mention that CLUE must be used something more "fancy" is
    >      >>>> needed.
    >      >>>>
    >      >>>> ---
    >      >>>>
    >      >>>> Q2:
    >      >>>>
    >      >>>> In Section 3, you require a specific order of the m- lines in the
    >      >>>> SDP. I think SDP explicitly says that the order of m- lines is not
    >      >>>> relevant. Also, I know that parsers may change the orders of the m-
    >      >>>> lines.
    >      >>>>
    >      >>>> (I also think that any counting should start from 1, not 0)
    >      >>>>
    >      >>>> My suggestion would be to have an explicit "order" attribute instead.
    >      >>>
    >      >>> I think it would be acceptable to use the order of the tokens in the
    >      >>> a:group line to define the ordering of the "layers". The "lowest"
    >      >>> layer would then be the background on which the others are overlain.
    >      >>> (Whether the lowest layer is the first or last in the list is TBD.)
    >      >>>
    >      >>>> ---
    >      >>>>
    >      >>>> Q3:
    >      >>>>
    >      >>>> The example in Section 6 talks about "a background video". But, this
    >      >>>> background video is not described in the SDP.
    >      >>>>
    >      >>>> Related to that, if the SDP describes multiple "background videos",
    >      >>>> you need to describe how you map superimposed videos to a specific
    >      >>>> background video.
    >      >>>>
    >      >>>> Based on the text in Section 3 (see Q2), I am not sure whether the
    >      >>>> 0th m- line is supposed to be the background video, but the text in
    >      >>>> Section 6 says that both m- lines are for superimposed video streams.
    >      >>>
    >      >>> See my comment above.
    >      >>>
    >      >>> The background layer would presumably have a transparency of zero.
    >      >>>
    >      >>> (It would also be good to specify that if the transparency attribute
    >      >>> is omitted it defaults to zero.)
    >      >>>
    >      >>>> ---
    >      >>>>
    >      >>>> Q4:
    >      >>>>
    >      >>>> What happens to the superimposed videos if I disable/remove/mute the
    >      >>>> background video?
    >      >>>>
    >      >>>> ---
    >      >>>>
    >      >>>> Q5:
    >      >>>>
    >      >>>> This is editorial, but please call the group attribute something
    >      >>>> else than just "S". "supim", "spim" or something :)
    >      >>>
    >      >>> Yes please. "S" is way to cryptic.
    >      >>>
    >      >>>       Thanks,
    >      >>>       Paul
    >      >>>
    >      >>>> Regards,
    >      >>>>
    >      >>>> Christer
    >      >>>>
    >      >>>>
    >      >>>>
    >      >>>> -----Original Message-----
    >      >>>> From: mmusic <mailto:mmusic-bounces@ietf.org> On Behalf Of Rohit Abhishek
    >      >>>> Sent: lauantai 12. joulukuuta 2020 0.28
    >      >>>> To: mailto:mmusic@ietf.org
    >      >>>> Subject: [MMUSIC] FW: New Version Notification for
    >      >>>> draft-abhishek-mmusic-superimposition-grouping-00.txt
    >      >>>>
    >      >>>> Dear All,
    >      >>>>
    >      >>>> A new version of the draft “SDP Superimposition Grouping framework”
    >      >>>> has been uploaded.
    >      >>>> We have changed the name from  “SDP Overlay Grouping framework for
    >      >>>> immersive telepresence media streams” to  “SDP Superimposition
    >      >>>> Grouping framework” as the previous name wasn’t an accurate
    >      >>>> description of the content. Therefore, we had to start from version 00.
    >      >>>>
    >      >>>> Thank you all for the comments/suggestions on the previous draft.
    >      >>>> We have tried to address them in this version. Specifically, a
    >      >>>> transparency attribute and an informative Section on relationship
    >      >>>> with CLUE has been added.
    >      >>>>
    >      >>>> Comments/Questions/Feedbacks are welcome.
    >      >>>>
    >      >>>> Best Regards,
    >      >>>> Rohit
    >      >>>>
    >      >>>> On 12/11/20, 12:41 PM, "mailto:internet-drafts@ietf.org"
    >      >>>> <mailto:internet-drafts@ietf.org> wrote:
    >      >>>>
    >      >>>>
    >      >>>>       A new version of I-D,
    >      >>>> draft-abhishek-mmusic-superimposition-grouping-00.txt
    >      >>>>       has been successfully submitted by Rohit Abhishek and posted to
    >      >>>> the
    >      >>>>       IETF repository.
    >      >>>>
    >      >>>>       Name:        draft-abhishek-mmusic-superimposition-grouping
    >      >>>>       Revision:    00
    >      >>>>       Title:        SDP Superimposition Grouping framework
    >      >>>>       Document date:    2020-12-11
    >      >>>>       Group:        Individual Submission
    >      >>>>       Pages:        8
    >      >>>>       URL:
    >      >>>> https://www.ietf.org/archive/id/draft-abhishek-mmusic-superimpositio
    >      >>>> n-grouping-00.txt
    >      >>>>
    >      >>>>       Status:
    >      >>>> https://datatracker.ietf.org/doc/draft-abhishek-mmusic-superimpositi
    >      >>>> on-grouping/
    >      >>>>
    >      >>>>       Htmlized:
    >      >>>> https://datatracker.ietf.org/doc/html/draft-abhishek-mmusic-superimp
    >      >>>> osition-grouping
    >      >>>>
    >      >>>>       Htmlized:
    >      >>>> https://tools.ietf.org/html/draft-abhishek-mmusic-superimposition-gr
    >      >>>> ouping-00
    >      >>>>
    >      >>>>
    >      >>>>
    >      >>>>       Abstract:
    >      >>>>          This document defines semantics that allow for signaling a
    >      >>>> new SDP
    >      >>>>          group "S" for superimposed media in an SDP session.  The "S"
    >      >>>>          attribute can be used by the application to relate all the
    >      >>>>          superimposed media streams enabling them to be added as an
    >      >>>> overlay on
    >      >>>>          top of any media stream.  The superimposition grouping
    >      >>>> semantics is
    >      >>>>          required, if the media data is separate and transported via
    >      >>>> different
    >      >>>>          sessions.
    >      >>>>
    >      >>>>
    >      >>>>
    >      >>>>
    >      >>>>       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.
    >      >>>>
    >      >>>>       The IETF Secretariat
    >      >>>>
    >      >>>>
    >      >>>> _______________________________________________
    >      >>>> mmusic mailing list
    >      >>>> mailto:mmusic@ietf.org
    >      >>>> https://www.ietf.org/mailman/listinfo/mmusic
    >      >>>> _______________________________________________
    >      >>>> mmusic mailing list
    >      >>>> mailto:mmusic@ietf.org
    >      >>>> https://www.ietf.org/mailman/listinfo/mmusic
    >      >>>>
    >      >>>
    >      >>> _______________________________________________
    >      >>> mmusic mailing list
    >      >>> mailto:mmusic@ietf.org
    >      >>> https://www.ietf.org/mailman/listinfo/mmusic
    >      >>
    >      >> _______________________________________________
    >      >> mmusic mailing list
    >      >> mailto:mmusic@ietf.org
    >      >> https://www.ietf.org/mailman/listinfo/mmusic
    >      >
    >      > _______________________________________________
    >      > mmusic mailing list
    >      > mailto:mmusic@ietf.org
    >      > https://www.ietf.org/mailman/listinfo/mmusic
    >      > _______________________________________________
    >      > mmusic mailing list
    >      > mailto:mmusic@ietf.org
    >      > https://www.ietf.org/mailman/listinfo/mmusic
    >      >
    > 
    >      _______________________________________________
    >      mmusic mailing list
    >      mailto:mmusic@ietf.org
    >      https://www.ietf.org/mailman/listinfo/mmusic
    > 
    > _______________________________________________
    > mmusic mailing list
    > mailto:mmusic@ietf.org
    > https://www.ietf.org/mailman/listinfo/mmusic
    >