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

[Flemming Andreasen <[e-mail]>]

On 2/8/16 12:09 PM, Paul Kyzivat wrote:
> On 2/8/16 11:09 AM, Flemming Andreasen wrote:
>>
>>
>> On 2/6/16 1:44 PM, Paul Kyzivat wrote:
>>> On 2/4/16 10:43 PM, Christian Groves wrote:
>>>> Isn't this the approach we're taking today?
>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific
>>>> drafts are used to describe protocols that use the mechanism (i.e.
>>>> draft-ietf-mmusic-msrp-usage-data-channel &
>>>> draft-ietf-clue-datachannel).
>>>
>>> It remains to be seen if that will be enough. E.g., there currently
>>> aren't any iana considerations in
>>> draft-ietf-mmusic-msrp-usage-data-channel.
>>>
>>> Suppose I encounter some sdp that uses msrp over a data channel, but
>>> that usage is unknown to me. How do I find the spec (the reference to
>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage?
>>>
>>> I would like to think that the iana registries will allow me to trace
>>> back to the relevant specs.
>>>
>> No disagreement on that part, however having taken another look at both
>> sdpneg and the msrp-usage documents, I still don't agree with your
>> original request for all (existing and new) attributes to specify how
>> they may or may not be used with the dcsa attribute defined by sdpneg.
>>
>> As Christian noted, the sub-protocol specifics are defined in individual
>> documents (like msrp-usage), which calls your the parameters that are at
>> least needed to be supported for that usage. Taking MSRP as an example,
>> why isn't that enough, and how do you see the resulting set of
>> attributes that may or may not be used with MSRP differ between use in a
>> data-channel (and hence encapsulated in dcsa) or as a regular media
>> stream ?
>
> Based on this discussion, I conclude that it should be sufficient for 
> this draft to say that before an attribute can be used with dcsa, such 
> usage must be defined somewhere. This could be either:
> - as part of the definition of the attribute, OR
> - as part of the definition of the protocol referenced on the m-line.
>
We are getting closer, but it's still not obvious to me that you cannot 
use an attribute with dcsa if it has not been explicitly defined for the 
attribute in question. Clearly, there are attributes that wouldn't make 
sense over data channels, just like there are attributes that don't make 
sense over particular media descriptions.

Again, I'd like to hear from more people on this, including the authors.

Thanks

-- Flemming



>     Thanks,
>     Paul
>
>> Also, it would be good to hear from more people on this, including the
>> document authors.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Regards, Christian
>>>>
>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote:
>>>>>
>>>>>> 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).
>>>>>
>>>>> Well, an obvious one is that the protocol(s) the attribute 
>>>>> pertains to
>>>>> need to be defined to work over data channels.
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>