On Sep 12, 2011, at 7:06 PM, Joe Touch wrote: >> Given that I think service location is almost inherently >> application-specific anyway, that solution is also fine with me. I don't >> know what value is added by SRV, other than confusion. > > SRV indicates the port number (useful if not the default) and weight, etc. right. but given that you can include the same things in a TXT record, if you have to query for TXT RRs anyway, what's the value added by doing an additional query for SRV RRs? >>> If you insist on a clean, generic, system that solves this problem >>> for nfsv4 domain-root and other similar cases, you're clearly arguing >>> for the deep slog of fixing this throughout the IETF. >> >> Eventually yes. But I'm also arguing against holding up this >> documentfor reasons that seem to me to be pedantic. > > All protocol specs are pedantic. Perhaps, but their interpretations don't have to be pedantic. > The way to avoid holding this doc up, IMO, is to use SRV records as they're currently used - with TXT records where additional info is needed. Your notion of "currently" seems like a stretch. My understanding is that they're currently used in several different ways, the RFC notwithstanding. >>> The worldwide default for services with assigned ports is to assume that port number. >> >> yes. >> >>> The worldwide system for doing otherwise is SRV records. >> >> no. > > I'll let Apple know. Thanks. :) >>> Either one works fine, and either one assumes that both sides make the same assumption. >>> >>> SMTP is not unique in this sense. >> >> False. SRV records are poorly designed and broken for several >> reasonsalready cited. And SMTP is somewhat unique in that it doesn't >> make sense to think of it entirely in terms of pairwise connections. > > What exactly isn't pairwise about mail relay? Right now, if you want to be able to receive mail reliably, you have to have an MX which listens on port 25. If you want to send mail across administrative boundaries, in general, you have to be able to send to port 25. There's no way to do pairwise port negotiation. Of course, in some hypothetical other world with a slightly different mail protocol, the problem could be solved differently. >>> The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them. >> >> Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture. > > Good. Then stop using SRV records. That's what they're for, in case it was at all vague in RFC 2782. I'd be very happy to see SRV records deprecated, or at least discouraged, for new protocols. >>>>> Further, it avoids the burden of pre-allocating port numbers (a quite >>>>> constrained resource) for services that might never be used at a given >>>>> endpoint, and allows that map to be assigned dynamically and locally. >>>> >>>> Yes, it does that, and I agree that pre-allocated port numbers are >>>> precious. Though I think this particular mechanism causes more problems >>>> than it solves. >>> >>> I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port). >> >> I identified several issues with port-names at the time you made >> that >> proposal. One of the bigger problems IIRC was that they assumed that >> there could only be one service with a particular name on a particular >> host, when these days "virtual hosts" (by which I mean multiple services >> acting on behalf of different domains all supported by the same physical >> host) are quite common, and the notion of "host" has become fairly >> blurry. > > Talk about breaking E2E. You are confusing a port with an endpoint ID. You might have an easier time understanding what I'm saying, if you weren't so busy trying to prove to yourself that I'm confused. >>>> New RR types are what they are. Some are inevitably defined better than >>>> others. For the specific case of SRV, I don't think the RR was well >>>> defined. But DNS is not as extensible as we'd like, new RR types are >>>> scarce and difficult to deploy, and so there's some weight to the idea >>>> that we should make do with what we have whenever it doesn't break anything. >>> >>> RIGHT!!!!! >>> >>> Which is why using TXT records with SRVs - which is what most other SRV users do when they need OOB info - is the right way to go. >> >> Nah, if you're going to use TXT records, don't bother with SRVs. Avoid the extra lookup and the resulting hit in latency and reliability. > > If you already know the port number, there's nothing that prevents you from doing this, FWIW. Or if you really need to support arbitrary ports, just encode the port number in the TXT record. > > If DNS would reliably let you get both RR types in a single query, that would be fine, but it doesn't. > > So go fix *that*. ;-) If I were going to fix DNS, that would be only one of several things on my list of things to fix. But I don't think the Internet is desperate enough to want to fix DNS yet. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf