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 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....
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.
However....I agree in the sense that I don't think it's been well thought
out what the ramifications are of introducing a new URI *scheme*. (ie.
ws:// and wss://) Since everything after the double-slash is "scheme
specific", defining a scheme implies many things (including name resolution
policies, well-known ports, transport protocols, etc.) But, I don't want
to get side tracked over this.
On Thu, Jul 21, 2011 at 2:10 PM, Iñaki Baz Castillo <ibc(_at_)aliax(_dot_)net>
wrote:
2011/7/21 David Endicott <dendicott(_at_)gmail(_dot_)com>:
I am strongly opposed to any MUST definition for any type of URL
resolution.
SIP and XMPP mandate (MUST) a resolution mechanism based on NAPTR, SRV
and A/AAAA records. Are they also wrong? do you also oppose to the DNS
MX resolution (as mandatory) for a mailto: URI? Do you imagine that a
mail server admin could not assume that SMTP clients would always use
MX resolution as the first choice? annoying that you say that, sorry.
I'm ok with inheriting / mimicking HTTP. Since it is intended to live
in
the same universe as HTTP, I'm ok with it sharing mechanisms /
limitations.
Yes, I assume many people in the HTTP warden is fine with this. That
is the problem: forcing a *new* protocol to inherit ugly limitations
just because "people is used to them". I don't understand how you can
prefer to ignore cool NEW solutions/mechanisms. This should not be a
valid argument in a new protocol design.
--
Iñaki Baz Castillo
<ibc(_at_)aliax(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf