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@xxxxxxxxx> wrote:
2011/7/21 David Endicott <dendicott@xxxxxxxxx>:
> 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.
Yes, I assume many people in the HTTP warden is fine with this. That
> 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.
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.
--
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf