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

Christian Groves <> Fri, 11 December 2015 00:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D59AD1B3057 for <>; Thu, 10 Dec 2015 16:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DeDiM-KzRZ2R for <>; Thu, 10 Dec 2015 16:20:46 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82D3D1AD0A7 for <>; Thu, 10 Dec 2015 16:20:45 -0800 (PST)
Received: from ([]:51926 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <>) id 1a7BRw-00310b-1U for; Fri, 11 Dec 2015 11:20:40 +1100
References: <> <> <> <> <> <> <> <> <> <>
From: Christian Groves <>
Message-ID: <>
Date: Fri, 11 Dec 2015 11:20:34 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Dec 2015 00:20:50 -0000

Hello Paul,

On 10/12/2015 3:47 PM, Paul Kyzivat wrote:
> On 12/9/15 11:04 PM, Christian Groves wrote:
>> Hello Juergen and Paul,
>> The proposed text by Juergen is OK.
>> Paul: Is an IANA registry the right place to capture the nuances of what
>> you're describing below? I agree that when people are defining new
>> attributes that they should consider their use with data channels, but
>> shouldn't that be documented in an RFC rather than the IANA registry?
>> People need to read the RFC rather than simply relying on the registry.
> It shouldn't *only* be in the IANA registry. The registry serves as an 
> index getting you to the right place, and helping you figure out what 
> you need to read.
[CNG] This is what I was getting at. It not just a registry update we're 
talking about there's a much more significant document explaining the 
use of the attributes with dcsa.
> Won't it be confusing if the registry covers usage of attributes a 
> session, media, and source level but doesn't cover their use in dcsa?
[CNG] The registry is a short cut. Even if the registry mentions that 
its a source attribute, a person still needs to read the RFC to see how 
it works. I see that people want to use an attribute for its 
functionality not because of what the IANA reg says.
> If this isn't needed for dcsa, then by the same logic we ought to 
> strip out that other information, and reduce the table to contain only 
> references to documents.
>> Also isn't the consequence of what you're suggesting is that another
>> draft similar to draft-ietf-mmusic-sdp-mux-attributes would have to be
>> completed in order to populate the IANA registry field that you're
>> proposing?
> Perhaps. We'd have to discuss the best way. It may be that most of the 
> existing attributes can be covered with a couple of default rules, and 
> maybe a few exceptions.
[CNG] Still the analysis of each attribute would need to be done and 
documented to get to the few rules. I not completely against doing this, 
I'm just keen to get this work finished and this will just delay things.

Regards, Christian

