--===============1300247025==
Content-Type: multipart/signed;
  boundary="nextPart1804104.uGsaWZWETn";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1804104.uGsaWZWETn
Content-Type: text/plain;
  charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Jakub Stachowski wrote:
>> 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=FCller-Website.m=FCller.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=FCller.org:80
> and use normal DNS.

Agreed. But you have to realise that will trigger yet again one more SRV=20
lookup.

So, we get from "M=FCller-Website" to "M=FCller-Website._http._tcp.m=FCller=
=2Eorg"=20
to "www.m=FCller.org", then back to "_http._tcp.www.m=FCller.org" in order =
to=20
resolve to go back to "www.m=FCller.org" again (either by getting a proper=
=20
SRV reply redirecting to it, or by getting no SRV reply).

It goes PTR -> SRV -> SRV -> A.

>> My conclusions are:
>> - KResolver needs more flags:
>> =3D> one for name-to-name PTR queries
>> =3D> one for generic SRV queries
>> =3D> 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
> <service>.<instance> order. In second mode: <instance> is UTF-8
> encoded, rest is IDN,  SVR is <instance>.<service> order.
>This two modes are never mixed so this flag could be argument for
> constructor.

The first two flags would be DNS-SD exclusively, but I think it would be=20
better to separate. So I agree.

>> 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.

Please do. I believe IDN was disregarded at the time DNS-SD was conceived=20
=2D- quite possibly because it didn't exist before the beginning of this=20
year. But now that it's out there and a standard, it must be upheld.

>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'm not so sure. As I said, there's some redirection going on from=20
kio_dnssd to other ioslaves, which would always use normal DNS/mDNS mode.

>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.

We'll see that together, don't worry.

>That is bad, I don't think that linking to one more deprecated library
> is good idea.

That leaves us with other DNS-parsing libraries, or with libresolv=20
directly.

=2D-=20
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart1804104.uGsaWZWETn
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBhAP0M/XwBW70U1gRAuuOAKCH1ouauD2/xBqQXQPOE4r2xStLuQCeLOtU
1kDfmpIRXJprP/QLQaq7NhE=
=BB4n
-----END PGP SIGNATURE-----

--nextPart1804104.uGsaWZWETn--

--===============1300247025==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1300247025==--