Re: [rtcweb] Transports: RFC 6062 support

Harald Alvestrand <harald@alvestrand.no> Tue, 11 March 2014 21:39 UTC

Return-Path: <harald@alvestrand.no>
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 94BA91A0804 for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 14:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 nE92lBKNHKel for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 14:39:23 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C3D3D1A063F for <rtcweb@ietf.org>; Tue, 11 Mar 2014 14:39:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9DC937C4F9F; Tue, 11 Mar 2014 22:39:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sojtsYdX0Dxd; Tue, 11 Mar 2014 22:39:16 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:ecf9:76b8:78ea:f58b] (unknown [IPv6:2001:470:de0a:27:ecf9:76b8:78ea:f58b]) by mork.alvestrand.no (Postfix) with ESMTPSA id E15FA7C4F93; Tue, 11 Mar 2014 22:39:15 +0100 (CET)
Message-ID: <531F8283.7000604@alvestrand.no>
Date: Tue, 11 Mar 2014 22:39:15 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <53183BBB.3040409@viagenie.ca> <CAOJ7v-1ZN=N5w3hFRkrC+LzarGFnt0qimcJbkTxWy6z0vWZFDg@mail.gmail.com> <531874A4.6010908@viagenie.ca> <CAOJ7v-3xasrFG5WVXPd_hA0=OoxvKbAhL2V4erYt7-kGt_JrtA@mail.gmail.com> <53187960.2010709@viagenie.ca> <531DDB5A.4060201@ericsson.com> <CAOW+2dtmLUWO-fKtNMMxn4ozywY2-dM3X0kEYwipRb9LcHgxQw@mail.gmail.com> <531F6B6E.6070609@alvestrand.no> <u5suh9p6srq201drs3r59fuagp5qbhbkdm@hive.bjoern.hoehrmann.de> <531F7812.4030505@alvestrand.no> <cfvuh9pbtdjo1lts32nlramj6436h7fv4g@hive.bjoern.hoehrmann.de>
In-Reply-To: <cfvuh9pbtdjo1lts32nlramj6436h7fv4g@hive.bjoern.hoehrmann.de>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZUoRVxMcLmCnhm76pf3qX7eXtXQ
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Transports: RFC 6062 support
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: Tue, 11 Mar 2014 21:39:26 -0000

On 03/11/2014 10:23 PM, Bjoern Hoehrmann wrote:
> * Harald Alvestrand wrote:
>> On 03/11/2014 09:26 PM, Bjoern Hoehrmann wrote:
>>> * Harald Alvestrand wrote:
>>>> In RFC 2119 theory, MAY and not mentioning it at all have exactly the 
>>>> same weight.
>>> (That depends on whether the default is "allowed" or "prohibited" and
>>> there are plenty of specifications where explicit MAY overrides a de-
>>> fault of "prohibited".)
>> Probably true. But I can't think of any at the moment - do you have
>> something specific in mind?
> (A typical example is when RFC 2119 keywords are used to describe how a
> protocol element is constructed, say, "<foo> elements MAY carry bar=''
> attributes"; you wouldn't assume you can use <foo bar=''> without that.)
Any specific examples?

Without context, this seems a strange way to specify protocol elements;
more common is to use ABNF, and not 2119 keywords.

And ABNF even allows "free" extensibility by having other specs use the
/= operator....


-- 
Surveillance is pervasive. Go Dark.