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

Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> Tue, 23 February 2016 13:29 UTC

Return-Path: <juergen.stoetzer-bradler@nokia.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EFF1B2CCB for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 05:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.501
X-Spam-Level:
X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuMcJCGa72fZ for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 05:29:50 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDD81B2CC8 for <mmusic@ietf.org>; Tue, 23 Feb 2016 05:29:50 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 03445122E8A69 for <mmusic@ietf.org>; Tue, 23 Feb 2016 13:29:46 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1NDTmhX031354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Tue, 23 Feb 2016 13:29:48 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1NDTdTC017564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Tue, 23 Feb 2016 14:29:47 +0100
Received: from [149.204.68.190] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Feb 2016 14:29:43 +0100
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu>
From: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Message-ID: <56CC5EC6.2030402@alcatel-lucent.com>
Date: Tue, 23 Feb 2016 14:29:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C745EB.6060605@alum.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/omfgJ7uUGOXYZCF3hpO8GWcFnBU>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2016 13:29:54 -0000

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:
> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote:
>> 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.
>
> 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.

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


>
>     Thanks,
>     Paul
>
>> Thank you,
>> Juergen
>>
>>
>> On 16.02.2016 14:01, Juergen Stoetzer-Bradler wrote:
>>> 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:
>>>> 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
>>>>
>>>>> 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?
>>>>>>
>>>>>> 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:
>>>>>>> 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:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote:
>>>>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote:
>>>>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote:
>>>>>>>>>>>> Isn't this the approach we're taking today?
>>>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and
>>>>>>>>>>>> specific
>>>>>>>>>>>> drafts are used to describe protocols that use the mechanism
>>>>>>>>>>>> (i.e.
>>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel &
>>>>>>>>>>>> draft-ietf-clue-datachannel).
>>>>>>>>>>>
>>>>>>>>>>> It remains to be seen if that will be enough. E.g., there
>>>>>>>>>>> currently
>>>>>>>>>>> aren't any iana considerations in
>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel.
>>>>>>>>>>>
>>>>>>>>>>> Suppose I encounter some sdp that uses msrp over a data
>>>>>>>>>>> channel, but
>>>>>>>>>>> that usage is unknown to me. How do I find the spec (the
>>>>>>>>>>> reference to
>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that
>>>>>>>>>>> usage?
>>>>>>>>>>>
>>>>>>>>>>> I would like to think that the iana registries will allow me to
>>>>>>>>>>> trace
>>>>>>>>>>> back to the relevant specs.
>>>>>>>>>>>
>>>>>>>>>> No disagreement on that part, however having taken another look at
>>>>>>>>>> both
>>>>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with your
>>>>>>>>>> original request for all (existing and new) attributes to
>>>>>>>>>> specify how
>>>>>>>>>> they may or may not be used with the dcsa attribute defined by
>>>>>>>>>> sdpneg.
>>>>>>>>>>
>>>>>>>>>> As Christian noted, the sub-protocol specifics are defined in
>>>>>>>>>> individual
>>>>>>>>>> documents (like msrp-usage), which calls your the parameters that
>>>>>>>>>> are at
>>>>>>>>>> least needed to be supported for that usage. Taking MSRP as an
>>>>>>>>>> example,
>>>>>>>>>> why isn't that enough, and how do you see the resulting set of
>>>>>>>>>> attributes that may or may not be used with MSRP differ between
>>>>>>>>>> use
>>>>>>>>>> in a
>>>>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular
>>>>>>>>>> media
>>>>>>>>>> stream ?
>>>>>>>>>
>>>>>>>>> Based on this discussion, I conclude that it should be
>>>>>>>>> sufficient for
>>>>>>>>> this draft to say that before an attribute can be used with dcsa,
>>>>>>>>> such usage must be defined somewhere. This could be either:
>>>>>>>>> - as part of the definition of the attribute, OR
>>>>>>>>> - as part of the definition of the protocol referenced on the
>>>>>>>>> m-line.
>>>>>>>>>
>>>>>>>> We are getting closer, but it's still not obvious to me that you
>>>>>>>> cannot use an attribute with dcsa if it has not been explicitly
>>>>>>>> defined for the attribute in question. Clearly, there are attributes
>>>>>>>> that wouldn't make sense over data channels, just like there are
>>>>>>>> attributes that don't make sense over particular media descriptions.
>>>>>>>>
>>>>>>>> Again, I'd like to hear from more people on this, including the
>>>>>>>> authors.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -- Flemming
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>     Thanks,
>>>>>>>>>     Paul
>>>>>>>>>
>>>>>>>>>> Also, it would be good to hear from more people on this, including
>>>>>>>>>> the
>>>>>>>>>> document authors.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> -- Flemming
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Paul
>>>>>>>>>>>
>>>>>>>>>>>> Regards, Christian
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
>>>>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we
>>>>>>>>>>>>>> need to
>>>>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it
>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at this
>>>>>>>>>>>>>> point is
>>>>>>>>>>>>>> that there is indeed a need to explicitly speficy these
>>>>>>>>>>>>>> interactions as
>>>>>>>>>>>>>> opposed to relying on a more general algorithmic approach
>>>>>>>>>>>>>> (plus the
>>>>>>>>>>>>>> offerer being responsible for generating a valid offer if he
>>>>>>>>>>>>>> wants to
>>>>>>>>>>>>>> establish a data channel).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute
>>>>>>>>>>>>> pertains to
>>>>>>>>>>>>> need to be defined to work over data channels.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>     Paul
>>>>>>>>>>>>>