Dnia sobota, 30 pa¼dziernika 2004 16:32, Thiago Macieira napisa³: > Jakub Stachowski wrote: > >> You mean "ability to use UTF-8 instead of ACE for mDNS". IDN means > >> "International Domain Name". If your UTF-8 domain isn't ASCII, then it's > >> internationalised and, therefore, IDN. > > > >Nope, I meant for both uDNS and mDNS. And for both PTR and SRV (noticed > > that after reading DNS-SD spec more carefully). > > I don't agree, see below. Remember that DNS-SD is still a draft. It can be > changed and I believe it will before it becomes an RFC. > But I have no idea what and how will be changed. So I can only act according to its current state. > >> At least, that's how I read things. Making mDNS not follow the IDN > >> Nameprep guidelines would wreak havoc and I, quite frankly, refuse to > >> implement it that way. > > > >Implementing it any other way would make it useless - incompatible with > >specification and every existing implementations. > > So we agree that "Fußball Fileserver.local" is the same as "fussball > fileserver.local"? Sorry, I'm really not sure at this moment. I have to experiment some more. > > >> Also note that PTR queries over normal DNS must be ACE-encoded. I don't > >> care what DNS-SD says: if you transmit over the normal DNS servers, it > >> has to be ACE, not UTF-8. > > > >From DNS-SD spec: " DNS recommends guidelines for allowable characters for > >host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are > > not host names." > > > >DNS-SD is _not_ DNS - it only happens to reuse existing infrastructure - > > DNS servers. > > [here is a mental exercise for me] > > Imagine the following two uDNS queries (for SRV): > Müller-Website.müller.org > josé.macieira.info > > Tell me, just by looking at them: how do we encode each one? If what you're > asking is to be followed, the "Müller-Website" part would be UTF-8 encoded, > while "müller.org" is ACE-encoded. And "josé.macieira.info" would be > encoded with ACE entirely. Exactly. > > I am imagining the following situation: > 1) user goes to dnssd:/ and selects "Web sites" and it is configured (for > whatever reason) to list müller.org > 2) kio_dnssd must send this query: > _http._tcp.xn--mller-kva.org. IN PTR? > 3) the answer comes back as: > _http._tcp.xn--mller-kva.org. IN PTR > M\195\188ller-Website._http._tcp.xn--mller-kva.org. > 4) if the user accesses that site, the name-resolver code must run this: > M\195\188ller-Website._http._tcp.xn--mller-kva.org. IN SRV? > which could result in: > M\195\188ller-Website._http._tcp.xn--mller-kva.org. IN SRV > 0 0 80 www.xn--mller-kva.org. Here ends DNS-SD operation and normal DNS starts: 4.5) > www.xn--mller-kva.org. IN A 192.168.1.2 > 5) I have no idea how Konqueror gets communicated that from kio_dnssd. It > *cannot* be with a redirection to "http://Müller-Website.müller.org", kio_dnssd implements DNS-SD so it should perform steps 1-4 and redirect to www.xn--mller-kva.org. Konqueror will get http://www.müller.org:80 and use normal DNS. > because it would result in the behaviour I listed below: > > What happens if the user types in Konqueror "Müller-Website.müller.org"? > 1) Konqueror will try a SRV resolution: > _http._tcp.xn--mller-website-wob.xn--mller-kva.org. IN SRV? > with the answer: > _http._tcp.xn--mller-website-wob.xn--mller-kva.org IN SRV > 0 0 80 www.xn--mller.kva.org. > www.xn--mller-kva.org. IN A 192.168.1.2 > 2) So Konqueror connects to that site. > > My conclusions are: > - KResolver needs more flags: > => one for name-to-name PTR queries > => one for generic SRV queries > => one for SRV queries which prepends the service and protocol I think that it needs one flag: "DNS mode" or "DNS-SD mode". In first mode everything is ACE encoded (for uDNS), SRV request has . order. In second mode: is UTF-8 encoded, rest is IDN, SVR is . order. This two modes are never mixed so this flag could be argument for constructor. > > - the first two would UTF-8 encode the first part of the nodename, in all > cases, with care being taken for dots escaped with backslashes. The rest of > the domain goes ACE if it's uDNS, or UTF-8 if it's mDNS. > > - someone who wants to support DNS-SD and normal resolution (SRV- and non > SRV-based) would be required to write the following records: > . IN PTR .. > .. IN SRV ... > .. IN SRV ... > . IN A ... > > example: > ; DNS-SD > _http._tcp IN PTR Müller-Website._http._tcp > Müller-Website._http._tcp IN SRV 0 0 80 www > > ; RFC 2782 (SRV): > _http._tcp.Müller-Website IN SRV 0 0 80 www > > ; old-style: > Müller-Website IN CNAME www > www IN A 192.168.1.2 > > the first two are DNS-SD, the third is SRV-based resolution, the fourth is > non SRV-based. In the first two, is encoded in UTF-8; in the > latter two, it's encoded in whatever method is used (ACE for uDNS, UTF-8 > for mDNS). > > So you see why I say it's stupid to encode in UTF-8 in uDNS? It is quite messy. I will ask Stuart Cheshire for comment on IDN/UTF-8 weirdness. > > Also note that DNS-SD inverted the already-established SRV record.Since > SRV-based resolution is set forth in RFC 2782, whenever DNS-SD conflicts > with the established RFC, the RFC overrules, until such time as DNS-SD > becomes an RFC of its own and RFC 2782 is replaced. This is not open for > negotiation. We have two clearly separated modes: DNS and DNS-SD. Queries for these two are never mixed so there will never be dilemma which syntax should be used. I understand that you don't want to pollute DNS resolver class with code violating DNS standards. In this case DNS-SD stuff can be in separate class (like DNSSD::Resolver for example) reusing private parts of normal resolver (for example kresolvermanager.cpp, kresolverstandardworkers.cpp). I have just started learning inner working of KResolver so what I said above about reusing may be incorrect. > > >After reading some more (mDNS spec, Apple's mDNSResponder code, GNOME > > code, mdnsd code) I think that reimplementing daemon is not best idea: > > [snip] > > >As you can see, now I am for using libhowl and mDNSResponder as mDNS > > low-level API for KResolver (exactly as libresolv is used for uDNS). > > Publishing part should be kept in kdnssd. > >Single disadvantage is that it adds external dependency (probably optional > > if someone doesn't care about mDNS) instead of internal. > > Agreed. > > And if mDNSResponder isn't running, we can still send "legacy DNS" queries > to the mDNS multicast address and receive answers. We will not cache those. Kind of fallback? Good idea. > > >> However, it has not gone away completely. It's still available as Q3Dns. > >> The warning on it is "This class is part of the Qt 3 compatibility > >> library. It is provided to keep old source code working. We strongly > >> advise against using it in new code.", though. > > > >So using it means linking to one more library? > > I don't know. It would seem that way. That is bad, I don't think that linking to one more deprecated library is good idea. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<