>     Thanks,
>     Paul
>> Regards, Christian
>> On 10/12/2015 2:43 AM, Paul Kyzivat wrote:
>>> Juergen and others,
>>> What you have below is a good start.
>>> I still think we need to at least specify how dcsa impacts IANA
>>> registration of attributes.
>>> The attribute registration is (going to be) updated so that there is
>>> one table containing all attributes, with fields indicating for each
>>> attribute whether it can be used at session level, media level, or
>>> source level.
>>> Now consider an attribute usable at media and/or source level:
>>> It *might* *also* be usable with dcsa, or it might not. That will at
>>> least in part be determined by whether the protocol that it applies to
>>> can run over a data channel.
>>> There was a suggestion (Keith?) that media level attributes be
>>> implicitly allowed with dcsa if the protocol they apply to is defined
>>> over a data channel. I find that plausible. But then the instructions
>>> for registration ought to say that. Also, if there can be exceptions
>>> (attributes that *can't* be used with dcsa even when the protocol is
>>> defined over data channel) then there should be a way to register that.
>>> Source level attributes add another complication. They only apply over
>>> RTP. For now, RTP isn't defined over a data channel. (Though in
>>> principle it *could* be.) If it were, then I suppose the ussage would
>>> have to be 'a=dcsa nn source ...'. I don't think we need to deal with
>>> that right now.
>>> And then there is the possibility of new attributes being defined that
>>> can be used *only* with dcsa, not directly at media level:
>>> If this is because the protocol is only defined to run over a data
>>> channel, then it could possibly be registered as a media level
>>> attribute (which is then allowed by default with dcsa). If the
>>> protocol were ever defined over another transport the sdp would be
>>> ready for it.
>>> But if, for some reason, the protocol can run over a data channel and
>>> also over some other transport, but for some reason a particular
>>> attribute only applies with data channels, or only applies without
>>> data channels, then there ought to be a way to record that in the
>>> registry.
>>> The worst case is for every spec that defines an attribute to pick its
>>> own way to specify all this, and for there to be no hint in the iana
>>> registry.
>>> IMO it is still better for the iana registry to be given another field
>>> to indicate applicability with data channels.
>>>     Thanks,
>>>     Paul
>>> On 12/9/15 8:24 AM, Juergen Stoetzer-Bradler wrote:
>>>> Paul, Christian, Keith,
>>>> Would propose to add following two new paragraphs to the end of 
>>>> current
>>>> section (dcsa Attribute) in order to more clearly describe the
>>>> relationship of a subprotocol's attribute and the subprotocol's
>>>> transport protocol, especially data channel.
>>>>     It is assumed that in general the usages of subprotocol related
>>>> media
>>>>     level attributes are independent from the subprotocol's transport
>>>>     protocol.  Such transport protocol independent subprotocol related
>>>>     attributes are used in the same way as defined in the original
>>>>     subprotocol specification, also if the subprotocol is transported
>>>>     over a data channel and if the attribute is correspondingly 
>>>> embedded
>>>>     in a "a=dcsa" attribute.
>>>>     There may be cases, where the usage of a subprotocol related media
>>>>     level attribute depends on the subprotocol's transport 
>>>> protocol.  In
>>>>     such cases the subprotocol related usage of the attribute is
>>>> expected
>>>>     to be described for the data channel transport, e.g. in an 
>>>> extension
>>>>     of the original subprotocol specification.
>>>> Section 5.1.2 already explicitly mentions that (subprotocol related)
>>>> media level attributes may follow a data channel declaration (the
>>>> a=dcmap line). Thus the restriction to subprotocol related media level
>>>> attributes only  seems to be covered already.
>>>> Thanks,
>>>> Juergen
>>>> On 01.12.2015 02:12, DRAGE, Keith (Keith) wrote:
>>>>> I think we need to be a little bit careful here.
>>>>> In a large number of cases, the use of the attribute will be 
>>>>> unaltered
>>>>> by the transport that is being used, and I do not think we should 
>>>>> have
>>>>> a need of saying anything if this is the case - it should be the
>>>>> default.
>>>>> So for example for MSRP, there are a number of attributes associated
>>>>> with MSRP - for file transfer and so on, and as far as I can tell,
>>>>> they are used when MSRP is sent over a data channel in exactly the
>>>>> same way as when MSRP is sent over TCP or SCTP. We don't write 
>>>>> special
>>>>> rules for TCP, so why write special rules for datachannel.
>>>>> We do need to identify how we document any special cases, and yes 
>>>>> when
>>>>> we find them, drafts like the msrp draft are the way to do that.
>>>>> Additionally, if we find when defining a new attribute, that it is
>>>>> inappropriate for datachannel usage in some way, then we can write
>>>>> that in the defining specification for the new attribute (although I
>>>>> suspect in this case it will be inappropriate to other transports 
>>>>> than
>>>>> just datachannel).
>>>>> I do assume this entire discussion is limited to attributes that can
>>>>> be applied to media lines. We might find it useful to say that in the
>>>>> general draft, if we have not done so already.
>>>>> Regards
>>>>> Keith
>>>>> -----Original Message-----
>>>>> From: mmusic [] On Behalf Of Christian
>>>>> Groves
>>>>> Sent: 01 December 2015 00:53
>>>>> To:
>>>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
>>>>> 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. 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)
>>>> _______________________________________________
>>>> mmusic mailing list
>>> _______________________________________________
>>> mmusic mailing list
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list