IETF Logo Mail Archive

Re: [rtcweb] URI schemes for TURN and STUN

Keith Moore <moore@network-heretics.com> Tue, 01 November 2011 12:05 UTC

Return-Path: <moore@network-heretics.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 8C9A821F910E; Tue, 1 Nov 2011 05:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.829
X-Spam-Level:
X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg3HDksGjLcr; Tue, 1 Nov 2011 05:05:36 -0700 (PDT)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id D047921F8C84; Tue, 1 Nov 2011 05:05:36 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 242CA20CC1; Tue, 1 Nov 2011 08:05:30 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 01 Nov 2011 08:05:30 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=QJpD/cqe2AqoVU846CZIyKUtP9k=; b=Uk dZBL4I3mL3frA5NZ/uFeCQ9Bv2nIKSg5OHuUZd4B2mX0KcQEIVmY2Pquy9k7+xdQ WueYKPs6FKR5dchDQZaJOxCDqUaw5LZD8cBi7hZIyDRZeHd8XOXWJr8+gGj58LDx JeTiUlq6W4G45FgBJKPIaU4H5AE/wOpSxyuGP7qmM=
X-Sasl-enc: QunLAAOFjBxZ3TvGL/TWmzHDttDScq/4XPsDjY9Zbreq 1320149129
Received: from [10.59.1.8] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 634254834EC; Tue, 1 Nov 2011 08:05:29 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4EAF9391.5040209@it.aoyama.ac.jp>
Date: Tue, 01 Nov 2011 08:05:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com>
References: <4EAC6BF4.2000604@alvestrand.no> <CALiegf=f4kFzyDLWK+Y5vbuCEJFXX590+VuZ4bbnHZnvX0CoBA@mail.gmail.com> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:02 -0700
Cc: Ned Freed <ned.freed@mrochek.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Keith Moore <moore@cs.utk.edu>, Behave WG <behave@ietf.org>
Subject: Re: [rtcweb] URI schemes for TURN and STUN
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Nov 2011 12:05:37 -0000

>> The "s" convention was a hack to distinguish "x over SSL" from "x" for all of the URIs that existed before SSL was well-established, because those protocols didn't (then) have a way to negotiate security in-band.   It made sense as a short term hack,
> 
> Yes. It also makes sense in current-day operation.
> 
>> but not as an architectural feature.   It's not something that we want to propagate to new URI types, neither in the form of an "s" suffix, nor as any other syntactic convention.
> 
> In most cases probably not. But there may be cases similar to HTTP/S where it makes sense. Each case has to be analyzed independently.

agree.  I just don't think it's a good idea to establish a new _convention_.

regards,

Keith

v2.23.0 | Report a Bug | By Email