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+i...@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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
