Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN

Marc Petit-Huguenin <petithug@acm.org> Fri, 04 November 2011 16:49 UTC

Return-Path: <petithug@acm.org>
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 DC74A11E8082; Fri, 4 Nov 2011 09:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.706
X-Spam-Level:
X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 C5WgsAgstQpQ; Fri, 4 Nov 2011 09:49:37 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DD34111E8081; Fri, 4 Nov 2011 09:49:36 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A19BD20595; Fri, 4 Nov 2011 16:40:35 +0000 (UTC)
Message-ID: <4EB4179C.9050703@acm.org>
Date: Fri, 04 Nov 2011 09:49:32 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.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> <02a901cc9b0b$a9638940$fc2a9bc0$@com> <4EB41016.7080205@acm.org> <02be01cc9b10$6816f9e0$3844eda0$@com>
In-Reply-To: <02be01cc9b10$6816f9e0$3844eda0$@com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: 'Behave WG' <behave@ietf.org>, 'Keith Moore' <moore@network-heretics.com>, 'Keith Moore' <moore@cs.utk.edu>, 'Ned Freed' <ned.freed@mrochek.com>, rtcweb@ietf.org
Subject: Re: [rtcweb] [BEHAVE] 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:49:38 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2011 09:40 AM, Dan Wing wrote:
>> -----Original Message-----
>> From: Marc Petit-Huguenin [mailto:petithug@acm.org]
>> Sent: Friday, November 04, 2011 9:17 AM
>> To: Dan Wing
>> Cc: 'Eric Rescorla'; 'Ned Freed'; 'Behave WG'; 'Keith Moore'; 'Keith
>> Moore'; rtcweb@ietf.org
>> Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
>>
> On 11/04/2011 09:06 AM, Dan Wing wrote:
>>>>> -----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
> 
> The document uses opaque URI (there was a long discussion at the time
> about
> this), so it is in fact:
> 
> turn:example.com?transport=tcp
> turns:example.com?transport=udp
> 
>> Thanks for the correction.
> 
>> (some examples in the I-D would be useful, to avoid mistakes like mine.)

Will do.  Thanks.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk60F5oACgkQ9RoMZyVa61ccqQCePrkokWQlZIpgRImOVnUngs9Q
w34An2U9EgwpFclj98m6MJl68GAkziIz
=qrda
-----END PGP SIGNATURE-----