Also:
The server side is in fact more difficult than the client side; it's not
just a matter of libraries, but other issues as well, including:
* reving the GUI tools used to administer things
* for zones stored in files:
reving the zone file parser
reving the server code that interprets same
* for zones stored in active directory
reving the AD read / write code
reving the server code that is client of same
I can't see how to do any of these in a side-by-side type of way.
Bob
-----Original Message-----
From: Eric A. Hall [mailto:ehall(_at_)ehsco(_dot_)com]
Sent: Thursday, May 20, 2004 3:59 PM
To: Yakov Shafranovich
Cc: Bob Atkinson; IETF MARID WG
Subject: Re: suggested new RRtype experiment
On 5/20/2004 3:02 PM, Yakov Shafranovich wrote:
So let me get this straight: if MARID defines a new RR type, Windows
will not be able to support it?
People have been dealing with resolver limitations for years and not
just
for Windows. In the usual case, they deal with it by embedding their
own
resolver into the app that does whatever heavy lifting is needed,
while
passing simple calls you can to the native APIs. Even implementors of
the
mail-submission and -retrieval SRV records
[draft-hall-mail-srv-01.txt]
have run into this problem because SRV is not supported in earlier
versions of the Windows resolver (or in many of the resolvers on
several
other platforms for that matter).
Is bundling a resolver lib into your app show-stopping? I mean, that's
really the test for how important this work is: either its more
important
than the work required to build a resolver function, or it isn't.
The server part of the problem is a bit more fuzzy but is less
difficult
than the client side.
--
Eric A. Hall
http://www.ehsco.com/
Internet Core Protocols
http://www.oreilly.com/catalog/coreprot/