Re: [MMUSIC] Mux Category and RFC4566bis

[Christer Holmberg <[e-mail]>]

Hi,

    >>>     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".
    >
    > Me either. But if an expert were charged with approving a new attribute, 
    > what criteria would he use for deciding if the mux category was "right"? 
    > Is the answer just "IESG review"?
    
    New attributes should also be reviewed by the SDP directorate, right? I guess we just have to assume there are people who are able to make the correct judgement. 

    Normally I think it shouldn't be that difficult to pick the mux category.

    As a last resort, I guess one can assign a TBD category. However, I think there should be a good technical reason for that. One should not assign a TBD category just because one is lazy and doesn't want to bother with the mux stuff...

---
        
    >>>     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?
    >
    > mux-attributes updates a whole bunch of parameter registries. Other than 
    > the actual attribute registries, none of them *are* attributes. Many of 
    > them are carried in a field in a value of some attribute, but that is 
    > different from them *being* an attribute.
    
Ok, I hear you.

But, as you say, they are still associated with attributes.

    >> 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?
    >
    > It may be that the most practical fix is to put some explanation 
    > somewhere in 4566, even though that is probably not the most ideal way. 
    > I'm groping for how to do that.
    
    I would suggest something like this to work on:

    "Note that the bandwidth-field is often referred to as an attribute in other specifications. In addition, reference-to-mux-categories defines mux categories for the different bandwidth types.
     As for attributes, and attribute values, when a new bandwith type is defined the mux category for the type MUST be specified."
    
    > I'm wondering whether it might actually make sense to create another 
    > document that factors the Mux Category *framework* out from the specific 
    > analysis for preexisting values. It would have more in the way of 
    > guidance on how to choose. And maybe it could also consider what needs 
    > to be done in the future when another SDP parameter is defined that has 
    > interactions with bundle. (Can we do an update to a document that hasn't 
    > yet made it to RFC?)

    My suggestion would be to add text to 4566bis based on this discussion, publish draft-mux-categories in its current form, and then wait and see whether there in future will be a need for an additional document. It can be called "MUX Clarifications" - similar to the tons of offer/answer clarification documents we have produced :)

Regards,

Christer