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

[Flemming Andreasen <[e-mail]>]

On 2/3/16 2:13 PM, Paul Kyzivat wrote:
> 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.
I'm referring to CapNeg's "conceptual" construction of SDPs based on 
potential configurations - see e.g. Sections 3.1, 3.5.1 and 3.6.2 in RFC 
5939

>
> 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.
>
Right, but what are the constraints on a particular data channel that 
may or may not make them work with a data channel ? Why is this 
fundamentally different than specifying parameters for a media stream ?

> 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?
>
I'm not concerned about the IANA part. I agree that *if* we need to 
expliclty specify attribute interactions for "dcsa", then it should be 
part of the IANA registry. What I am not agreeing with at this point is 
that there is indeed a need to explicitly speficy these interactions as 
opposed to relying on a more general algorithmic approach (plus the 
offerer being responsible for generating a valid offer if he wants to 
establish a data channel).

Thanks

-- Flemming

>     Thanks,
>     Paul
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>