Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

[Paul Kyzivat <[e-mail]>]

On 2/2/16 5:35 PM, Flemming Andreasen wrote:
>
>
> On 1/29/16 10:30 AM, Paul Kyzivat wrote:

>> We *could* rethink this, and reduce the information put in IANA for
>> attributes. It would be sufficient for the IANA registry to give the
>> attribute name, and a reference to the document where it is defined.
>> (As long as we are assured that the information is present in the
>> referenced document. It may be that this is not the case for some
>> older attributes.)
>>
>> But we should be consistent about this.
>>
> I'm not concerned about the IANA registration. What I am concerned about
> is that we are heading down the path of explicitly thinking about and
> specifying interactions between different attributes. Again, I'm not
> convinced that it is really necessary here and that you couldn't solve
> the issue for dcsa with a more algorithmich approach similar to what we
> did for capability negotiation.

Are you referring to:

    When the attribute capability contains a session-level attribute,
    that "acap" attribute can only be provided at the session level.
    Conversely, media-level attributes can be provided in attribute
    capabilities at either the media level or session level.  The base

I don't see the parallel. capneg is really a "macro" mechanism, so it is 
really up to the user to ensure that all possible expansions of a macro 
are valid.

But I see a direct analogy to the a=ssrc attribute. That one also is an 
attribute that recursively contains another attribute. But not all 
attributes "work" (or make sense) with a=ssrc. Only those whose effect 
can be narrowed to a particular RTP stream are valid. So it established 
a registry for those that do work with it.

The a=dcsa attribute is very similar to that. Again not every attribute 
works with it. Only those that can be applied to a particular data 
channel apply.

Rather than keeping separate registries for session level, media level, 
and "source" (a=ssrc) level, we have agreed to merge them and add a 
column to indicate which level(s) apply to each attribute. That makes it 
easier to add yet another (dcsa) "level".

> Can you (and/or the authors) elaborate on why such an approach would not
> work ?

It isn't strictly necessary to have this information in IANA. It would 
be sufficient to have it in the documents that define each attribute. 
(As long as they really do have it.)

And, if it was there and not in the registry, then each document could 
decide whether applicability can be specified via an algorithm, or if it 
must be done by enumeration.

But, if that is the case, then it should apply for all the distinct 
contexts where attributes might be used: session level, media level, 
source level, dcsa level, and capneg level. (Every distinct place that 
<attribute> can appear.)

And there is a downside to this. Each time a new "level" is defined 
(e.g., when a=dcsa is defined) then either it has to provide a rule for 
every attribute, current and future, or else the definition of every 
attribute, current and future, will need to specify applicability to 
this new level.

Consider a=ssrc. When some new attribute is defined, will it be usable 
with a=ssrc? Without the registry, how would anyone find out?

	Thanks,
	Paul