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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 2 Feb 2016 17:35:52 -0500

On 1/29/16 10:30 AM, Paul Kyzivat wrote:
> Flemming,
>
> On 1/28/16 9:19 PM, Flemming Andreasen wrote:
>> 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.
>
> Originally there were two distinct scopes in which attributes could 
> appear: session level and media level. Each attribute needs to specify 
> at which of those levels it is valid, and the semantics in each scope. 
> IANA registries were defined for the attributes and identify which 
> scope(s) are applicable to each.
>
> Later we added source level attributes as another scope. And IANA was 
> extended to record that scope as well.
>
> The introduction of dcsa clearly adds another scope, at least as 
> distinct as source level. 
It's not clear to me it's another scope, or at least that the scope is 
significantly different from having parameters that apply to only 
certain transports, etc. where we don't do something like this (think 
MSRP specific parameters, SRTP specific parameters, connection-oriented 
parameters, etc. - we don't need to specify explicitly how they interact 
with all other attributes ever defined).

> If it is important to put scope in the registry, then this one belongs 
> there as much as any other.
>
> 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.

Can you (and/or the authors) elaborate on why such an approach would not 
work ?

Thanks

-- Flemming

>     Thanks,
>     Paul
>
>> Thanks
>>
>> -- 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 [mailto:[email-masked]] On Behalf Of Christian
>>>> Groves
>>>> Sent: 11 December 2015 00:21
>>>> To: [email-masked]
>>>> 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 5.1.2.1 (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 [mailto:[email-masked]] On Behalf Of
>>>>>>>>> Christian Groves
>>>>>>>>> Sent: 01 December 2015 00:53
>>>>>>>>> To: [email-masked]
>>>>>>>>> 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.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)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> mmusic mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 3 Feb 2016 14:13:29 -0500

> 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.

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.

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

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?

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 3 Feb 2016 17:42:08 -0500

On 2/3/16 2:13 PM, Paul Kyzivat wrote:
> 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 
> 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".
>
> decide whether applicability can be specified via an algorithm, or if 
> it must be done by enumeration.
>
> (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.
>
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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 3 Feb 2016 23:58:53 -0500

> 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

---

From: Christian Groves <[email-masked]>
Date: Fri, 5 Feb 2016 14:43:03 +1100

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).

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 6 Feb 2016 13:44:08 -0500

> 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.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 8 Feb 2016 10:13:29 +1100

Hello Paul,

On 7/02/2016 5:44 AM, Paul Kyzivat wrote:
> aren't any iana considerations in 
> draft-ietf-mmusic-msrp-usage-data-channel.
>
[CNG] If you're using data channel then you'd register a websocket 
subprotocol ID (e.g. as we do for CLUE). This should then point to the 
specification that defines the use of the sub-protocol within the 
datachannel. The dcsa parameters can't live without the a=dcmap line 
with the subprotocol.

I agree we need to document something in the IANA considerations section.

Regards, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 8 Feb 2016 11:09:08 -0500

> 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 ?

Also, it would be good to hear from more people on this, including the 
document authors.

Thanks

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Feb 2016 12:09:09 -0500

> data-channel (and hence encapsulated in dcsa) or as a regular media

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.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Feb 2016 12:17:38 -0500

BTW, ISTM that whatever is decided here will apply equally to attributes 
used with a=ssrc.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 11 Feb 2016 15:52:14 -0500

> - 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Feb 2016 16:00:19 -0500

On 2/11/16 3:52 PM, Flemming Andreasen wrote:
> attribute in question.

Can you give me an example?

	Thanks,
	Paul

> Clearly, there are attributes that wouldn't make

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 11 Feb 2016 16:13:35 -0500

> Can you give me an example?
How about preconditions ?

-- Flemming

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 12 Feb 2016 11:45:16 +0100

Flemming, Paul,

The current a=dcmap related text in draft-ietf-mmusic-data-channel-sdpneg doesn't require that the 
'subprotocol' parameter must always be present - rather it is specified as an optional parameter. 
Thus, current sdpneg text would allow to create an SDP offer for a data channel, which contains one 
a=dcmap attribute and potentially multiple a=dcsa attributes without the subprotocol actually being 
given. Based on this discussion I am wondering if the subprotocol parameter should actually be 
mandatory.

In the specific case of MSRP, the msrp-usage-data-channel draft says in 5.1.1.1 that the dcmap 
attribute includes the label and subprotocol parameters. The current text could possible be made 
more explicit by saying that the 'subprotocol="MSRP"' parameter must always be present.
Have just submitted version 04 of the msrp-usage-data-channel draft, which proposes to add 
subprotocol identifier "MSRP" to the WebSocket Subprotocol Name registry. This registry would then 
associate subprotocol id "MSRP" with the msrp-usage-data-channel document.
There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa attribute are specified. And there 
the MSRP specific SDP attributes, which can be dcsa embedded, are described.
'setup' is an attribute, whose semantic changes when being dcsa embedded and associated with 
subprotocol MSRP, as compared to the meaning of an "a=setup" media level attribute of a TCP/MSRP 
m-line. Hence these semantical differences are explicitly addressed in the msrp-usage-data-channel 
draft.

Regarding sdpneg, I also think that the current text in sdpneg seems to be sufficient regarding the 
usage of dcsa encapsulated SDP attributes as being bound to the data channel's subprotocol.  But as 
the semantic of a dcsa encapsulated attribute may be subprotocol specific (like 'setup'), I'd now 
tend to consider the subprotocol parameter in the dcmap attribute as being mandatory, as mentioned 
above. As already discussed, the Websocket subprotocol registry would then refer to the document, 
which specifies the subprotocol specific usage of dcsa encapsulated parameters.

Thanks,
Juergen

On 11.02.2016 21:52, Flemming Andreasen wrote:
>> 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:
> 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.
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 12 Feb 2016 09:52:54 -0500

On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote:
> Flemming, Paul,
>
> The current a=dcmap related text in 
> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the 
> 'subprotocol' parameter must always be present - rather it is 
> specified as an optional parameter. Thus, current sdpneg text would 
> allow to create an SDP offer for a data channel, which contains one 
> a=dcmap attribute and potentially multiple a=dcsa attributes without 
> the subprotocol actually being given. Based on this discussion I am 
> wondering if the subprotocol parameter should actually be mandatory.
>
It would probably simplify the overall SDP negotiation part, but I don't 
know if it would constrain the way data channels were envisioned to be 
used.

> In the specific case of MSRP, the msrp-usage-data-channel draft says 
> in 5.1.1.1 that the dcmap attribute includes the label and subprotocol 
> parameters. The current text could possible be made more explicit by 
> saying that the 'subprotocol="MSRP"' parameter must always be present.
> Have just submitted version 04 of the msrp-usage-data-channel draft, 
> which proposes to add subprotocol identifier "MSRP" to the WebSocket 
> Subprotocol Name registry. This registry would then associate 
> subprotocol id "MSRP" with the msrp-usage-data-channel document.
> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa 
> attribute are specified. And there the MSRP specific SDP attributes, 
> which can be dcsa embedded, are described.
> 'setup' is an attribute, whose semantic changes when being dcsa 
> embedded and associated with subprotocol MSRP, as compared to the 
> meaning of an "a=setup" media level attribute of a TCP/MSRP m-line. 
> Hence these semantical differences are explicitly addressed in the 
> msrp-usage-data-channel draft.
>
> Regarding sdpneg, I also think that the current text in sdpneg seems 
> to be sufficient regarding the usage of dcsa encapsulated SDP 
> attributes as being bound to the data channel's subprotocol. But as 
> the semantic of a dcsa encapsulated attribute may be subprotocol 
> specific (like 'setup'), I'd now tend to consider the subprotocol 
> parameter in the dcmap attribute as being mandatory, as mentioned 
> above. As already discussed, the Websocket subprotocol registry would 
> then refer to the document, which specifies the subprotocol specific 
> usage of dcsa encapsulated parameters.
>
Ok. Going back to discussion between Paul and I, do you believe that in 
for an attribute to be encapsulated in dcsa, the attribute MUST have 
been explicitly define to support this (Paul's suggestion below) or do 
you believe that this is overly constraining, and if so, how shoud we 
relax it ?

Thanks

-- Flemming

>>> 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:
>> 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.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Feb 2016 11:58:57 -0500

Juergen,

You bring up a point that perhaps needs further discussion: what does it 
mean when the subprotocol is not specified?

IIUC there are at least a couple of reasons this might come about:

1) The protocol to be used is not standardized. There is no globally 
unique name for it. The two ends know what protocol to use based on context.

2) The protocol to be used on the channel is not determined via SDP 
negotiation. The applications want to establish the channel, and then 
dynamically decide what protocol to use with it. (And that protocol may 
change over time.)

I guess that it still might be meaningful to use dcsa with (1), but 
there would be no way to determine by examination of the SDP whether the 
usage was compatible with the protocol. In this case the usage of the 
attributes would be "off label" - being adapted to the proprietary 
protocol in a way that hopefully the two ends agree.

I don't see how dcsa makes much sense for (2). If you don't know what 
protocol will be used then how do you know what attributes to use?

	Thanks,
	Paul

On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote:
> 'subprotocol' parameter must always be present - rather it is specified
> as an optional parameter. Thus, current sdpneg text would allow to
> create an SDP offer for a data channel, which contains one a=dcmap
> attribute and potentially multiple a=dcsa attributes without the
> subprotocol actually being given. Based on this discussion I am
> In the specific case of MSRP, the msrp-usage-data-channel draft says in
> 5.1.1.1 that the dcmap attribute includes the label and subprotocol
> 'setup' is an attribute, whose semantic changes when being dcsa embedded
> and associated with subprotocol MSRP, as compared to the meaning of an
> "a=setup" media level attribute of a TCP/MSRP m-line. Hence these
> semantical differences are explicitly addressed in the
> Regarding sdpneg, I also think that the current text in sdpneg seems to
> be sufficient regarding the usage of dcsa encapsulated SDP attributes as
> being bound to the data channel's subprotocol.  But as the semantic of a
> dcsa encapsulated attribute may be subprotocol specific (like 'setup'),
> I'd now tend to consider the subprotocol parameter in the dcmap
> attribute as being mandatory, as mentioned above. As already discussed,
> the Websocket subprotocol registry would then refer to the document,
>>> this draft to say that before an attribute can be used with dcsa,
>>> such usage must be defined somewhere. This could be either:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Feb 2016 12:39:50 -0500

> How about preconditions ?

I don't see how any of the currently defined precondition types 
(connectivity, qos, security) make sense at the data channel level. But 
all of them could make sense when applied to the overall SCTP 
association over which the channels run.

I suppose *in theory* some hypothetical new precondition type might 
apply to a channel, but we have nothing suggesting that.

I will grant that we could just take the position that any attribute can 
be used anywhere, and that the general "ignore if you don't understand" 
rule will prevent problems.

My basic concern is that when an attribute is used in some context, that 
the semantics for such use are well defined, so that an independent 
observer can determine whether the usage is proper.

	Thanks,
	Paul

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Sun, 14 Feb 2016 11:48:03 +0100

Flemming,

Regarding
> It would probably simplify the overall SDP negotiation part, but I don't know if it would 
> constrain the way data channels were envisioned to be used. 

On Friday Paul mentioned in his email two potential use cases, where no subprotocol identifiers 
might be added to a data channel's dcmap attribute. In my last email I hadn't thought of such cases. 
If we don't want to exclude such cases, then requiring the subprotocol ids always to be present 
might indeed be too restrictive.

Regarding
> Ok. Going back to discussion between Paul and I, do you believe that in for an attribute to be 
> encapsulated in dcsa, the attribute MUST have been explicitly define to support this (Paul's 
> suggestion below) or do you believe that this is overly constraining, and if so, how shoud we 
> relax it ? 

I now think that the sdpneg draft might recommend SDP offerers and answerers to always add a 
subprotocol identifier to a data channel's dcmap attribute if dcsa embedded attributes are also 
negotiated for the data channel's subprotocol. I also think we could explicitly add text to sdpneg 
saying that subprotocol identifiers should be added to the IANA Websocket (and in future combined 
data channel) registry. And that this registration should be done via a document, which then 
explicitly describes the usages and semantics of dcsa embedded subprotocol attributes, _if_ those 
usages or semantics deviate from cases, where these attributes are not dcsa encapsulated. I think 
that in those cases, where the usage and meaning of an attribute (always related to the data 
channel's subprotocol) does not deviate from the non-dcsa encapsulated use cases, such an attribute 
may not explicitly need to be described for data channel usage. But I think it might be helpful to 
explicitly say so in the sdpneg draft.

Somebody inspecting an SDP offer or answer, which was generated by an implementation following these 
two recommendations (and which hence contains an IANA registered subprotocol id if it contains any 
dcsa embedded attributes), could then refer to that IANA table, would then find the reference to the 
document, which defines this subprotocol id for data channel usage, and there could check if any of 
the dcsa embedded attributes has a data channel specific semantic. If yes, that specific semantic 
would be described in that document. If such a specific semantic were not described in that 
document, then the default usage and semantic of the attribute would apply also to that data channel 
transport case.

But in that context I'd have an IANA table related question.
A certain subprotocol might be defined for Websocket usage as well as for data channel usage. MSRP 
is already such a case, where draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP over 
data channels, and where draft-pd-dispatch-msrp-websocket defines how to use MSRP over Websockets.
Would the IANA WebSocket Subprotocol Name Registry on 
http://www.iana.org/assignments/websocket/websocket.xml then contain two MSRP related rows? Or just 
one row containing references to both the Websocket and data channel documents?
Should we add related text to the IANA registration section of the sdpneg draft?

Thanks,
Juergen

On 12.02.2016 15:52, EXT Flemming Andreasen wrote:
>> The current a=dcmap related text in draft-ietf-mmusic-data-channel-sdpneg doesn't require that 
>> the 'subprotocol' parameter must always be present - rather it is specified as an optional 
>> parameter. Thus, current sdpneg text would allow to create an SDP offer for a data channel, which 
>> contains one a=dcmap attribute and potentially multiple a=dcsa attributes without the subprotocol 
>> actually being given. Based on this discussion I am wondering if the subprotocol parameter should 
>> actually be mandatory.
>>
> It would probably simplify the overall SDP negotiation part, but I don't know if it would 
> constrain the way data channels were envisioned to be used.
>
>
>> subprotocol identifier "MSRP" to the WebSocket Subprotocol Name registry. This registry would 
>> then associate subprotocol id "MSRP" with the msrp-usage-data-channel document.
>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa attribute are specified. And 
>> there the MSRP specific SDP attributes, which can be dcsa embedded, are described.
>> m-line. Hence these semantical differences are explicitly addressed in the 
>> Regarding sdpneg, I also think that the current text in sdpneg seems to be sufficient regarding 
>> the usage of dcsa encapsulated SDP attributes as being bound to the data channel's subprotocol. 
>> But as the semantic of a dcsa encapsulated attribute may be subprotocol specific (like 'setup'), 
>> I'd now tend to consider the subprotocol parameter in the dcmap attribute as being mandatory, as 
>> mentioned above. As already discussed, the Websocket subprotocol registry would then refer to the 
>> document, which specifies the subprotocol specific usage of dcsa encapsulated parameters.
>>
> Ok. Going back to discussion between Paul and I, do you believe that in for an attribute to be 
> encapsulated in dcsa, the attribute MUST have been explicitly define to support this (Paul's 
> suggestion below) or do you believe that this is overly constraining, and if so, how shoud we 
> relax it ?
>
> Thanks
>
> -- Flemming
>
>
>> Thanks,
>> Juergen
>>
>>
>>> 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.
>>>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Sun, 14 Feb 2016 11:48:48 +0100

Paul,

In your case 2) I would agree that the usage of dcsa embedded attributes seems questionable. After 
all, the dcsa attribute is defined in sdpneg as encapsulating a subprotocol specific attribute. If 
the subprotocol may dynamically change over time without further (SDP offer/answer) negotiation, 
then a negotiation of dcsa embedded attributes may indeed not be very helpful.

In your case 1), I am wondering how would the SDP answerer know which subprotocol to use for which 
data channel, if the subprotocol id is not added to the data channel's dmap attribute (at least if 
multiple data channels are negotiated)? Conceivably via some provisioning, or via a mutual 
understanding of a certain subprotocol to SCTP stream id mapping, or via a certain a priori agreed 
label usage. I hadn't thought of such cases when raising the question if the subprotocol should 
actually be mandatory.
But such use cases would certainly go beyond a pure SDP offer/answer negotiation use case and I 
would argue that such use cases would also go beyond the scope of the sdpneg draft.

