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

Flemming Andreasen <> Fri, 29 January 2016 02:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B58CE1B370E for <>; Thu, 28 Jan 2016 18:19:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.902
X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0aWo7gvFnn-h for <>; Thu, 28 Jan 2016 18:19:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E673A1B3704 for <>; Thu, 28 Jan 2016 18:19:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=17872; q=dns/txt; s=iport; t=1454033977; x=1455243577; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9o17MvaPtYuNl4YbAqnxEzvBEni6roIb+NVtkIhWppU=; b=NPz/Jg/Kc1o2JJP0jGNj2iXE9ac3Fl2SJQB878IaIKtCHsclSUZzuTQL vV04IlQ7UZ8F/LtKSZWTQf/S5W4k6LQ6b1o/clAesnccf+YsgfaJue/rG WDqqB/GRACLiTt4vVDN6iUdS0CgIXOAe8pxWpmXXp9RdOyhgiRDCoVz+u Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,361,1449532800"; d="scan'208";a="68038286"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jan 2016 02:19:36 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id u0T2JZp9001604; Fri, 29 Jan 2016 02:19:36 GMT
To: Paul Kyzivat <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Flemming Andreasen <>
Message-ID: <>
Date: Thu, 28 Jan 2016 21:19:35 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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, 29 Jan 2016 02:19:41 -0000

Apologies for joining in late here, but I would like to go back to the 
beginning of this thread to understand better why we believe there is a 
need for attributes to specifically define whether they can be used with 
the "dcsa" attribute.

The way I see it, the "dcsa" attribute is simply an encapsulating 
attribute that specifies attributes for the data channel sub-protocol. 
What I believe we need here is a set of clear procedures that explain 
how you take those encapsulated procedures, "decapsulate" them and 
negotiate based on the resulting set of parameters (which may need to 
include a few parameters from the media description containing them). 
This is similar to the approach we took with SDP Capability Negotiation 
(RFC 5939). It has the benefit of specifying a generic algorithm for 
dealing with these, and above and beyond that, it's up to the entity 
generating the SDP to include a set of parameters that make sense for 
the given sub-protocol. This is similar to what we do with normal SDP 
(i.e. don't specify all the valid combinations) and avoids the rather 
painful approach that we have with mux-attributes.


-- Flemming

On 12/11/15 10:25 AM, Paul Kyzivat wrote:
> On 12/10/15 7:25 PM, DRAGE, Keith (Keith) wrote:
>> I agree with Christian.
>> But Paul and myself have had this discussion before. He seems 
>> convinced we can essentially put stuff in the IANA registry that 
>> needs to be in an RFC.
> Keith - yes, we continue to disagree. But not for the reason you say. 
> I do not, and have never, proposed that things be put into the 
> registry *instead* of into a document.
> But I do believe that registries are important as an index/discovery 
> tool. You cannot expect people to be aware of every pertinent RFC that 
> may have been published that pertains to something of interest. If I 
> have an interop problem with a new peer, and see something being used 
> that I am not familiar with, then I need a way discover the specs that 
> might pertain to that. The IANA registries serve that function.
> (There are *some* cases where the registries are more important. When 
> there is something where the bar for extension is low, and no public 
> document is required, then the registry becomes only public place to 
> learn about it.)
>> It is probably worth others (such as the WG chairs) weighing on this 
>> discussion.
> Agreed.
>     Thanks,
>     Paul
>> Keith
>> -----Original Message-----
>> From: mmusic [] On Behalf Of Christian 
>> Groves
>> Sent: 11 December 2015 00:21
>> To:
>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
>> 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
>> _______________________________________________
>> mmusic mailing list
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list
> .