[MMUSIC] Mux Category and RFC4566bis

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 09 August 2019 15:19 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 608B712008A for <mmusic@ietfa.amsl.com>; Fri, 9 Aug 2019 08:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1g7b-OrDcAc for <mmusic@ietfa.amsl.com>; Fri, 9 Aug 2019 08:19:37 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 601DE120052 for <mmusic@ietf.org>; Fri, 9 Aug 2019 08:19:37 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x79FJUx8001252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2019 11:19:30 -0400
To: Suhas Nandakumar <snandaku@cisco.com>, "Christer.Holmberg@ericsson.com" <Christer.Holmberg@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: IETF MMUSIC WG <mmusic@ietf.org>
Message-ID: <1d94d0e0-5ad0-b838-c1b2-43c68bd1cccb@alum.mit.edu>
Date: Fri, 09 Aug 2019 11:19:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/G4Sz45jxUfb8gGBAsZqv0YLk6-c>
Subject: [MMUSIC] Mux Category and RFC4566bis
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: Fri, 09 Aug 2019 15:19:40 -0000

Christer, Suhas, and others,

Based on IESG feedback I'm working on clarifying the IANA considerations 
for the various registry tables defined by 4566. In the process of that 
I'm having difficulty deciding what to do about Mux Category.

The document aims to spell out the requirements for registration of new 
parameter values. For the ones that require Mux Category (attributes & 
bwtype) I think it really needs to say *something*.

So far there is *nothing* for bwtype.

For attributes a new registry format is defined and includes the Mux 
Category column, and a reference to the mux-attributes draft, but no 
text saying anything about how the proper value is to be defined for 
future attributes.

Nor, as best I can tell, do the bundle or mux-attributes drafts say 
anything about how one should choose a mux category when defining new 
values in the future. This really needs to be specified.

I'm uncertain where this information ought to be. Does it belong in 
4566bis or in bundle? (I don't think it belongs in mux-attributes since 
that is only intended to "catch up" previously defined parameters.)

I think it will be hard to incorporate it into 4566bis because the 
context needed to talk about it isn't present there - it is dependent on 
bundle. It would perhaps work to just add references to bundle in all 
the places where this should come up, but I think that will require some 
new text in bundle.

	Thanks,
	Paul