I could now imagine the sdpneg draft saying that an SDP offerer should add a subprotocol identifier 
to an offered data channel's dcmap attribute, if it also adds dcsa embedded subprotocol attributes. 
And that an implementation would be on its own, if it does not follow that recommendation (for 
whatever reasons).
Further, similar as for non-dcsa embedded attributes, we could explicitly add text to the sdpneg 
draft saying that a recipient of an an SDP offer or answer should ignore dcsa embedded attributes 
not only if they are completely unknown, but also if their semantics related to the subprotocol is 
not known.
(The current draft says in sec 5.2.3 that the SDP answerer "/Parses and applies the SDP offer.  Note 
that the typical parser normally ignores unknown SDP attributes, which includes data channel related 
attributes./" I think we could make this clearer and explicitly refer to dcsa embedded subprotocol 
attributes.)

Thanks,
Juergen

On 12.02.2016 17:58, EXT Paul Kyzivat wrote:
> Juergen,
>
> You bring up a point that perhaps needs further discussion: what does it mean when the subprotocol 
> is not specified?
>
> 1) The protocol to be used is not standardized. There is no globally unique name for it. The two 
> ends know what protocol to use based on context.
>
> 2) The protocol to be used on the channel is not determined via SDP negotiation. The applications 
> want to establish the channel, and then dynamically decide what protocol to use with it. (And that 
> protocol may change over time.)
>
> I guess that it still might be meaningful to use dcsa with (1), but there would be no way to 
> determine by examination of the SDP whether the usage was compatible with the protocol. In this 
> case the usage of the attributes would be "off label" - being adapted to the proprietary protocol 
> in a way that hopefully the two ends agree.
>
> I don't see how dcsa makes much sense for (2). If you don't know what protocol will be used then 
> how do you know what attributes to use?
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Feb 2016 11:08:48 -0500

On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote:
> Paul,
>
> In your case 2) I would agree that the usage of dcsa embedded attributes
> seems questionable. After all, the dcsa attribute is defined in sdpneg
> as encapsulating a subprotocol specific attribute. If the subprotocol
> may dynamically change over time without further (SDP offer/answer)
> negotiation, then a negotiation of dcsa embedded attributes may indeed
> not be very helpful.
>
> In your case 1), I am wondering how would the SDP answerer know which
> subprotocol to use for which data channel, if the subprotocol id is not
> added to the data channel's dmap attribute (at least if multiple data
> channels are negotiated)? Conceivably via some provisioning, or via a
> mutual understanding of a certain subprotocol to SCTP stream id mapping,
> or via a certain a priori agreed label usage. I hadn't thought of such
> cases when raising the question if the subprotocol should actually be
> mandatory.

IMO it could be any of those. But for this use case it seems more likely 
that channels will be opened dynamically rather than via SDP.

I think the provision for *not* specifying the subprotocol was primarily 
to establish equivalence with what is possible via DCEP.

One possibility is that SDP is used to specify how many channels are 
opened, with the understanding that each of them will use the same 
application-specific protocol.

One possible use for dcsa with an unnamed protocol would be if the 
intent is to use a proprietary variant of a standard protocol, where 
there is still a desire to negotiate options using attributes applicable 
to that standard base protocol. But I'm really stretching to come up 
with this.

> But such use cases would certainly go beyond a pure SDP offer/answer
> negotiation use case and I would argue that such use cases would also go
> beyond the scope of the sdpneg draft.

Probably.

> I could now imagine the sdpneg draft saying that an SDP offerer should
> add a subprotocol identifier to an offered data channel's dcmap
> attribute, if it also adds dcsa embedded subprotocol attributes. And
> that an implementation would be on its own, if it does not follow that
> recommendation (for whatever reasons).

That could work.

> Further, similar as for non-dcsa embedded attributes, we could
> explicitly add text to the sdpneg draft saying that a recipient of an an
> SDP offer or answer should ignore dcsa embedded attributes not only if
> they are completely unknown, but also if their semantics related to the
> subprotocol is not known.
> (The current draft says in sec 5.2.3 that the SDP answerer "/Parses and
> applies the SDP offer.  Note that the typical parser normally ignores
> unknown SDP attributes, which includes data channel related
> attributes./" I think we could make this clearer and explicitly refer to
> dcsa embedded subprotocol attributes.)

Yes, that would help.

	Thanks,
	Paul

>> You bring up a point that perhaps needs further discussion: what does
>> it mean when the subprotocol is not specified?
>>
>> dynamically decide what protocol to use with it. (And that protocol
>> may change over time.)
>>
>> there would be no way to determine by examination of the SDP whether
>> the usage was compatible with the protocol. In this case the usage of
>> the attributes would be "off label" - being adapted to the proprietary

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Feb 2016 10:41:35 +1100

Hello Juergen,

Your proposal seems reasonable to me.

With regards to the IANA registry for websockets I think it should be 
possible to add two references to the row for MSRP. It's only editing a 
table.

Regards, Christian

On 14/02/2016 9:48 PM, Juergen Stoetzer-Bradler wrote:
> Flemming,
>
> Regarding
>> It would probably simplify the overall SDP negotiation part, but I 
>> don't know if it would constrain the way data channels were 
>> envisioned to be used. 
>
> On Friday Paul mentioned in his email two potential use cases, where 
> no subprotocol identifiers might be added to a data channel's dcmap 
> attribute. In my last email I hadn't thought of such cases. If we 
> don't want to exclude such cases, then requiring the subprotocol ids 
> always to be present might indeed be too restrictive.
>
> Regarding
>> Ok. Going back to discussion between Paul and I, do you believe that 
>> in for an attribute to be encapsulated in dcsa, the attribute MUST 
>> have been explicitly define to support this (Paul's suggestion below) 
>> or do you believe that this is overly constraining, and if so, how 
>> shoud we relax it ? 
>
> I now think that the sdpneg draft might recommend SDP offerers and 
> answerers to always add a subprotocol identifier to a data channel's 
> dcmap attribute if dcsa embedded attributes are also negotiated for 
> the data channel's subprotocol. I also think we could explicitly add 
> text to sdpneg saying that subprotocol identifiers should be added to 
> the IANA Websocket (and in future combined data channel) registry. And 
> that this registration should be done via a document, which then 
> explicitly describes the usages and semantics of dcsa embedded 
> subprotocol attributes, _if_ those usages or semantics deviate from 
> cases, where these attributes are not dcsa encapsulated. I think that 
> in those cases, where the usage and meaning of an attribute (always 
> related to the data channel's subprotocol) does not deviate from the 
> non-dcsa encapsulated use cases, such an attribute may not explicitly 
> need to be described for data channel usage. But I think it might be 
> helpful to explicitly say so in the sdpneg draft.

>
> Somebody inspecting an SDP offer or answer, which was generated by an 
> implementation following these two recommendations (and which hence 
> contains an IANA registered subprotocol id if it contains any dcsa 
> embedded attributes), could then refer to that IANA table, would then 
> find the reference to the document, which defines this subprotocol id 
> for data channel usage, and there could check if any of the dcsa 
> embedded attributes has a data channel specific semantic. If yes, that 
> specific semantic would be described in that document. If such a 
> specific semantic were not described in that document, then the 
> default usage and semantic of the attribute would apply also to that 
> data channel transport case.
>
> A certain subprotocol might be defined for Websocket usage as well as 
> for data channel usage. MSRP is already such a case, where 
> draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP over 
> http://www.iana.org/assignments/websocket/websocket.xml then contain 
> two MSRP related rows? Or just one row containing references to both 
> the Websocket and data channel documents?
>> It would probably simplify the overall SDP negotiation part, but I 
>> don't know if it would constrain the way data channels were 
>> envisioned to be used.
>>
>>
>>> in 5.1.1.1 that the dcmap attribute includes the label and 
>>> subprotocol parameters. The current text could possible be made more 
>>> explicit by saying that the 'subprotocol="MSRP"' parameter must 
>>> always be present.
>>> above. As already discussed, the Websocket subprotocol registry 
>>> would then refer to the document, which specifies the subprotocol 
>>> specific usage of dcsa encapsulated parameters.
>>>
>> Ok. Going back to discussion between Paul and I, do you believe that 
>> in for an attribute to be encapsulated in dcsa, the attribute MUST 
>> have been explicitly define to support this (Paul's suggestion below) 
>> or do you believe that this is overly constraining, and if so, how 
>> shoud we relax it ?
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> Thanks,
>>> Juergen
>>>
>>>
>>>> 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.
>>>>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 16 Feb 2016 14:01:57 +0100

Paul,

Thanks for further feedback. Fully agree now that the subprotocol parameter should stay optional.
Will come back with with a proposal of how the sdpneg text could be enhanced as discussed.

Thanks,
Juergen

On 15.02.2016 17:08, EXT Paul Kyzivat wrote:
> IMO it could be any of those. But for this use case it seems more likely that channels will be 
> opened dynamically rather than via SDP.
>
> I think the provision for *not* specifying the subprotocol was primarily to establish equivalence 
> with what is possible via DCEP.
>
> One possibility is that SDP is used to specify how many channels are opened, with the 
> understanding that each of them will use the same application-specific protocol.
>
> One possible use for dcsa with an unnamed protocol would be if the intent is to use a proprietary 
> variant of a standard protocol, where there is still a desire to negotiate options using 
> attributes applicable to that standard base protocol. But I'm really stretching to come up with this.
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 16 Feb 2016 14:02:27 +0100

Hello Christian,

Thank you for your feedback. Ok, I think then it might be helpful to add a related sentence or two 
to the IANA registration section of the sdpneg draft.

Thanks,
Juergen

On 16.02.2016 00:41, EXT Christian Groves wrote:
> With regards to the IANA registry for websockets I think it should be possible to add two 
> references to the row for MSRP. It's only editing a table.
>
> Regards, Christian
>
>> might be added to a data channel's dcmap attribute. In my last email I hadn't thought of such 
>> cases. If we don't want to exclude such cases, then requiring the subprotocol ids always to be 
>> present might indeed be too restrictive.
>>
>> Regarding
>> negotiated for the data channel's subprotocol. I also think we could explicitly add text to 
>> sdpneg saying that subprotocol identifiers should be added to the IANA Websocket (and in future 
>> combined data channel) registry. And that this registration should be done via a document, which 
>> then explicitly describes the usages and semantics of dcsa embedded subprotocol attributes, _if_ 
>> those usages or semantics deviate from cases, where these attributes are not dcsa encapsulated. I 
>> think that in those cases, where the usage and meaning of an attribute (always related to the 
>> data channel's subprotocol) does not deviate from the non-dcsa encapsulated use cases, such an 
>> attribute may not explicitly need to be described for data channel usage. But I think it might be 
>> Somebody inspecting an SDP offer or answer, which was generated by an implementation following 
>> these two recommendations (and which hence contains an IANA registered subprotocol id if it 
>> contains any dcsa embedded attributes), could then refer to that IANA table, would then find the 
>> reference to the document, which defines this subprotocol id for data channel usage, and there 
>> could check if any of the dcsa embedded attributes has a data channel specific semantic. If yes, 
>> that specific semantic would be described in that document. If such a specific semantic were not 
>> described in that document, then the default usage and semantic of the attribute would apply also 
>> to that data channel transport case.
>>
>> A certain subprotocol might be defined for Websocket usage as well as for data channel usage. 
>> MSRP is already such a case, where draft-ietf-mmusic-msrp-usage-data-channel defines how to use 
>> MSRP over data channels, and where draft-pd-dispatch-msrp-websocket defines how to use MSRP over 
>> Websockets.
>> http://www.iana.org/assignments/websocket/websocket.xml then contain two MSRP related rows? Or 
>> just one row containing references to both the Websocket and data channel documents?
>>>> parameter. Thus, current sdpneg text would allow to create an SDP offer for a data channel, 
>>>> which contains one a=dcmap attribute and potentially multiple a=dcsa attributes without the 
>>>> subprotocol actually being given. Based on this discussion I am wondering if the subprotocol 
>>>> parameter should actually be mandatory.
>>>>
>>>> attribute includes the label and subprotocol parameters. The current text could possible be 
>>>> made more explicit by saying that the 'subprotocol="MSRP"' parameter must always be present.
>>>> subprotocol MSRP, as compared to the meaning of an "a=setup" media level attribute of a 
>>>> TCP/MSRP m-line. Hence these semantical differences are explicitly addressed in the 
>>>> But as the semantic of a dcsa encapsulated attribute may be subprotocol specific (like 
>>>> 'setup'), I'd now tend to consider the subprotocol parameter in the dcmap attribute as being 
>>>> mandatory, as mentioned above. As already discussed, the Websocket subprotocol registry would 
>>>> then refer to the document, which specifies the subprotocol specific usage of dcsa encapsulated 
>>>> parameters.
>>>>
>>>>>> before an attribute can be used with dcsa, such usage must be defined somewhere. This could 
>>>>>> be either:

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 17 Feb 2016 14:12:49 +0100

Hi Paul, Christian, Flemming, Bo,

Have just submitted version 08 of draft-ietf-mmusic-data-channel-sdpneg.
The changes compared to version 07 are essentially as follows.

*   Two new paragraphs in section 5.1.2.1 (dcsa Attribute) regarding the relationship of 
subprotocols and their attributes.
*   Two new SDP offer/answer considerations in section 5.2.5 (Various SDP Offer/Answer Scenarios and 
Considerations)  regarding unknown subprotocol attributes or known subprotocol attributes, whose 
data channel transport specific semantic is not known.
*   A new paragraph in section 8.1 (IANA Considerations / Subprotocol Identifiers) related to cases, 
where a subprotocol is defined for data channel and Websocket transport.

These changes should address the points discussed in this email thread.

Thank you,
Juergen

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 18 Feb 2016 14:03:08 -0500

> data channel transport case.
Sounds reasonable with the caveat that you may have attributes defined 
for use with a particular sub-protocol outside the subprotocol draft 
itself (e.g. because such an attribute was either defined subsequently 
or its use with a specific subprotocol is defined subsequently). If so, 
we would need an IANA registry structure (under SDP) that for each 
subprotocol defines the set of attributes that have been defined with 
specific semantics for that subprotocol.

> Should we add related text to the IANA registration section of the 
See above.

Thanks

-- Flemming

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 19 Feb 2016 14:56:03 +0100

Flemming,

Regarding
> Sounds reasonable with the caveat that you may have attributes defined for use with a particular 
> sub-protocol outside the subprotocol draft itself (e.g. because such an attribute was either 
> defined subsequently or its use with a specific subprotocol is defined subsequently). If so, we 
> would need an IANA registry structure (under SDP) that for each subprotocol defines the set of 
> attributes that have been defined with specific semantics for that subprotocol. 

Let's assume a future document defines how to establish MSRP sessions over a transport protocol 
unequal to TCP, TLS, or data channel, and that this document also defines a new MSRP related 
attribute, whose semantic is only defined for this new transport case (like a maximal MSRP chunk 
size specific for the new transport). I assume that this future document would request to add this 
new attribute to one of the existing IANA SDP attribute tables (assumingly to the "att-field (media 
level only)" table).
Let's further assume that an implementation creates an SDP offer for an MSRP session over a data 
channel and adds this new attribute as dcsa embedded MSRP subprotocol attribute (for whatever reasons).

Somebody seeing and inspecting this SDP offer could use the dcmap attribute's subprotocol value 
"MSRP" to get a reference to the msrp-usage-data-channel document. That document would not mention 
that new attribute at all. The next step could then be to consult the IANA SDP tables, and there 
this new attribute would be found together with a reference to this future document.
As assumingly this new MSRP related attribute would only be defined for this new transport, I think 
this new attribute should then be ignored by the recipient of this SDP offer.
Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 now contains two related 
recommendations:

'SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is unknown.
  *  The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line.

SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose 
subprotocol attribute semantic is not known for the data channel transport case.
  *  The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line.'

Would these recommendations address the case you are describing?

Thanks,
Juergen

On 18.02.2016 20:03, EXT Flemming Andreasen wrote:
> Sounds reasonable with the caveat that you may have attributes defined for use with a particular 
> sub-protocol outside the subprotocol draft itself (e.g. because such an attribute was either 
> defined subsequently or its use with a specific subprotocol is defined subsequently). If so, we 
> would need an IANA registry structure (under SDP) that for each subprotocol defines the set of 
> attributes that have been defined with specific semantics for that subprotocol.
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2016 11:42:19 -0500

On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote:
> *   Two new paragraphs in section 5.1.2.1 (dcsa Attribute) regarding the
> relationship of subprotocols and their attributes.
> *   Two new SDP offer/answer considerations in section 5.2.5 (Various
> SDP Offer/Answer Scenarios and Considerations)  regarding unknown
> subprotocol attributes or known subprotocol attributes, whose data
> channel transport specific semantic is not known.
> *   A new paragraph in section 8.1 (IANA Considerations / Subprotocol
> Identifiers) related to cases, where a subprotocol is defined for data
> channel and Websocket transport.
>

This is an improvement. But I think things could still be made clearer.

Consider the following addition to 5.1.2.1:

    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.  A data channel
    specific usage of a subprotocol attribute is expected to be specified
    in the same document, which registers the subprotocol's identifier
    for data channel usage as described in Section 8.1.

This text makes sense when there is a clear distinction between 
subprotocol and protocol. Unfortunately, the way SDP has evolved there 
is no such clear distinction in many cases, such as RTP over UDP or TCP, 
etc. Those are combined into a single protocol value. While that can 
usually be parsed apart at slashes, there isn't good terminology for it.

My point is that when I read the above, I don't know how it applies to, 
say, RTP attributes. Or does it only apply for attributes that are 
clearly defined for a *sub*protocol?

I think this is primarily that we lack well defined vocabulary for all 
of this. But I think it would be too much to expect this draft to 
*solve* the vocabulary problem. In lieu of doing so, maybe it would be 
sufficient to give some concrete examples, even if they have to be 
hypothetical ones.

	Thanks,
	Paul

>>> IMO it could be any of those. But for this use case it seems more
>>> likely that channels will be opened dynamically rather than via SDP.
>>>
>>> I think the provision for *not* specifying the subprotocol was
>>> primarily to establish equivalence with what is possible via DCEP.
>>>
>>> there is still a desire to negotiate options using attributes
>>> applicable to that standard base protocol. But I'm really stretching
>>> to come up with this.
>>>
>>>>>> specified
>>>>>>>>> attributes that may or may not be used with MSRP differ between
>>>>>>>>> use
>>>>>>>>> in a

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 19 Feb 2016 12:24:46 -0500

On 2/19/16 8:56 AM, Juergen Stoetzer-Bradler wrote:
> Flemming,
>
> Regarding
>> Sounds reasonable with the caveat that you may have attributes 
>> defined for use with a particular sub-protocol outside the 
>> subprotocol draft itself (e.g. because such an attribute was either 
>> defined subsequently or its use with a specific subprotocol is 
>> defined subsequently). If so, we would need an IANA registry 
>> structure (under SDP) that for each subprotocol defines the set of 
> Let's assume a future document defines how to establish MSRP sessions 
> over a transport protocol unequal to TCP, TLS, or data channel, and 
> that this document also defines a new MSRP related attribute, whose 
> semantic is only defined for this new transport case (like a maximal 
> MSRP chunk size specific for the new transport). I assume that this 
> future document would request to add this new attribute to one of the 
> existing IANA SDP attribute tables (assumingly to the "att-field 
> (media level only)" table).
So far so good, however the case I had in mind is one where the new 
attribute would apply to one or more existing subprotocols .
> Let's further assume that an implementation creates an SDP offer for 
> an MSRP session over a data channel and adds this new attribute as 
> dcsa embedded MSRP subprotocol attribute (for whatever reasons).
>
> Somebody seeing and inspecting this SDP offer could use the dcmap 
> attribute's subprotocol value "MSRP" to get a reference to the 
> msrp-usage-data-channel document. That document would not mention that 
> new attribute at all. The next step could then be to consult the IANA 
> SDP tables, and there this new attribute would be found together with 
> a reference to this future document.
> As assumingly this new MSRP related attribute would only be defined 
> for this new transport,
While that is certainly a valid use case, I wasn't thinking of 
restricting it to that and hence the request for an actual sub-registry 
for each of these subprotocols to register attributes that can be used 
with each of them (some attributes may apply to multiple).

> I think this new attribute should then be ignored by the recipient of 
> this SDP offer.
> Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 
> now contains two related recommendations:
>
> SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 
> attribute is known, but whose subprotocol attribute semantic is not 
> known for the data channel transport case.
They only address the case(s) partally per the above.

Thanks

-- Flemming

>>>> Ok. Going back to discussion between Paul and I, do you believe 
>>>> that in for an attribute to be encapsulated in dcsa, the attribute 
>>>> MUST have been explicitly define to support this (Paul's suggestion 
>>>> below) or do you believe that this is overly constraining, and if 
>>>> so, how shoud we relax it ? 
>>>
>>> text to sdpneg saying that subprotocol identifiers should be added 
>>> to the IANA Websocket (and in future combined data channel) 
>>> registry. And that this registration should be done via a document, 
>>> which then explicitly describes the usages and semantics of dcsa 
>>> embedded subprotocol attributes, _if_ those usages or semantics 
>>> deviate from cases, where these attributes are not dcsa 
>>> encapsulated. I think that in those cases, where the usage and 
>>> meaning of an attribute (always related to the data channel's 
>>> subprotocol) does not deviate from the non-dcsa encapsulated use 
>>> cases, such an attribute may not explicitly need to be described for 
>>> data channel usage. But I think it might be helpful to explicitly 
>>> say so in the sdpneg draft.
>>>
>>> Somebody inspecting an SDP offer or answer, which was generated by 
>>> an implementation following these two recommendations (and which 
>>> hence contains an IANA registered subprotocol id if it contains any 
>>> dcsa embedded attributes), could then refer to that IANA table, 
>>> would then find the reference to the document, which defines this 
>>> subprotocol id for data channel usage, and there could check if any 
>>> of the dcsa embedded attributes has a data channel specific 
>>> semantic. If yes, that specific semantic would be described in that 
>>> document. If such a specific semantic were not described in that 
>>> document, then the default usage and semantic of the attribute would 
>>> apply also to that data channel transport case.
>>>
>> Sounds reasonable with the caveat that you may have attributes 
>> defined for use with a particular sub-protocol outside the 
>> subprotocol draft itself (e.g. because such an attribute was either 
>> defined subsequently or its use with a specific subprotocol is 
>> defined subsequently). If so, we would need an IANA registry 
>> structure (under SDP) that for each subprotocol defines the set of 
>>> A certain subprotocol might be defined for Websocket usage as well 
>>> as for data channel usage. MSRP is already such a case, where 
>>> draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP 
>>> over data channels, and where draft-pd-dispatch-msrp-websocket 
>>> defines how to use MSRP over Websockets.
>>>>> specified as an optional parameter. Thus, current sdpneg text 
>>>>> would allow to create an SDP offer for a data channel, which 
>>>>> contains one a=dcmap attribute and potentially multiple a=dcsa 
>>>>> attributes without the subprotocol actually being given. Based on 
>>>>> this discussion I am wondering if the subprotocol parameter should 
>>>>> actually be mandatory.
>>>>>
>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft 
>>>>> says in 5.1.1.1 that the dcmap attribute includes the label and 
>>>>> subprotocol parameters. The current text could possible be made 
>>>>> Have just submitted version 04 of the msrp-usage-data-channel 
>>>>> draft, which proposes to add subprotocol identifier "MSRP" to the 
>>>>> WebSocket Subprotocol Name registry. This registry would then 
>>>>> attribute are specified. And there the MSRP specific SDP 
>>>>> attributes, which can be dcsa embedded, are described.
>>>>> meaning of an "a=setup" media level attribute of a TCP/MSRP 
>>>>> m-line. Hence these semantical differences are explicitly 
>>>>> addressed in the msrp-usage-data-channel draft.
>>>>>
>>>>> Regarding sdpneg, I also think that the current text in sdpneg 
>>>>> seems to be sufficient regarding the usage of dcsa encapsulated 
>>>>> SDP attributes as being bound to the data channel's subprotocol. 
>>>>> But as the semantic of a dcsa encapsulated attribute may be 
>>>>> subprotocol specific (like 'setup'), I'd now tend to consider the 
>>>>> subprotocol parameter in the dcmap attribute as being mandatory, 
>>>>> as mentioned above. As already discussed, the Websocket 
>>>>> subprotocol registry would then refer to the document, which 
>>>>> specifies the subprotocol specific usage of dcsa encapsulated 
>>>>> parameters.
>>>>>
>>>> Ok. Going back to discussion between Paul and I, do you believe 
>>>> that in for an attribute to be encapsulated in dcsa, the attribute 
>>>> MUST have been explicitly define to support this (Paul's suggestion 
>>>> below) or do you believe that this is overly constraining, and if 
>>>> so, how shoud we relax it ?
>>>>
>>>> Thanks
>>>>
>>>> -- Flemming
>>>>
>>>>
>>>>> Thanks,
>>>>> Juergen
>>>>>
>>>>>
>>>>>>>> use in a
>>>>>>> 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:

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 23 Feb 2016 14:28:59 +0100

Flemming,

Thanks for further feedback. Regarding your comments:
> So far so good, however the case I had in mind is one where the new attribute would apply to one 
> or more existing subprotocols.
and
> While that is certainly a valid use case, I wasn't thinking of restricting it to that and hence 
> the request for an actual sub-registry for each of these subprotocols to register attributes that 
> can be used with each of them (some attributes may apply to multiple). 

Ok, as per my understanding such a new attribute would be introduced in a (let's assume) future 
document. I think that such a future document should describe the new attribute's semantic with 
respect to all protocols for which it is intended to be used. And if one of these protocols can be 
transported over data channels, and if the new attribute's meaning then also has data channel 
specific aspects, this future document should also describe those aspects. If this new attribute is 
then added to the IANA SDP attribute registry (presumably as media level only or media and session 
level attribute), then this document could be found when searching for the new attribute.

I am not yet sure I fully understand how such subprotocol specific registries could be used. Right 
now there are already drafts describing MSRP, BFCP and T.140 as data channel subprotocols. Do you 
think IANA registry tables for each of these subprotocols should be created (and in future for any 
further protocol, which might be used as data channel subprotocol)?
Where then a new attribute might be listed in multiple of these subprotocol specific registries, 
depending on which subprotocol it might be used for?
And all already existing attributes, which might also be used for a data channel subprotocol - do 
you think that these should also be added to such subprotocol specific registry tables?

Coming back to MSRP as an example - RFC 5547 defines several file transfer related attributes. 
Conceivably, a future document could define another file transfer protocol unequal to MSRP (and 
based on data channel transport, or based on a transport protocol unequal to data channel). And that 
potential future document might then describe how (some of) the file transfer related SDP attributes 
might be re-used for this new file transfer protocol. Would you then expect these file transfer 
related SDP attributes to be added to such a new registry associated with the new file transfer 
protocol? Also if data channel transport of this potential new file transfer protocol were not 
defined in that assumed future document?

Right now I'm not sure if this topic is only data channel specific. E.g. the a=setup attribute was 
originally introduced in RFC 4145 for TCP connection negotiation. Later on, this attribute was 
reused for TLS connection negotiation (RFC 4572) and DTLS association negotiation (RFC 5763, 
draft-ietf-mmusic-sctp-sdp, draft-ietf-mmusic-dtls-sdp). As far as I see the IANA SDP parameters 
registry for the a=setup attribute only refers to RFC 4145. And the two sctp-sdp and dtls-sdp drafts 
don't seem to request updating this registry. However, all these documents have setup attribute 
related texts describing the extended semantics of the setup attribute.

Somebody seeing an SDP offer like the UDP/DTLS/SCTP related one in section 13.1 of 
draft-ietf-mmusic-sctp-sdp-15, when looking for the setup attribute's usage in this SDP offer and 
when therefore searching the related reference in the IANA SDP attribute registry, would only find 
the reference to RFC 4145. However, he/she could look up the UDP/DTLS/SCTP m-line proto value in the 
IANA SDP proto registry, and there would find the reference to the future RFC of 
draft-ietf-mmusic-sctp-sdp, where the semantic of the setup attribute within this SDP offer instance 
is specified.

Somebody seeing an SDP offer like the DTLS-SRTP related one in section 7.1 of RFC 5763, again when 
trying to find the semantic of the setup attribute in this SDP offer, would similarly find the 
reference to RFC 4145. When searching the proto registry for UDP/TLS/RTP/SAVP he/she would find the 
reference to RFC 5764. RFC 5764 does not mention the setup attribute at all, but RFC 5763 does and 
describes its usage in the DTLS-SRTP case. [But then it might not be clear if this setup attribute 
is used in the original sense of RFCs 5763 / 5764, or with the modified semantic described in 
draft-ietf-mmusic-dtls-sdp (which excludes value 'holdconn').]

In these cases, do you think that subprotocol (TLS and DTLS as "subprotocols" of TCP and UDP) 
specific sub-registries should be created? And if yes, how do you envision those would be used?

Thanks,
Juergen

On 19.02.2016 18:24, EXT Flemming Andreasen wrote:
>> size specific for the new transport). I assume that this future document would request to add 
>> this new attribute to one of the existing IANA SDP attribute tables (assumingly to the "att-field 
> So far so good, however the case I had in mind is one where the new attribute would apply to one 
> or more existing subprotocols .
>> "MSRP" to get a reference to the msrp-usage-data-channel document. That document would not 
>> mention that new attribute at all. The next step could then be to consult the IANA SDP tables, 
>> and there this new attribute would be found together with a reference to this future document.
>> As assumingly this new MSRP related attribute would only be defined for this new transport,
> While that is certainly a valid use case, I wasn't thinking of restricting it to that and hence 
> the request for an actual sub-registry for each of these subprotocols to register attributes that 
> can be used with each of them (some attributes may apply to multiple).
>
>> I think this new attribute should then be ignored by the recipient of this SDP offer.
>>>> combined data channel) registry. And that this registration should be done via a document, 
>>>> which then explicitly describes the usages and semantics of dcsa embedded subprotocol 
>>>> attributes, _if_ those usages or semantics deviate from cases, where these attributes are not 
>>>> dcsa encapsulated. I think that in those cases, where the usage and meaning of an attribute 
>>>> (always related to the data channel's subprotocol) does not deviate from the non-dcsa 
>>>> encapsulated use cases, such an attribute may not explicitly need to be described for data 
>>>> channel usage. But I think it might be helpful to explicitly say so in the sdpneg draft.
>>>>
>>>> contains any dcsa embedded attributes), could then refer to that IANA table, would then find 
>>>> the reference to the document, which defines this subprotocol id for data channel usage, and 
>>>> there could check if any of the dcsa embedded attributes has a data channel specific semantic. 
>>>> If yes, that specific semantic would be described in that document. If such a specific semantic 
>>>> were not described in that document, then the default usage and semantic of the attribute would 
>>>> MSRP over data channels, and where draft-pd-dispatch-msrp-websocket defines how to use MSRP 
>>>> over Websockets.
>>>>>> The current a=dcmap related text in draft-ietf-mmusic-data-channel-sdpneg doesn't require 
>>>>>> that the 'subprotocol' parameter must always be present - rather it is specified as an 
>>>>>> optional parameter. Thus, current sdpneg text would allow to create an SDP offer for a data 
>>>>>> channel, which contains one a=dcmap attribute and potentially multiple a=dcsa attributes 
>>>>>> without the subprotocol actually being given. Based on this discussion I am wondering if the 
>>>>>> subprotocol parameter should actually be mandatory.
>>>>>>
>>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft says in 5.1.1.1 that the 
>>>>>> dcmap attribute includes the label and subprotocol parameters. The current text could 
>>>>>> possible be made more explicit by saying that the 'subprotocol="MSRP"' parameter must always 
>>>>>> be present.
>>>>>> Regarding sdpneg, I also think that the current text in sdpneg seems to be sufficient 
>>>>>> regarding the usage of dcsa encapsulated SDP attributes as being bound to the data channel's 
>>>>>> subprotocol. But as the semantic of a dcsa encapsulated attribute may be subprotocol specific 
>>>>>> (like 'setup'), I'd now tend to consider the subprotocol parameter in the dcmap attribute as 
>>>>>> being mandatory, as mentioned above. As already discussed, the Websocket subprotocol registry 
>>>>>> would then refer to the document, which specifies the subprotocol specific usage of dcsa 
>>>>>> encapsulated parameters.
>>>>>>
>>>>>>>> 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:
>>>>>>> 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

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 23 Feb 2016 14:29:42 +0100

Hi Paul,

Thanks for your feedback to the updates in version 08.
Please find my remarks inserted below your comments.

Thanks,
Juergen

On 19.02.2016 17:42, EXT Paul Kyzivat wrote:
> This text makes sense when there is a clear distinction between subprotocol and protocol. 
> Unfortunately, the way SDP has evolved there is no such clear distinction in many cases, such as 
> RTP over UDP or TCP, etc. Those are combined into a single protocol value. While that can usually 
> be parsed apart at slashes, there isn't good terminology for it.
>
> My point is that when I read the above, I don't know how it applies to, say, RTP attributes. Or 
> does it only apply for attributes that are clearly defined for a *sub*protocol?
>
> I think this is primarily that we lack well defined vocabulary for all of this. But I think it 
> would be too much to expect this draft to *solve* the vocabulary problem. In lieu of doing so, 
> maybe it would be sufficient to give some concrete examples, even if they have to be hypothetical 
> ones.

[Juergen] Agree that it would be helpful to have more precise definitions of the differences of the 
terms protocol and subprotocol, especially when those terms are used outside the scope of data 
channels (or Websockets). When only focusing on data channels the notion of a "subprotocol" seems to 
be clearer - at least draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket 
Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter. (But 
draft-ietf-rtcweb-data-channel does not define what a data channel's "subprotocol" is.) So far the 
sdpneg draft relatively informally starts using the term "subprotocol" in the introduction and there 
refers to Websocket "subprotocols". Perhaps we should add the term "subprotocol" to the list of used 
terminology in section 3.

The sdpneg document, together with the data channel subprotocol specific document (which defines the 
value of the a=dcmap attribute's "subprotocol" parameter), should certainly give clear guidance on 
how to interpret SDP offers or answers like e.g.:

      m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
      c=IN IP4 10.10.10.1
      a=max-message-size:100000
      a=sctp-port:5000
      ...
      a=dcmap:0 subprotocol="MSRP"
      a=dcsa:0 accept-types:message/cpim text/plain
      a=dcsa:0 framerate:...
      a=dcsa:0 lang:...

An implementation receiving such an offer would need to decide what to do with the dcsa embedded 
framerate and lang attributes. Or, someone implementing MSRP over data channel based services may 
need to decide whether or not to use these attributes, and if yes, how.
(I am using these two attributes just as hypothetical examples - don't want to suggest that those 
may indeed be used for MSRP over data channel transport).

The msrp-usage-data-channel document doesn't mention these two attributes. When looking at the IANA 
SDP attribute registry tables, I would find both attributes specified in RFC 4566. There, 
"framerate" is explicitly said to be defined only "for video media". Just to be sure I could 
additionally have a look at the MSRP specifying documents, RFC 4975 and RFC 4976, but there would 
not find any text at all related to "framerate". So this case seems pretty clear and I would 
therefore conclude that the "framerate" attribute should not be used for MSRP, and that a receiver 
of such an offer or answer should ignore it.

When looking at the definition of the "lang" attribute in RFC 4566 I would not see any explicit hint 
of what protocols this attribute might be used with, especially if "lang" could be used when 
negotiating an MSRP session. When then looking at RFC 4975 I would indeed find "lang" - but not as 
SDP attribute, rather as XML tag parameter within an example MSRP message payload. Thus, the case of 
the "lang" attribute might not be as unambiguous as the one with the "framerate" attribute, but here 
too I think the typical choice would be to ignore that attribute when receiving such an offer or 
answer.
It seems to me that the two new "ignore" rules in section 5.2.5 of sdpneg-08 may also be applied in 
these cases.

Admittedly, these examples may seem a bit far-fetched, but would those go into the direction you had 
in mind?

>>>>>>> says in
>>>>>>> seems to
>>>>>>>>> sufficient for

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2016 16:26:07 -0500

Hi Juergen,

See response at end.

On 2/23/16 8:29 AM, Juergen Stoetzer-Bradler wrote:
>> is no such clear distinction in many cases, such as RTP over UDP or
>> TCP, etc. Those are combined into a single protocol value. While that
>> can usually be parsed apart at slashes, there isn't good terminology
>> for it.
>>
>> My point is that when I read the above, I don't know how it applies
>> to, say, RTP attributes. Or does it only apply for attributes that are
> [Juergen] Agree that it would be helpful to have more precise
> definitions of the differences of the terms protocol and subprotocol,
> especially when those terms are used outside the scope of data channels
> (or Websockets). When only focusing on data channels the notion of a
> "subprotocol" seems to be clearer - at least
> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket
> Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter.
> (But draft-ietf-rtcweb-data-channel does not define what a data
> channel's "subprotocol" is.) So far the sdpneg draft relatively
> informally starts using the term "subprotocol" in the introduction and
> there refers to Websocket "subprotocols". Perhaps we should add the term
> "subprotocol" to the list of used terminology in section 3.
>
> The sdpneg document, together with the data channel subprotocol specific
> document (which defines the value of the a=dcmap attribute's
> "subprotocol" parameter), should certainly give clear guidance on how to
> interpret SDP offers or answers like e.g.:
>
> An implementation receiving such an offer would need to decide what to
> do with the dcsa embedded framerate and lang attributes. Or, someone
> implementing MSRP over data channel based services may need to decide
> whether or not to use these attributes, and if yes, how.
> (I am using these two attributes just as hypothetical examples - don't
> want to suggest that those may indeed be used for MSRP over data channel
> transport).
>
> The msrp-usage-data-channel document doesn't mention these two
> attributes. When looking at the IANA SDP attribute registry tables, I
> would find both attributes specified in RFC 4566. There, "framerate" is
> explicitly said to be defined only "for video media". Just to be sure I
> could additionally have a look at the MSRP specifying documents, RFC
> 4975 and RFC 4976, but there would not find any text at all related to
> "framerate". So this case seems pretty clear and I would therefore
> conclude that the "framerate" attribute should not be used for MSRP, and
> that a receiver of such an offer or answer should ignore it.
>
> When looking at the definition of the "lang" attribute in RFC 4566 I
> would not see any explicit hint of what protocols this attribute might
> be used with, especially if "lang" could be used when negotiating an
> MSRP session. When then looking at RFC 4975 I would indeed find "lang" -
> but not as SDP attribute, rather as XML tag parameter within an example
> MSRP message payload. Thus, the case of the "lang" attribute might not
> be as unambiguous as the one with the "framerate" attribute, but here
> too I think the typical choice would be to ignore that attribute when
> receiving such an offer or answer.
> It seems to me that the two new "ignore" rules in section 5.2.5 of
> sdpneg-08 may also be applied in these cases.
>
> Admittedly, these examples may seem a bit far-fetched, but would those
> go into the direction you had in mind?

Yes. Note that using examples is just me grasping at straws, since a 
real solution looks like to big a problem for this draft to tackle by 
itself. I am entirely open to other ideas for how to deal with this.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 25 Feb 2016 11:24:33 +1100

Hello Juergen and Paul,

Please see at end.

Regards, Christian

On 24/02/2016 8:26 AM, Paul Kyzivat wrote:
> ..snip..
[CNG] I don't see what the example buys? I don't see that the behaviour 
is any different between using additional attributes in the datachannel 
vs. the non data channel case. E.g. for

     c=IN IP4 10.10.10.1
     m=message 7394 TCP/MSRP *
     a=accept-types:message/cpim text/plain text/html
     a=lang:....
     a=framerate:...
The ignore behaviour would be the same.
In the above example the attributes are scoped by the m= line. In the 
data channel case the attributes are scoped by the relevant a=dcmap: line.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 16:38:56 -0500

> data channel case the attributes are scoped by the relevant a=dcmap: line.

My concern is that SDP has no notion of subprotocol, even though in 
practice it shows up lots of places. It only has a notion of the 
protocol field in the m-line. Beyond that a *convention* has developed 
to denote a layering within the protocol through use of "/". AFAIK this 
isn't formally written down anywhere.

So, in principle we could define an RTP sub-protocol for use over a data 
channel. And then we could talk about using the attributes that apply to 
RTP in dcsa for a channel using RTP. But note there is no formal 
definition of the *protocol*s where RTP attributes are relevant.

A lot of the very old stuff was just sloppy. To be fair, it was probably 
good enough for the cases in front of them at the time, and they weren't 
yet in a position to foresee how things would evolve. It is just another 
example of how old stuff rots and has to be refreshed from time to time.

But I don't think *this* draft is the place to fix it. So, in lieu of 
doing that I'm just looking for some way to clarify things.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 26 Feb 2016 10:09:36 +1100

Hello Paul,

How about an update to draft-ietf-mmusic-rfc4566bis clause 5.14 (or 
8.2.2)? This is the document that defines the PROTO field in the first 
place.

Regards, Christian

On 26/02/2016 8:38 AM, Paul Kyzivat wrote:
> to denote a layering within the protocol through use of "/". AFAIK 
> this isn't formally written down anywhere.
>
> So, in principle we could define an RTP sub-protocol for use over a 
> data channel. And then we could talk about using the attributes that 
> apply to RTP in dcsa for a channel using RTP. But note there is no 
> formal definition of the *protocol*s where RTP attributes are relevant.
>
> A lot of the very old stuff was just sloppy. To be fair, it was 
> probably good enough for the cases in front of them at the time, and 
> they weren't yet in a position to foresee how things would evolve. It 
> is just another example of how old stuff rots and has to be refreshed 
> from time to time.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2016 18:44:22 -0500

> 8.2.2)? This is the document that defines the PROTO field in the first

That would be good, and possible since the bis is still in progress.

The hard part is figuring out what it should say!

For instance, consider UDP/DTLS/SCTP:

what is the sub-protocol? Is it SCTP, or DTLS/SCTP? Or both? Is DTLS a 
sub-protocol?

And note that this is somewhat confusing, since in typical protocol 
stack diagrams the sub-protocol is at the *top* and is considered to run 
at a higher level in the "stack".

Of course this is all just a matter of definition. But I expect there 
might be a lot of opinions on it.

	Thanks,
	Paul

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 26 Feb 2016 15:17:49 +0100

Hello Paul, Christian,

Would propose to add following definition of term "subprotocol" to the terminology section 3 of the 
sdpneg draft:

       Data channel subprotocol: The application protocol which is
       transported over a single data channel.  Data channel subprotocol
       messages are sent as data channel payload over an established data
       channel.  If an SDP offer/answer exchange is used as specified in
       this document to negotiate the establishment of data channels,
       corresponding data channel properties, associated data channel
       subprotocols and data channel subprotocol properties, then the data
       channel subprotocols may be identified by the values of the
       "subprotocol" parameters of the SDP "a=dcmap" attributes as
       described in Section 5.1.1.5.  Within this document the term "data
       channel subprotocol" is often abbreviated as just "subprotocol".

This text could explicitly narrow down the notion of "subprotocol" within the data channel SDP 
offer/answer context and might especially be helpful distinguishing it from the usages of 
"subprotocol" in the Websocket RFC 6455 (where the term "subprotocol" was taken from, but where it 
does not seem to be formally defined). This text may certainly not be helpful in more general 
non-data channel contexts. But it might help to clarify that every occurrence of of the term 
"subprotocol" in the sdpneg draft refers to the application protocol which (typically but not 
necessarily) is identified via the a=dcmap's "subprotocol" parameter.

Would such an explicit definition be helpful from your point of view?

Thanks,
Juergen

On 25.02.2016 22:38, EXT Paul Kyzivat wrote:
> My concern is that SDP has no notion of subprotocol, even though in practice it shows up lots of 
> places. It only has a notion of the protocol field in the m-line. Beyond that a *convention* has 
> developed to denote a layering within the protocol through use of "/". AFAIK this isn't formally 
> written down anywhere.
>
> So, in principle we could define an RTP sub-protocol for use over a data channel. And then we 
> could talk about using the attributes that apply to RTP in dcsa for a channel using RTP. But note 
> there is no formal definition of the *protocol*s where RTP attributes are relevant.
>
> A lot of the very old stuff was just sloppy. To be fair, it was probably good enough for the cases 
> in front of them at the time, and they weren't yet in a position to foresee how things would 
> evolve. It is just another example of how old stuff rots and has to be refreshed from time to time.
>
> But I don't think *this* draft is the place to fix it. So, in lieu of doing that I'm just looking 
> for some way to clarify things.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 12:46:00 -0500

Hi,

On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote:
> Hello Paul, Christian,
>
> Would propose to add following definition of term "subprotocol" to the
> terminology section 3 of the sdpneg draft:
>
> This text could explicitly narrow down the notion of "subprotocol"
> within the data channel SDP offer/answer context and might especially be
> helpful distinguishing it from the usages of "subprotocol" in the
> Websocket RFC 6455 (where the term "subprotocol" was taken from, but
> where it does not seem to be formally defined). This text may certainly
> not be helpful in more general non-data channel contexts. But it might
> help to clarify that every occurrence of of the term "subprotocol" in
> the sdpneg draft refers to the application protocol which (typically but
> not necessarily) is identified via the a=dcmap's "subprotocol" parameter.
>

It might *help*, but it doesn't get at the main problem I see.

The question is how does this sub-protocol relate the the proto field 
used in m-lines? But not to the proto of the m-line for data channel. My 
point is that many sdp attributes were designed to be used with 
particular proto fields. For instance, with RTP/AVP, RTP/AVPF, 
TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, 
RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, 
DCCP/TLS/RTP/SAVPF, ...

In general they are described as being applicable to RTP. But what is 
RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a super-protocol 
(of AVP, AVPF, SAVP, SAVPF)?

If we wanted to define use of RTP over a data channel, what 
sub-protocol(s) would we have to define? I *think* we would have to 
define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted to 
support over a data channel.

And then how would we do it, and where would we specify which attributes 
could be used with dcsa? Would we have to update the documents that 
define those attributes?

ISTM there are similar (though not so complex) issues for pretty much 
any attribute that we might want to reuse over a data channel.

Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, 
RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the 
websocket/datachannel registry. And then that document might say that 
any sdp attribute designed to be used with protos */(each of these 
subprotocols) may also be used in dcsa for a channel using these protocols.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 29 Feb 2016 13:48:46 +1100

Hello Paul and Juergen,

On 27/02/2016 4:46 AM, Paul Kyzivat wrote:
> used in m-lines? But not to the proto of the m-line for data channel. 
> My point is that many sdp attributes were designed to be used with 
[CNG] Does sub-protocol have to relate to the proto field? The proto 
field in the case of WebRTC-datachannel is UDP/DTLS/SCTP. What ever is 
carried in the individual data channels is the sub-protocol. 
Draft-ietf-mmusic-data-channel-sdpneg is only considering this.

> RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a 
> super-protocol (of AVP, AVPF, SAVP, SAVPF)?
[CNG] I'm not sure it matters? If someone wants to run a particular RTP 
profile over a data channel then it is a sub-protocol of UDP/DTLS/SCTP. 
All the other above examples have already been defined so I don't see we 
gain anything by trying to label them as a sub-protocol etc.

> define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted 
> to support over a data channel.
[CNG] Yes I would agree.
>
> And then how would we do it, and where would we specify which 
> attributes could be used with dcsa? Would we have to update the 
> documents that define those attributes?
[CNG] I assume we'd follow the example of 
draft-ietf-mmusic-msrp-usage-data-channel. It discusses the use of 
existing attributes. I don't see that RTP would need to do anything 
different.

> any attribute that we might want to reuse over a data channel.
[CNG] Some will be complex, some will be a no brainer. What 
draft-ietf-mmusic-data-channel-sdpneg provides is a syntax for re-using 
attributes. It doesn't provide semantics for every attribute. 
Implementors need to understand that some attributes have been defined 
with a particular protocol stack in mind and that they the behaviour may 
need to be modified when using a data channel.
> subprotocols) may also be used in dcsa for a channel using these 
[CNG] Yes it "could" be, if someone actually wanted to carry RTP over a 
data channel. That would follow with what is being done for MSRP and 
BFCP. I don't see RTP as being any different.

---

From: "Schwarz, Albrecht (Nokia - DE)" <[email-masked]>
Date: Mon, 29 Feb 2016 08:45:58 +0000

There isn't any use case at all for RTP-over-DC, neither for RTP in general nor specific RTP profiles "RTP/<Profile(s)>".
Thus, I concur to Christian.
Regards,
Albrecht

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of EXT Christian Groves
Sent: Montag, 29. Februar 2016 03:49
To: [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Hello Paul and Juergen,

On 27/02/2016 4:46 AM, Paul Kyzivat wrote:
>> Would propose to add following definition of term "subprotocol" to 
>> the terminology section 3 of the sdpneg draft:
>>
>> within the data channel SDP offer/answer context and might especially 
>> be helpful distinguishing it from the usages of "subprotocol" in the 
>> where it does not seem to be formally defined). This text may 
>> certainly not be helpful in more general non-data channel contexts. 
>> But it might help to clarify that every occurrence of of the term 
>> "subprotocol" in the sdpneg draft refers to the application protocol 
>> which (typically but not necessarily) is identified via the a=dcmap's "subprotocol"
>> parameter.
>>
[CNG] Does sub-protocol have to relate to the proto field? The proto field in the case of WebRTC-datachannel is UDP/DTLS/SCTP. What ever is carried in the individual data channels is the sub-protocol. 
Draft-ietf-mmusic-data-channel-sdpneg is only considering this.

[CNG] Yes I would agree.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 10:16:13 -0500

Since I am the only one who thinks there is a problem I'm going to just 
stop talking about it. We can deal with the problem if/when it arises.

(I don't like leaving loose ends, but it isn't important enough to 
pursue here.)

	Thanks,
	Paul