Re: [MMUSIC] Mux Category and RFC4566bis

[Paul Kyzivat <[e-mail]>]

Upon looking further at mux-attributes, perhaps it is a more likely 
candidate to reference criteria for new parameter values. In particular, 
section 4 (SDP Attribute Analysis Framework) comes close to serving the 
purpose.

I have a concern about it as it stands: this section only talks about 
*attributes*. But mux categories apply to many SDP parameters other than 
attributes. I *think* this is perhaps just sloppy terminology, and it is 
intended to apply more generally to parameters that are affected by mux 
category.

I don't know if it is possible, given it is the the editor's queue, to 
update mux-attributes. Is it *good enough* to reference without change?

	Thanks,
	Paul

On 8/9/19 11:19 AM, Paul Kyzivat wrote:
> 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