Re: [rtcweb] URI schemes for TURN and STUN

"Dan Wing" <dwing@cisco.com> Fri, 04 November 2011 16:06 UTC

Return-Path: <dwing@cisco.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 1DD2C21F8CA1; Fri, 4 Nov 2011 09:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.578
X-Spam-Level:
X-Spam-Status: No, score=-105.578 tagged_above=-999 required=5 tests=[AWL=1.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 dewo4gp7akOA; Fri, 4 Nov 2011 09:06:19 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0F421F8C9E; Fri, 4 Nov 2011 09:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1860; q=dns/txt; s=iport; t=1320422779; x=1321632379; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9m+Vvi+nxuAvN6Wd+QzSkVe5onXVhRKd5pV73Wmdcuk=; b=ZGqrHYxB6kl/vM6ueQp83jvjLMpKP258aE6R55v16VQzLc9PbiVwbrJQ Oikmxc8fX46AFQrAl+Db3T6JVGHnDwrwtu3HxIaCojWaLyECINEOJ7TWh G0StqggpZ/4YhC9gFVB3989jOHK4R2tpXCBBYFqn1cUqfX7tC7T4wGQrE s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskAAE8NtE6rRDoJ/2dsb2JhbABEmhCBa4xogSCBBYFyAQEBBAEBAQUKARcQNAsMAQMCCQ4BAgQBAQEnBxkOFQoJCAEBBAESCxeHaJZ5AZ5ciSsEiAqeGA
X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12370910"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Nov 2011 16:06:07 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA4G67gs000440; Fri, 4 Nov 2011 16:06:07 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Eric Rescorla' <ekr@rtfm.com>, 'Ned Freed' <ned.freed@mrochek.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> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <CABcZeBPCGcUcEDNJ5T3+LowrdTz-NAka3Q33CA8mvdwb0=+aZg@mail.gmail.com>
In-Reply-To: <CABcZeBPCGcUcEDNJ5T3+LowrdTz-NAka3Q33CA8mvdwb0=+aZg@mail.gmail.com>
Date: Fri, 04 Nov 2011 09:06:07 -0700
Message-ID: <02a901cc9b0b$a9638940$fc2a9bc0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcybCmTMk2kTkttER/CHovfDIrg3zwAAQ4Zw
Content-Language: en-us
Cc: 'Behave WG' <behave@ietf.org>, 'Keith Moore' <moore@cs.utk.edu>, 'Keith Moore' <moore@network-heretics.com>, rtcweb@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: Fri, 04 Nov 2011 16:06:20 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Eric Rescorla
> Sent: Friday, November 04, 2011 8:56 AM
> To: Ned Freed
> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org
> Subject: Re: [rtcweb] URI schemes for TURN and STUN
> 
> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed <ned.freed@mrochek.com>
> wrote:
> >> Top-posting a general principle, detailed comment at the bottom....
> >
> >> For all URI schemes, I think the URI needs to contain all the
> >> information you need in order to make contact with the service; you
> >> can't negotiate until you've made contact.
> >> (the process may involve things like "resolve through a resolution
> >> mechanism like DNS" or "get authorization tokens from somewhere
> else").
> >
> >> In the case of TURN, you need to distinguish between TCP, UDP and
> TLS,
> >> and you need to make that determination before you send the first
> >> packet. That means the distinguishing information between those
> three
> >> things belongs in the URL; I don't think the scheme is a good place
> to
> >> encode it.
> >
> > I'm in complete agreement with Harald on all of these points. And
> while it
> > would have been nice if URL syntax was less messy and more general,
> making
> > it easier to do these sorts of things in a consistent way, it quite
> simply
> > isn't and we have to make do with what we have.
> 
> I don't have any commitment to the scheme. What's the best place?

http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05
uses "?transport=", for example:

  turn://example.com?transport=tcp
  turns://example.com?transport=udp

-d

> -Ekr
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb