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 <i...@aliax.net> wrote: > 2011/7/21 David Endicott <dendic...@gmail.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 > <i...@aliax.net> >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf