IETF Logo Mail Archive

Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive?

Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> Wed, 09 March 2016 14:55 UTC

Return-Path: <juergen.stoetzer-bradler@nokia.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBCB12D736 for <rtcweb@ietfa.amsl.com>; Wed, 9 Mar 2016 06:55:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9JFAJ_XGKoa for <rtcweb@ietfa.amsl.com>; Wed, 9 Mar 2016 06:55:25 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 D7C4812D52E for <rtcweb@ietf.org>; Wed, 9 Mar 2016 06:52:13 -0800 (PST)
Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 60E3E4B6C7DF1; Wed, 9 Mar 2016 14:52:09 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u29EqBex006169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2016 14:52:12 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u29EpraF012039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Mar 2016 15:52:11 +0100
Received: from [149.204.68.190] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 9 Mar 2016 15:50:26 +0100
To: EXT Tim Panton <tim@phonefromhere.com>
References: <56DEC8F5.4070101@alcatel-lucent.com> <B1B57A41-654E-48AF-BE9A-94D66CC70BA3@phonefromhere.com>
From: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>
Message-ID: <56E03831.7080507@alcatel-lucent.com>
Date: Wed, 09 Mar 2016 15:50:25 +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: <B1B57A41-654E-48AF-BE9A-94D66CC70BA3@phonefromhere.com>
Content-Type: multipart/alternative; boundary="------------080606000608080509000704"
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/A4G1wkaYL-hamMyu8R4hcUkoVn4>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2016 14:55:27 -0000

Tim,

Thanks for feedback.
The SDP offer/answer extensions described in draft-ietf-mmusic-data-channel-sdpneg could be used if 
subprotocol related properties need to be negotiated, which go beyond the pure signaling of the 
subprotocol identifier. If no subprotocol properties need to be negotiated, then usage of DCEP may 
indeed be sufficient.
I mentioned this draft as I think that the case related processing of data channel subprotocol ids 
should be the same for SDP offer/answer based data channel subprotocol negotiation as for DCEP based 
data channel subprotocol negotiation.

Thanks,
Juergen


On 09.03.2016 13:12, EXT Tim Panton wrote:
>
>> On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com 
>> <mailto:juergen.stoetzer-bradler@nokia.com>> wrote:
>>
>> Hello,
>>
>> If a WebRTC endpoint uses the data channel establishment protocol in order to open a data 
>> channel, it may add a non-empty protocol identifier to the DATA_CHANNEL_OPEN message. Is the 
>> endpoint, which receives this DATA_CHANNEL_OPEN message, assumed to process this protocol id 
>> string in a case sensitive or case insensitive way? Or would that actually be up to the receiving 
>> WebRTC endpoint's implementation?
>
> Since the sub-protocol definition in websockets seems to be non-normative, this feels like a 
> matter we can leave to post 1.0 .
>
>>
>> As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify this.
>>
>> Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol identifiers are 
>> signaled as part of an SDP attribute and where it is not yet clarified if these identifiers are 
>> assumed to be case sensitive or case insensitive.
>
> I’m not sure I understand the point of draft-ietf-mmusic-data-channel-sdpneg -
> I think the new data contained in the ‘offer’ SDP is exactly that in the DCEP Open - and the
> ‘answer' contains nothing other than an ACK or NACK of that offer?
> That being the case, why doesn’t the offer side just open a DataChannel with the
> required parameters and see if it gets ACK or reset back  - no additional SDP needed ?
>
> Tim.
>
>>
>> Thanks,
>> Juergen
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>

v2.23.0 | Report a Bug | By Email