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(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf