Hi,
I believe that almost everything Roy says below is non-controversial; if
we can tune the language to be less offensive it might fit well into the
Introduction (and not require an IESG Note to get into the document).
Best regards, Julian
On 2011-09-01 21:55, Roy T. Fielding wrote:
I
On 2011-09-03 12:54, Julian Reschke wrote:
Hi,
I believe that almost everything Roy says below is non-controversial; if
we can tune the language to be less offensive it might fit well into the
Introduction (and not require an IESG Note to get into the document).
Best regards, Julian
...
Like
Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do
handshaking and authentication to even allow it in the first so? If
so, whose network management constraint is it bypassing?
Roy T. Fielding wrote:
I sent this originally in March, before the last call, but I see
that it
2011/9/2 Hector sant9...@gmail.com:
Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do
handshaking and authentication to even allow it in the first so? If so,
whose network management constraint is it bypassing?
I suppose Roy talks about company firewalls or HTTP proxies
I sent this originally in March, before the last call, but I see
that it still applies for draft-ietf-hybi-thewebsocketprotocol-13.
If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please
add an IESG note to the effect of:
=
The WebSocket protocol is designed with an assumption
On Wed, Jul 27, 2011 at 06:07:12PM +0100, Dave Cridland wrote:
On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote:
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
SRV provides load-balancing and failover. I never said that SRV
is a
solution for temporaly put in maintenance a
On Wed Jul 27 02:28:06 2011, Mark Andrews wrote:
Billions of dollars have been wasted globally for the sake of a few
hours
work by webbrowser vendors.
Seems to be a recurring theme - browsers could have easily performed
probe tests to check for vulnerable proxies and disabled WebSockets
Hi Iñaki,
On Tue, Jul 26, 2011 at 11:58:41AM +0200, Iñaki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
To ensure nobody gets me wrong, I'm certain this can help solve issues
*if this is optional*. If it becomes a MUST, then the negative effects
will override the positive ones.
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
SRV provides load-balancing and failover. I never said that SRV is a
solution for temporaly put in maintenance a server.
Happy eyeballs however does allow you to take a server out of production
and not really notice it. Note
2011/7/26 Willy Tarreau w...@1wt.eu:
if you want to have any chance of making SRV *usable* with WS (or
HTTP), you have to motivate both sides by showing them that :
- it's better for them to use it than not to use it (both servers and
browsers)
- the additional cost of using it is
On Wed, Jul 27, 2011 at 11:43:58AM +0200, Iñaki Baz Castillo wrote:
2011/7/26 Willy Tarreau w...@1wt.eu:
if you want to have any chance of making SRV *usable* with WS (or
HTTP), you have to motivate both sides by showing them that :
- it's better for them to use it than not to use it (both
2011/7/27 Willy Tarreau w...@1wt.eu:
That's where I think you're mistaken. As long as you think of it as mandatory
this will not be possible.
Hi Willy, as I've explained several times in these threads, if a WS
client is not mandated to perform SRV given a WS URI domain, then the
service
On Wed, Jul 27, 2011 at 12:46:28PM +0200, Iñaki Baz Castillo wrote:
Hi Willy, as I've explained several times in these threads, if a WS
client is not mandated to perform SRV given a WS URI domain, then the
service provider cannot rely on SRV records. This is, let's assume
that a WS service
2011/7/27 Willy Tarreau w...@1wt.eu:
Once again, the goal to make SRV adopted BY USERS is not to ensure that
it tries to cover all the server-side needs, but that it offers better
quality of service to USERS. That way USERS will massively adopt it and
server will one day be able to safely rely
On Wed, Jul 27, 2011 at 03:45:38PM +0200, Iñaki Baz Castillo wrote:
2011/7/27 Willy Tarreau w...@1wt.eu:
Once again, the goal to make SRV adopted BY USERS is not to ensure that
it tries to cover all the server-side needs, but that it offers better
quality of service to USERS. That way USERS
2011/7/27 Willy Tarreau w...@1wt.eu:
I don't think home users (neither professional users) has nothing to
decide here, they will not resolve the WS URI retrieved from a
webpage.
I think you're wrong. Those are these users which ask for feature XXX or
YYY that they like because it brings them
On Wed, Jul 27, 2011 at 05:19:30PM +0200, Iñaki Baz Castillo wrote:
Well, I understand (and agree) most of your text, but I still think
that the URI resolution mechanism is something transparent for an
end-user. This is not like having FlashPlayer for showing annoying and
dancing menus in a
On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote:
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
SRV provides load-balancing and failover. I never said that SRV
is a
solution for temporaly put in maintenance a server.
Happy eyeballs however does allow you to take a server
In message 9031.1311786432.357811@puncture, Dave Cridland writes:
On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote:
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
SRV provides load-balancing and failover. I never said that SRV
is a
solution for temporaly put in
2011/7/24 Willy Tarreau w...@1wt.eu:
Ok, but what would be the failover solution then? any failover
solution can take some time until redirects the client's request to a
working server, it's not just a client problem.
This is already addressed by existing web architectures. DNS provides
2011/7/24 Willy Tarreau w...@1wt.eu:
To ensure nobody gets me wrong, I'm certain this can help solve issues
*if this is optional*. If it becomes a MUST, then the negative effects
will override the positive ones. In my opinion, the client should decide
whether to enable it or not.
But I don't
2011/7/25 Keith Moore mo...@network-heretics.com:
By now, I think the market has long since decided. For better or worse, the
mechanism the market chose to use with the web was HTTP redirects.
That's common in HTTP world: too much cool stuff on top of it, and
too much noise and hacks below it.
2011/7/25 Mark Andrews ma...@isc.org:
But if you really want to use DNS to do redirects for http: URIs (or for =
that matter ws: URIs or almost any other kind of URI), NAPTR was =
tailor-made to do that. SRV was not.
_http._tcp.example.com SRV 100 0 80 server is not a redirect.
The http
In message CALiegf=e48kkf+gky1my7lippub-0kzdgsgzrjxk1azupag...@mail.gmail.com
, =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= writes:
2011/7/24 Willy Tarreau w...@1wt.eu:
Ok, but what would be the failover solution then? any failover
solution can take some time until redirects the client's request to
On Sun, Jul 24, 2011 at 8:46 PM, Mark Andrews ma...@isc.org wrote:
Adding a SRV lookup should add 0ms if it isn't there as you should be
making A, and SRV lookups in parallel. Non-existance is as
cachable as existance is.
But you have to wait until the SRV returns even if the A/
On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote:
Adding a SRV lookup should add 0ms if it isn't there as you should be
making A, and SRV lookups in parallel.
This does not work for a simple reason : you have to perform the lookups
on the SRV response just as you would do with
On Mon, Jul 25, 2011 at 02:50:37PM +1000, Mark Andrews wrote:
In message 20110725042921.gj22...@1wt.eu, Willy Tarreau writes:
On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote:
Adding a SRV lookup should add 0ms if it isn't there as you should be
making A, and SRV
On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote:
[I haven't been following hybi and haven't read the draft, but as this is
posted to the ietf list and there are a bunch of assertions here about the
DNS I consider ... odd, I thought I'd chime in]
On Jul 24, 2011, at 8:59 AM,
On Mon, Jul 25, 2011 at 11:12:46AM +1000, Mark Andrews wrote:
But, do current webbrosers resolve names using anything but DNS A?
(well, I know that they use /etc/hosts). Anyhow, WINS / NIS /etc/hosts
and such stuff just maps a hostname into a single IP. It's the
equivalent of a DNS A
In message 20110725045821.gn22...@1wt.eu, Willy Tarreau writes:
On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote:
[I haven't been following hybi and haven't read the draft, but as
this is posted to the ietf list and there are a bunch of assertions
here about the DNS I consider
Willy Tarreau wrote:
What are you saying ? Your browser embeds the resolved as a library, so when
I'm saying that the browser has to retry, I mean the resolver part of the
browser has to retry.
You should mean that the browser can control behavior of the
resolver.
If the resolver in the
In message b2c17b21-ea8a-4698-8c41-f55a9aa14...@gbiv.com, Roy T. Fielding
writes:
On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote:
2011/7/21 Dave Cridland d...@cridland.net:
It's proven impossible, despite effort, to retrofit SRV onto HTTP; there=
is
no way it'll be possible
On Fri Jul 22 06:43:45 2011, Willy Tarreau wrote:
Iñaki, what we're saying is that the resolving applies first to HTTP
well before it is WS. For instance, a client could connect to an
HTTP
server, fetch a few objects, then decide to upgrade the connection
to
switch to WebSocket. DNS
Dave Cridland wrote:
On Thu Jul 21 18:18:31 2011, David Endicott wrote:
It is my opinion that name resolution (however done) is outside the
purview
of WS. It may be handled in any number of ways by the client, and must
happen *before* WS establishes it's TCP connection and begins
Masataka Ohta wrote:
Dave Cridland wrote:
Where is a proof?
Sorry, I've a habit of using the word proof in the English
1) There are no SRV records.
2) Therefore browsers do not support them.
3) Therefore you'd need to allow for A-lookup as fallback for the
forseeable future.
4) Therefore
On Jul 24, 2011, at 4:42 AM, Iñaki Baz Castillo wrote:
2011/7/23 Roy T. Fielding field...@gbiv.com:
Right. If WS borns with no SRV (as a MUST for WS clients) then just
forget it and let inherit all the ugly limitations from HTTP protocol.
I am tired of this. SRV is not used for HTTP
On Jul 24, 2011, at 12:33 AM, Mark Andrews wrote:
In message b2c17b21-ea8a-4698-8c41-f55a9aa14...@gbiv.com, Roy T. Fielding
writes:
On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote:
2011/7/21 Dave Cridland d...@cridland.net:
It's proven impossible, despite effort, to retrofit SRV
* Iñaki Baz Castillo wrote:
Open the fastest web page and tell me how long it takes.
Too long.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
On Sun Jul 24 19:59:49 2011, Willy Tarreau wrote:
On Sun, Jul 24, 2011 at 08:30:11PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 John Tamplin j...@google.com:
~100 ms (if the DNS server is not local and there is no DNS
cache for
the given domain). And just during the WS connection, no
[ should we leave ietf@ietf.org in CC or not ? I'm suspecting that people
who read this address will quickly get bored by hybi traffic ]
On Sun, Jul 24, 2011 at 10:35:45AM +0100, Dave Cridland wrote:
You're saying that you have a nebulous connection thing, that you
pump HTTP requests down,
Hi Mark,
On Sun, Jul 24, 2011 at 05:33:23PM +1000, Mark Andrews wrote:
In message b2c17b21-ea8a-4698-8c41-f55a9aa14...@gbiv.com, Roy T. Fielding
writes:
On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote:
2011/7/21 Dave Cridland d...@cridland.net:
It's proven impossible,
On Sun, Jul 24, 2011 at 01:26:53PM +0200, Iñaki Baz Castillo wrote:
2011/7/22 Willy Tarreau w...@1wt.eu:
Iñaki, what we're saying is that the resolving applies first to HTTP
well before it is WS. For instance, a client could connect to an HTTP
server, fetch a few objects, then decide to
On Sun, Jul 24, 2011 at 01:47:36PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
No I'm not saying that because I don't understand what you mean here.
What I'm saying is that browsers try to reuse existing connections to
host:port. So if you want to connect to
On Sun, Jul 24, 2011 at 01:42:26PM +0200, Iñaki Baz Castillo wrote:
2011/7/23 Roy T. Fielding field...@gbiv.com:
Right. If WS borns with no SRV (as a MUST for WS clients) then just
forget it and let inherit all the ugly limitations from HTTP protocol.
I am tired of this. SRV is not used
On Sun, Jul 24, 2011 at 7:11 AM, Iñaki Baz Castillo i...@aliax.net wrote:
2011/7/22 David Endicott dendic...@gmail.com:
The technological advantages are worthy, when it's used, but when it
doesn't
come into play, there are added inefficiencies.
~100 ms (if the DNS server is not local and
On Sun, Jul 24, 2011 at 08:25:05PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
Making an additional DNS request and a connection come with a cost.
http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02#section-5.2
You still need the DNS request : the client
On Sun, Jul 24, 2011 at 08:24:25PM +0200, Iñaki Baz Castillo wrote:
Yes it has. Either you open a fresh new connection, or you reuse an
idle existing one.
If the WS URI points to a different server, it's perfectly possible
that the WS connection has nothing to do (neither cookies usage)
On Sun, Jul 24, 2011 at 08:28:49PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
And I'm really tired of hearing the argument of the latency which
nobody demostrates (but just talks about it without replying me how
the same is not a problem in realtime protocols like
On Sun, Jul 24, 2011 at 08:30:11PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 John Tamplin j...@google.com:
~100 ms (if the DNS server is not local and there is no DNS cache for
the given domain). And just during the WS connection, no more. Taking
into account that a WS will be *usually*
On Sun, Jul 24, 2011 at 08:52:32PM +0200, Iñaki Baz Castillo wrote:
Ok. But I don't see the problem. What about Google Apps? My own domain
uses Gtalk and Gmail by setting Google XMPP SRV and MX records. Now
imagine that I would host my personal webpage (domain www.aliax.net)
in Google,
On Sun, Jul 24, 2011 at 08:57:45PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
Also, if the user realizes that the connection takes too much time and
presses F5 to reload the page, why couldn't the webbrowser cache the
SRV results and mark the previous attemp as
On Sun, Jul 24, 2011 at 09:02:59PM +0200, Iñaki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
But that's not what I meant, I meant that DNS is not the only solution
to resolve host names. WINS, NIS and /etc/hosts are usable too. When I
was a student in 94, we had all our
On Sun, Jul 24, 2011 at 09:18:40PM +0100, Dave Cridland wrote:
Open the fastest web page and tell me how long it takes. Probably
you
have performed a DNS A query. I don't think that a xtra DNS query
would be the bottleneck, never.
On lossy networks such as 3G, they definitely are. A
Hector Santos wrote:
A Major Application will offer all services necessary for the customer
to leverage. They are not going to eliminate ftp just because the
developer likes http better or whats customers to switch to http. Even
then, where I have seen a history of people using a http
Willy Tarreau wrote:
Ok, but I don't consider a xtra DNS query to be so hard.
I had to perform sites analysis for a customer a few months ago. Many
web pages nowadays have between 100 and 200 objects to fetch, spread
over up to 25-30 host names.
How long does it take to fetch all the
Willy Tarreau wrote:
On lossy networks such as 3G, they definitely are. A lost UDP packet is
not retransmitted nor signaled as lost, so the browser has to retry. However,
once the connection is established to the server, most losses are more or
less smoothed by TCP extensions such as SACK. So
Willy Tarreau wrote:
But we have to keep in mind that for SRV to work, it cannot be made
mandatory because existing infrastructure simply does not support it.
Such argument is valid at the IP, the infrastructure, layer where
IPv6 is to work but is not applicable at the application layer
where
In message 20110724183343.gy22...@1wt.eu, Willy Tarreau writes:
On Sun, Jul 24, 2011 at 08:25:05PM +0200, I=F1aki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
Making an additional DNS request and a connection come with a cost.
In message 20110724193230.ge22...@1wt.eu, Willy Tarreau writes:
On Sun, Jul 24, 2011 at 09:02:59PM +0200, I=F1aki Baz Castillo wrote:
2011/7/24 Willy Tarreau w...@1wt.eu:
But that's not what I meant, I meant that DNS is not the only solution
to resolve host names. WINS, NIS and
[I haven't been following hybi and haven't read the draft, but as this is
posted to the ietf list and there are a bunch of assertions here about the DNS
I consider ... odd, I thought I'd chime in]
On Jul 24, 2011, at 8:59 AM, Willy Tarreau wrote:
A lost UDP packet is not retransmitted nor
On Jul 24, 2011, at 3:33 AM, Mark Andrews wrote:
How do you solve the problem of hosting just http://example.com/;
on s1.joes-web-service.com and not redirect everything else at
example.com? People have been complaining about this for about as
long as the web has existed.
Well, in a way,
In message CABLsOLD-KM6DnR8HvfGH8N1M=1bz4z8zus0ydczaxsfocbq...@mail.gmail.com
, John Tamplin writes:
On Sun, Jul 24, 2011 at 8:46 PM, Mark Andrews ma...@isc.org wrote:
Adding a SRV lookup should add 0ms if it isn't there as you should be
making A, and SRV lookups in parallel.
In message 4b3c19fd-b736-4da7-9db5-3d433320d...@network-heretics.com, Keith M
oore writes:
On Jul 24, 2011, at 3:33 AM, Mark Andrews wrote:
How do you solve the problem of hosting just http://example.com/;
on s1.joes-web-service.com and not redirect everything else at
example.com?
On Jul 24, 2011, at 11:21 PM, Mark Andrews wrote:
How do you solve the problem of hosting just http://example.com/;
on s1.joes-web-service.com and not redirect everything else at
example.com? People have been complaining about this for about as
long as the web has existed.
Well, in a way,
In message 3bc48562-6459-4fb9-9806-731af87fe...@network-heretics.com, Keith M
oore writes:
On Jul 24, 2011, at 11:21 PM, Mark Andrews wrote:
How do you solve the problem of hosting just http://example.com/;
on s1.joes-web-service.com and not redirect everything else at
example.com?
In message 20110725042921.gj22...@1wt.eu, Willy Tarreau writes:
On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote:
Adding a SRV lookup should add 0ms if it isn't there as you should be
making A, and SRV lookups in parallel.
This does not work for a simple reason : you have
On Thu, Jul 21, 2011 at 9:57 PM, David Endicott dendic...@gmail.com wrote:
I have no idea what you might mean by highly dynamic host environment in
this context, but XMPP servers are normally found at the same location
consistently. However, it is *not* always (or typically) the same location
I think there is some misunderstanding as to what is being proposed, at
least as I understand it. Iñaki, please correct me if I am wrong.
You are right that it would be impossible to require all environments
that wanted to add Websockets support, whether client or server, to
change their DNS
Hi Dave,
On Thu, Jul 21, 2011 at 10:52:07PM +0100, Dave Cridland wrote:
On Thu Jul 21 18:33:38 2011, Willy Tarreau wrote:
If someone were to develop a backup/restore solution based on WS,
it would
be funny to discover that it cannot be used to restore the DNS
server when
this one
2011/7/21 David Endicott dendic...@gmail.com:
Yes, those are all excellent reasons to use DNS SRV. None of them are a
reason to mandate that WS require it. Because something is good for some
(or many) use cases, does not mean it is appropriate for everything and
certainly is not a reason
2011/7/22 Bruce Atherton br...@callenish.com:
You are right that it would be impossible to require all environments that
wanted to add Websockets support, whether client or server, to change their
DNS to have NAPTR and SRV records. After all, Websockets is intended to
integrate easily into the
2011/7/21 David Endicott dendic...@gmail.com:
Do they? A http uri and a ws uri have the same host/path construction.
It's really only the scheme that differs - and that identifies the
transport protocol to be used. Resolution of host name/addresses and
mapping of paths should be
2011/7/22 Willy Tarreau w...@1wt.eu:
You couldn't make DNS SRV mandatory for WS when WS starts with a protocol
upgrade from HTTP which does not mandate use of DNS SRV : the DNS resolving
had to be performed by the HTTP chain well before the connection gets
upgraded to WS. If any existing HTTP
On 21/07/2011 3:21 PM, Dave Cridland wrote:
SRV lookup is pretty commonplace now in libraries. XMPP and SIP
clients have no difficulty finding this functionality in a wide
variety of environments. For the web, where there are substantially
fewer web browsers than there are XMPP clients, I
: Server-Initiated HTTP; IETF-Discussion
Subject: Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt
(The
WebSocket protocol) to Proposed Standard
On 21/07/2011 3:21 PM, Dave Cridland wrote:
SRV lookup is pretty commonplace now in libraries. XMPP and SIP
clients have
On Thu, Jul 21, 2011 at 7:47 PM, Bruce Atherton br...@callenish.com wrote:
As I understand it, the issue that caused the various drafts for HTTP SRV
to die without getting much traction is one of efficiency. It is inefficient
to make all these extra DNS calls, especially when it is unlikely
On Thu, Jul 21, 2011 at 10:24 PM, David Endicott dendic...@gmail.com wrote:
I find myself reminded of my reservations about HTTP Upgrade as the opening
handshake. It is clever, efficient and reflects some of the shared nature
between HTTP and WS. However, I felt it should be considered one
I agree that DNS SRV is a matter outside the scope of websockets,
which (for better or for worse) use a connection that is established
via a HTTP request. Thus I do not think that the establishment of a
HTTP connection for websockets should differ in any way from the name
resolution handling of
On Fri, Jul 22, 2011 at 01:22:15AM +0200, Iñaki Baz Castillo wrote:
Well, in SIP there are NAPTR records because SIP can work over
different transports (UDP, TCP, TLS-TCP. SCTP, TLS-SCTP). In case of
WebSocket, it just defined for TCP so NAPTR records don't make sense.
So just SRV is
Good to know, thank you.
On Fri, Jul 22, 2011 at 5:55 AM, Dave Cridland d...@cridland.net wrote:
On Fri Jul 22 03:24:41 2011, David Endicott wrote:
there are added inefficiencies. Also the name resolution of the HTTP
that
serves the Javascript that opens the WS should remain constant.
serves the Javascript that opens the WS should remain constant. If WS
resolves the host/domain to a different address than the HTTP it was
spawned
from, it becomes a method to bypass same-origin / CORS restrictions.
That's an unfortunate misunderstanding.
All protocols that use SRV
On Fri, Jul 22, 2011 at 9:47 AM, David Endicott dendic...@gmail.com wrote:
ActuallyI wasn't talking about the Host: header - that is totally
spoofable...I was concerned about:
1. Browser client resolves example.com via old style DNS to x.x.x.x and
fetches HTTP
2. Received HTML starts
In message 4e28a51f.4020...@callenish.com, Bruce Atherton writes:
I admit that I find it a little troubling to use MUST for the client to
follow this procedure as there is a burden on implementers to understand
how to code this since it isn't done by default in the standard
libraries the
On Jul 23, 2011, at 5:23 PM, Mark Andrews wrote:
In message 4e28a51f.4020...@callenish.com, Bruce Atherton writes:
I admit that I find it a little troubling to use MUST for the client to
follow this procedure as there is a burden on implementers to understand
how to code this since it
On Fri Jul 22 01:11:33 2011, Masataka Ohta wrote:
Dave Cridland wrote:
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
Where is a proof?
Sorry, I've a habit of using the word proof in the English (and
indeed Welsh) sense of test or trial, rather than the
mathematical
On Fri Jul 22 03:24:41 2011, David Endicott wrote:
there are added inefficiencies. Also the name resolution of the
HTTP that
serves the Javascript that opens the WS should remain constant.
If WS
resolves the host/domain to a different address than the HTTP it
was spawned
from, it
Mark Andrews wrote:
Transitioning HTTPS to use SRV is complicated because of proxies.
There needs to be changes to how clients talk to proxies for HTTPS
+ SRV to work through proxies.
CONNECT server.example.org:100 HTTP/1.1
Host: www.example.com
I was referring to this sort of
Dave Cridland wrote:
Where is a proof?
Sorry, I've a habit of using the word proof in the English
1) There are no SRV records.
2) Therefore browsers do not support them.
3) Therefore you'd need to allow for A-lookup as fallback for the
forseeable future.
4) Therefore there's no
On Fri, Jul 22, 2011 at 07:34:49PM +0900, Masataka Ohta wrote:
Dave Cridland wrote:
Where is a proof?
Sorry, I've a habit of using the word proof in the English
1) There are no SRV records.
2) Therefore browsers do not support them.
3) Therefore you'd need to allow for A-lookup
In message 9031.1311328268.180517@puncture, Dave Cridland writes:
On Fri Jul 22 01:11:33 2011, Masataka Ohta wrote:
Dave Cridland wrote:
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
Where is a proof?
Sorry, I've a habit of using the word proof in the English
Scott Schmit wrote:
_http._tcp.example.com. SRV 0 99 80 www.example.com.
_http._tcp.example.com. SRV 0 1 80 www-ds.example.com.
www.example.com. A 198.0.2.1
www-ds.example.com. A 198.0.2.2
www-ds.example.com. 2001:db8::2
I.e., content providers could control/measure their probability
On Fri, Jul 22, 2011 at 11:36:10PM +0900, Masataka Ohta wrote:
Scott Schmit wrote:
_http._tcp.example.com. SRV 0 99 80 www.example.com.
_http._tcp.example.com. SRV 0 1 80 www-ds.example.com.
www.example.com. A 198.0.2.1
www-ds.example.com. A 198.0.2.2
www-ds.example.com.
On Jul 21, 2011, at 10:52 AM, Iñaki Baz Castillo wrote:
2011/7/21 Dave Cridland d...@cridland.net:
It's proven impossible, despite effort, to retrofit SRV onto HTTP; there is
no way it'll be possible to retrofit onto WS.
Right. If WS borns with no SRV (as a MUST for WS clients) then just
On Jul 22, 2011, at 4:51 AM, Dave Cridland wrote:
1) There are no SRV records.
2) Therefore browsers do not support them.
3) Therefore you'd need to allow for A-lookup as fallback for the forseeable
future.
4) Therefore there's no incentive for browsers to support SRV.
That's
On Thu Jul 21 17:06:59 2011, David Endicott wrote:
DNS resolution is not a function of a transport protocol.
I entirely agree, but the specification already includes DNS
resolution as part of URI resolution and URI scheme definition, and
as such, if you want all these things - which are, I
On Thu Jul 21 18:18:31 2011, David Endicott wrote:
It is my opinion that name resolution (however done) is outside the
purview
of WS. It may be handled in any number of ways by the client, and
must
happen *before* WS establishes it's TCP connection and begins
handshaking.
The URI scheme
On Thu Jul 21 19:43:07 2011, David Endicott wrote:
I do not know SIP or XMPP well enough to comment on why they
mandated the
name resolution mechanisms they did.However, XMPP is used in a
highly
dynamic host environment, so having flexible extensible name
resolution is
likely an
2011/7/19 Dave Cridland d...@cridland.net:
Hi, I assume there is no interest in making DNS SRV mechanism exposed
in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of
the WebSocket core specification, neither referencing it (in the same
way RFC 3261 SIP protocol mandates the
I am opposed to inclusion in core specification. I would accept it as
optional extension.
DNS resolution is not a function of a transport protocol. DNS SRV has no
special association with WS.It is my opinion that this would be
additional cruft that is only marginally related to the purpose
2011/7/21 David Endicott dendic...@gmail.com:
DNS resolution is not a function of a transport protocol. DNS SRV has no
special association with WS. It is my opinion that this would be
additional cruft that is only marginally related to the purpose and function
of websockets. It does not
1 - 100 of 143 matches
Mail list logo
