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

[Christian Groves <[e-mail]>]

Hello Paul,

I actually meant to post the reply to the list, sorry for the confusion.

I do understand your concerns. For multiplexing it makes sense to check 
all the existing attributes to see whether they're applicable due to the 
fact that quite alot may be used when multiplexing occurs. I think the 
data channel usage is quite a bit more narrow in scope.

Whilst this draft does introduce a general purpose mechanism the actual 
use of the dcsa is being defined by other drafts. E.g.
draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what happens 
when both a=setup and a=dcsa:setup are present. msrp-cema is another one 
discussed, etc.

I think you need to understand the application protocol being carried in 
a data channel before you can say whether particular attributes should 
be carried in dcsa and what that actually means. Going through the IANA 
registry wouldn't be trivial and unless the attributes are put in 
context of an application protocol I don't think it will be terribly 
helpful.

draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate that 
the dsca parameters follow the procedures defined in the subprotocol 
specific documents. Maybe we could strengthen this to indicate that the 
use of dsca by an application protocol should be documented in a 
specification?


Regards, Christian

On 1/12/2015 11:30 AM, Paul Kyzivat wrote:
> Christian,
>
> On 11/30/15 6:45 PM, Christian Groves wrote:
>> Is this level of detail really needed? There are several drafts for
>> CLUE, MSRP and BFCP related to the use of this sdpneg mechanism. E.g.
>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of dcsa.
>>
>> Can't we just follow the principle that the use of the dcsa attribute
>> should be detailed in a specification and leave it at that? I'm not sure
>> what we gain by analysing every existing attribute and forcing every new
>> attribute to do this analyses when the set of possible parameters in
>> likely to be very small.
>
> I guess it is arguable both ways. Originally there was only session 
> level and media level. That was always supposed to be identified, but 
> it wasn't always followed.
>
> Then we got source level. That has complicated the registry and the 
> usage. I am not convinced that two SDP experts would come up with the 
> same list of which attributes can be used at source level.
>
> The dcsa attribute becomes the 4th "level" for attributes. It at least 
> makes sense to me that it ought to be managed analogously to the 
> source attribute. But I agree it doesn't provide the same degree of 
> confusion as the others. It only makes sense if the usage the 
> attribute applies to works over a data channel. And that should be 
> known to whatever is processing the SDP.
>
> I see this was a private message. Why don't you repost it on the list 
> and lets see what other people think? (Feel free to repost this reply 
> if you wish.)
>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>
>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote:
>>> One thing occurred to me that we may have forgotten about:
>>>
>>> This draft introduces the dcsa attribute, which allows other
>>> attributes to be used in this new scope. It notes that not all
>>> attributes are suitable for use this way.
>>>
>>> ISTM that in the future other attribute definitions should include an
>>> indication of whether they can be used with dcsa, and the IANA
>>> registration of the attribute ought to include this. And then there is
>>> a need to update the iana registry for all the existing attributes.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> On 11/25/15 4:52 AM, Bo Burman wrote:
>>>> This is to announce a 4 week Working Group Last Call for
>>>>
>>>>                  draft-ietf-mmusic-data-channel-sdpneg-06
>>>>
>>>> as proposed standard.
>>>>
>>>> Please review and provide any comments you may have on the document by
>>>> Wednesday, December 23, 2015. Comments should be sent to the document
>>>> authors and the MMUSIC WG list. If you review the document but do not
>>>> have any comments, please send a note to that effect as well.
>>>>
>>>> Please also forward this WGLC call to any other interested parties who
>>>> may be able to review the draft, asking them to also direct their
>>>> comments to the authors and the list as above.
>>>>
>>>> Thank you!
>>>>
>>>>          Bo Burman (MMUSIC co-chair)
>>>>
>>>> Draft information:
>>>>
>>>> This draft is a work item of the Multiparty Multimedia Session Control
>>>> Working Group of the IETF.
>>>>
>>>>          Title           : SDP-based Data Channel Negotiation
>>>>
>>>> Authors         : Keith Drage
>>>>
>>>>                            Maridi R. Makaraju (Raju)
>>>>
>>>>                            Juergen Stoetzer-Bradler
>>>>
>>>> Richard Ejzak
>>>>
>>>>                            Jerome Marcon
>>>>
>>>>                  Filename        :
>>>> draft-ietf-mmusic-data-channel-sdpneg-06.txt
>>>>
>>>>                  Pages           : 37
>>>>
>>>>                  Date            : 2015-10-19
>>>>
>>>> Abstract:
>>>>
>>>>     The Real-Time Communication in WEB-browsers (RTCWeb) working
>>>> group is
>>>>
>>>>     charged to provide protocols to support direct interactive rich
>>>>
>>>>     communications using audio, video, and data between two peers' 
>>>> web-
>>>>
>>>>     browsers.  For the support of data communication, the RTCWeb 
>>>> working
>>>>
>>>>     group has in particular defined the concept of bi-directional data
>>>>
>>>>     channels over SCTP, where each data channel might be used to
>>>>
>>>>     transport other protocols, called sub-protocols.  Data channel 
>>>> setup
>>>>
>>>>     can be done using either the in-band Data Channel Establishment
>>>>
>>>>     Protocol (DCEP) or using some out-of-band non-DCEP protocol.  This
>>>>
>>>>     document specifies how the SDP offer/answer exchange can be 
>>>> used to
>>>>
>>>>     achieve such an out-of-band non-DCEP negotiation.  Even though 
>>>> data
>>>>
>>>>     channels are designed for RTCWeb use initially they may be used by
>>>>
>>>>     other protocols like, but not limited to, the CLUE protocol.  This
>>>>
>>>>     document is intended to be used wherever data channels are used.
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ 
>>>>
>>>>
>>>> There's also a htmlized version available at:
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-06
>>>>
>>>> A diff from the previous version is available at:
>>>>
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-06 
>>>>
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>
>