Re: [MMUSIC] Mux Category and RFC4566bis

[Christer Holmberg <[e-mail]>]

Hi Paul,

>    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 agree. When one defines a new attribute, one needs to read the semantics of the mux categories, and pick the one that fits the new attribute. I am not sure what else could be said regarding "how to choose a category".
  
>    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.
  
What other SDP parameters than attributes and b= do you think it applies to?

As far as calling b= an attribute is concerned, RFC 3556 actually DOES call it an attribute (see e.g., Section 2). Same thing for RFC 3890 (see e.g., section 1.1).

So, perhaps we could add some text to RFC4566bis saying that b= is often referred to as an attribute?

Regards,

Christer  




    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