Re: [MMUSIC] Mux Category and RFC4566bis

Hi,

>After further consideration I concluded that maybe the problem isn't as bad as I was thinking, at least for 4566bis. >bwtype and attribute are the only parameters that 4566bis is concerned with that have a mux category. And for >bwtype it isn't too confusing because nothing is really being changed. I'm just going to punt on saying anything >about how one would choose the mux category for a new bwtype.
>
>I just submitted -37 of 4566bis. Please take a look and see if it works for you.

I think it would have been useful to have a few words about b= is sometimes referred to as an attribute, and point out that the mux category needs to be defined to new bandwidth types.

Otherwise it looks ok. 

Regards,

Christer

On 8/9/19 4:06 PM, Christer Holmberg wrote:
> 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 :)

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic