Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 excellent choice.


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 as a simple A record lookup:

;; ANSWER SECTION:
_xmpp-server._tcp.isode.com. 259200 IN	SRV	5 0 5269 xmpp.isode.com.

;; ADDITIONAL SECTION:
xmpp.isode.com.		225364	IN	A	62.3.217.250

;; ANSWER SECTION:
isode.com.		73130	IN	A	87.106.143.99

This property alone is very useful - in a websockets case this would mean being able to provide websockets services from a different host (or network) to the traditional web services in a simple manner, fully compatible with SOP.

The fact that this also allows cheap lightweight load balancing and fallback control is also useful in other cases; none of this relates to dynamic hosts, but simply richer service location.


I do not oppose DNS's MX records for SMTP as email addresses are name@domain, so obviously the Domain Name System is appropriate. Also, I fail to see why a mail admin should care how the SMTP clients arrive at the server. DNS MX is a reasonable solution, but there may be other methods, any and all of which are irrelevant to the SMTP server. Especially when the SMTP server
supports multiple email domains....


A mail admin does need to care *that* the service is located, and therefore will care *how* it is located.

You can be as theoretical as you like, by all means, but in practical terms, your email address (and my XMPP address) work because they use a defined, interoperable, service location mechanism, which operates via DNS record lookup.

(Also, I have no idea what multiple domains has to do with this.)


Since WS is intended as a browser supported protocol, WS should follow the same URI resolution mechanisms as HTTP (or how URI resolution is done in general) Having URLs that could resolve differently for a HTTP request and
a WS setup is a problem.


But they do resolve differently anyway. You don't get a page from a 'ws' scheme URI, you get a transport protocol connection. This is good, indeed, it's kind of the point.

Your suggestion of "how URI resolution is done in general" is somewhat self-defeating, too, since aside from 'http' and 'https', there are 'mailto', which uses MX, 'sip' and 'xmpp', which both use SRV.

I think opponents of SRV records need to mount a stronger argument than the kind of luddite argument that if it's hard for one protocol in use by the browser, it should be hard for them all.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]