Re: [hybi] -09: abstract and introduction

Iñaki Baz Castillo <ibc@aliax.net> Thu, 16 June 2011 10:31 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695711E8106 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 03:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level:
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-1rp5KWbDTw for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 03:31:02 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6D811E80CD for <hybi@ietf.org>; Thu, 16 Jun 2011 03:31:01 -0700 (PDT)
Received: by qwc23 with SMTP id 23so966118qwc.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 03:31:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr539854qcq.230.1308220260729; Thu, 16 Jun 2011 03:31:00 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 03:31:00 -0700 (PDT)
In-Reply-To: <BANLkTinWNrjdA9sx3Kx7NX_h7OC8k0e_cg@mail.gmail.com>
References: <4DF91FCA.8060403@stpeter.im> <BANLkTinBEprfvY7oRu6_ZeiX4ei0rS5GjA@mail.gmail.com> <4DF93B86.7050704@stpeter.im> <BANLkTinWNrjdA9sx3Kx7NX_h7OC8k0e_cg@mail.gmail.com>
Date: Thu, 16 Jun 2011 12:31:00 +0200
Message-ID: <BANLkTinJJKgtq+pr3AuY90SfbhSVJSVbMQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2011 10:31:03 -0000

2011/6/16 Iñaki Baz Castillo <ibc@aliax.net>et>:
> You have not enough data. A WebSocket service is not just identified
> by a host and optional port, it also requires an URI schema (ws for
> plain TCP or wss for TLS over TCP). So you need a WebSocket URI (like
> "ws://1.2.3.4[:999]).
>
> In your example above, if you want to point a client to the WebSocket
> service at example.com, how do you know wheter to use TLS or not? you
> need to know the URI schema for that.
>
> Of course, in the case of using SRV records things change a bit (since
> the server IP and port) must be determined by performing SRV
> procedures and more than one valid destinations can be retrieved in
> the DNS response.


However there is a way, at least in SIP protocol, for the client to
discover which transport (UDP, TCP, TLS over TCP) to use when
contacting a server: using DNS NAPTR records (RFC 2915).

For example, a SIP client wants to contact the server with domain
oversip.net so it performs a NAPTR DNS query:

  $ host -t NAPTR oversip.net
  oversip.net has NAPTR record 10 50 "S" "SIP+D2U" "" _sip._udp.oversip.net.
  oversip.net has NAPTR record 40 50 "S" "SIP+D2S" "" _sip._sctp.oversip.net.
  oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" "" _sips._sctp.oversip.net.
  oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" "" _sips._tcp.oversip.net.
  oversip.net has NAPTR record 10 50 "S" "SIP+D2T" "" _sip._tcp.oversip.net.

If the SIP client just supports SIP over UDP, TCP and TLS, it would
just take DNS records with service "SIP+D2U", "SIP+D2T" and
"SIPS+D2T".
It would then choose the resource with best 'order' (in this case
"SIPS+D2T") and perform a DNS SRV query for  _sips._tcp.oversip.net,
retrieving various SRV records (each one with a domain for which DNS A
must be queried, and a port). Then the client should try the SRV
record with best priority (taking into account the 'weight' field if
more than one record with same 'priority') and connect via TCP to the
resulting IP and port.

I see that NAPTR records don't exist in XMPP, so given a domain how
does a client know wheter it must use TCP or TLS??


-- 
Iñaki Baz Castillo
<ibc@aliax.net>