IETF Logo Mail Archive

Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description)

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Wed, 27 August 2014 21:22 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623961A0141 for <rtcweb@ietfa.amsl.com>; Wed, 27 Aug 2014 14:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 asfF-1JIPnQ0 for <rtcweb@ietfa.amsl.com>; Wed, 27 Aug 2014 14:22:28 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 C54531A0704 for <rtcweb@ietf.org>; Wed, 27 Aug 2014 14:22:27 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTPS for <rtcweb@ietf.org>; Wed, 27 Aug 2014 23:22:23 +0200 (CEST)
Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 3D1AE3A1F4 for <rtcweb@ietf.org>; Wed, 27 Aug 2014 23:22:13 +0200 (CEST)
Message-ID: <53FE4C08.5050605@omnitor.se>
Date: Wed, 27 Aug 2014 23:22:16 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <CABkgnnW05HW2kdEH49GfSTe1unCeqKUWguUqd29iMjOc1z5BAg@mail.gmail.com> <53FDBE22.8080609@alvestrand.no> <E1FE4C082A89A246A11D7F32A95A17828E536C68@US70UWXCHMBA02.zam.alcatel-lucent.com> <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de>
In-Reply-To: <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de>
Content-Type: multipart/alternative; boundary="------------080705080602010203080600"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yATaZVoUWLfYEhrg7gSVTWUwJ7Y
Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 27 Aug 2014 21:22:30 -0000

There is an ambition to be as close as possible to Websocket.
Websocket is specified in RFC 6455.
It has an negotiation mechanism for extensions.  See chapter 9
And it closes channels in case of reception tht is not according to the 
protocol. ( e.g. Section 10.7 )

So, it could be wise to copy that behavior, to maintain the ambitions of 
keeping these data channel types similar.

/Gunnar

------------------------------------------------------------------------
On 2014-08-27 14:52, Michael Tuexen wrote:
> On 27 Aug 2014, at 13:38, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>
>>> If there is negotiation, there is no problem.
>>>
>>> If there is no negotiation, starting to use the new feature will either
>>> lead to ignored messages or lead to a crashed connection.
>>>
>>> Ignored messages are not a problem if they form part of an ignorable
>>> extension (for instance if someone decided to once in a while send
>>> checksums over all the data sent so far - doesn't matter to those that
>>> don't understand it, since it doesn't carry any extra data).
>>>
>>> Crashed connections are usually a problem, so that will mean "no
>>> unnegotiated extensions, ever".
>>>
>>> I'm happy with either way of doing it, as long as we're explicit about it.
>> <Raju>
>> +1 for negotiation.
>> I think it is highly preferred to negotiate these additional PPIDs in all cases as
>> anything other than a binary or text  PPID is additional capability. Use of any additional
>> capabilities must at least be negotiated using JSEP.
>> One element of negotiation could be "what must be done for unrecognized PPIDs?": ignore them or
>> abort the connection.
> Do we really need to negotiate that? The consensus up to now was to close the channel.
> So if you negotiate the PPIDs and honor the result, you will never run into this issue...
>
> Best regards
> Michael
>> </Raju>
>>
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email