[DNSOP] ALTSRV

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 07 November 2018 05:51 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3310112785F for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 21:51:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 3gmlgGGda9D0 for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 21:51:24 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id E5025127333 for <dnsop@ietf.org>; Tue, 6 Nov 2018 21:51:23 -0800 (PST)
Received: (qmail 59454 invoked from network); 7 Nov 2018 05:43:30 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 7 Nov 2018 05:43:30 -0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: dnsop@ietf.org
References: <201809211811.w8LIBdLA021837@atl4mhob20.registeredsite.com> <fdee6f3f-dd86-b482-5263-eb8e2a21bcb7@bellis.me.uk> <CAKC-DJi=Afer4uKprMf-uaNB07MVY-XJ+etocntY0BbU1bXYrg@mail.gmail.com> <CAHbrMsATrpdgP6PN2DSAjf+Nj7ZMywPu=FiGMzxjvoOm5ab2OA@mail.gmail.com> <F508AFA8-6611-4553-97AA-2A38A7F28691@isc.org>
Message-ID: <9136e27f-0dce-b655-a83e-5a414a0752d1@necom830.hpcl.titech.ac.jp>
Date: Wed, 07 Nov 2018 14:51:15 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <F508AFA8-6611-4553-97AA-2A38A7F28691@isc.org>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZlXLoE5A3-9hwNGg6Ay1zTzbrLQ>
Subject: [DNSOP] ALTSRV
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 05:51:26 -0000

I changed Subject.

Let me clarify confusions on SRV and ALTSRV.

On 2018/11/07 7:05, Mark Andrews wrote:

>> On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren <erik+ietf@nygren.org> wrote:
>> How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to >> make it more DNS-aligned (e.g. the name as a separate field in the>>  
record) not help here?

I'm afraid you (Erik) are not aware of the most important
changes of ALTSRV from SRV, which is necessary to make SRV
implementable on browsers.

One is that, instead of _<portname>, _<portnumber> is used. OW,
browsers need most recent /etc/services and we are still at
a loss if port numbers do not have IANA assigned names.

Another important change is removal of _<protocol> replaced
by _<scheme>. Browsers know <scheme>, but <protocol> may
be known only by add on modules for <scheme>.

They are good changes.

However,

>> It comes from the HTTP world and is aligned with the
>> existing AltSvc feature

that is a fatal mistake.

It MUST come from WWW, *NOT* HTTP, world.

What is necessary for browsers is translation mechanism of
URLs in general, which is *NOT* HTTP specific.

Thus, proposed features specific to HTTP/HTTPS should be
removed entirely.

> Wouldn’t be better to pre-parse the fields in the record?

Yes, of course.

 From URLs including <hostname>,

    <scheme>://[<userinfor>@]<hostname>[:<port>]<path>[?<query>]

_<port>._<scheme>.<hostname> NEWSRV <newhostname> <newport>

or, if optional <port> is not specified,

_<defaultport>._<scheme>.<hostname> NEWSRV <newhostname> <newport>

should be looked up and the original URLs should be rewritten as:

    <scheme>://[<userinfor>@]<newhostname>:<newport><path>[?<query>]

or, if <newport> is 0,

    <scheme>://[<userinfor>@]<newhostname><path>[?<query>]

That's all necessary.

As multiple (anycast) addresses (<hostname> may have multiple
addresses, which may be anycast ones) take care of load
distribution and fault tolerance, I don't think complications
by priority or weight necessary. As they are not very harmful,
they may be added, if someone insists, but, won't be used.

						Masataka Ohta