<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Avri<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite"><br>
On 21 Sep 2009, at 13:14, Dr. Francis MUGUET wrote:
<br>
<br>
<blockquote type="cite">except for some fields like the CNAME that
you mentioned at the workshop,
<br>
</blockquote>
<br>
this is not just any old field but an essential feature, a resource
record type that, until and unless it is changed makes the entire
project unworkable as the namespaces will leak into each other. </blockquote>
You are dramatizing a little bit with visions of floods... <br>
<br>
,without indication of class, the default is the class IN. <a
href="http://en.wikipedia.org/wiki/CNAME_record" class="l"
onmousedown="return rwt(this,'','','res','1','AFQjCNHa8Ccamn32cd1TamrrQdOjUDzmNg','&sig2=h9pgNrWM-HnbXYLxnoGzSg')"></a><br>
and <br>
although the <a href="http://en.wikipedia.org/wiki/CNAME_record"
class="l"
onmousedown="return rwt(this,'','','res','1','AFQjCNHa8Ccamn32cd1TamrrQdOjUDzmNg','&sig2=h9pgNrWM-HnbXYLxnoGzSg')"><em>CNAME</em>
record</a> can be a convenient shortcut, everything can be done with A
records, <br>
<br>
So for the class IN, for legacy reasons, the CNAME could only be used
for aliasing<br>
names in the class IN.... no big deal<br>
and in the new <i>classes, </i> <br>
either we modify the syntax for the CNAME<br>
( which is possible, since there no legacy ) <br>
or CNAME would be avoided unless aliasing to a domain name in the IN
class...<br>
so no big deal...<br>
and above all, no confusion <br>
<br>
or, other idea,, may be better, we adopt the rule<br>
that aliasing can only be done with the same <i>class.</i><br>
<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite">Even if you intend your new Class not to use it, the fact
that in can be used </blockquote>
cf infra<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite">means that the namespaces can't be isolated from each
other - hence putting us back in need of a single global name space.
i.e. right back were we are now.
<br>
<br>
<blockquote type="cite">almost everything is in the RFCs
<br>
</blockquote>
<br>
not by a long shot.
<br>
<br>
two things that immediately come to mind are a well formed definition
of these Classes and a well formed URI scheme f</blockquote>
exactly, I neved hide this fact in my presentation, the class field
must become represented in the URI, with<br>
an added syntax feature. <br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite">or naming your new services/objects so that apps, apps
that would need to be modified, can use the new namespace.
<br>
</blockquote>
yes of course, to use new things, the apps must be updated, nothing
wrong with this<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite"><br>
and things in the RFC that have not yet been implemented and tried may
or may not work.
<br>
<br>
and how many DNS implementations would need to be updated?
<br>
</blockquote>
all, it is like a software update<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite"><br>
as for <a class="moz-txt-link-freetext" href="http://www.icann.org/en/meetings/stockholm/unique-root-draft.htm">http://www.icann.org/en/meetings/stockholm/unique-root-draft.htm</a>
<br>
<br>
The problem here is that was just an assumption, but when people </blockquote>
who ?<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite">started looking at doing it, they started to find all the
reasons why it would be very difficult.
<br>
<br>
</blockquote>
be more specific<br>
<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite">my prediction is still that even if you can get the
resources and talent to do all the necessary research work and if it is
indeed doable, which won't be known until some ways down the road, I
still predict a decade is the shortest time before deployment - and
possibly 2 decades before it might see wide spread use - if it proves
to be feasible at all. I admit this is slightly better then the
infinite time prediction I gave you on first hearing the proposal (the
last thing I predicted infinite time on was IPv6 and yeah, maybe i was
wrong on that. maybe</blockquote>
your track record on prediction reassures me <span
class="moz-smiley-s3"><span> ;-) </span></span><br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite">.) as i said, i love seeing people find clever uses for
unused protocol features, but one must be realistic about the effort
involved in making it work and deployment. i think there is some
cleverness in the proposal but the road to deployment is really really
difficult and very very long.
I<br>
</blockquote>
we agree to disagree on this later point... <br>
the deploment is going to depend on the adoption of the DNS software
update by the majors ISPs,<br>
but since they might not lose OoS on the IN class, I seen no reason why
they should not perform the update,<br>
unless they resist for political reasons in order to maintain a
monopoly...<br>
in the long run, this is going to depend on the request of their
customers...<br>
( ie why I can't access this site... etc.... ) <br>
and if whole communities, spread all over the world <br>
request for the <i>class</i> feature .... it could spread like
wildfire... <br>
be the "In" thing ( intended pun ) <br>
<br>
Best<br>
<br>
Francis <br>
<br>
<blockquote cite="mid:036A4270-2D9A-4C64-99D8-7A05EA12BF0D@acm.org"
type="cite"><br>
a.
<br>
<br>
____________________________________________________________
<br>
You received this message as a subscriber on the list:
<br>
<a class="moz-txt-link-abbreviated" href="mailto:governance@lists.cpsr.org">governance@lists.cpsr.org</a>
<br>
To be removed from the list, send any message to:
<br>
<a class="moz-txt-link-abbreviated" href="mailto:governance-unsubscribe@lists.cpsr.org">governance-unsubscribe@lists.cpsr.org</a>
<br>
<br>
For all list information and functions, see:
<br>
<a class="moz-txt-link-freetext" href="http://lists.cpsr.org/lists/info/governance">http://lists.cpsr.org/lists/info/governance</a>
<br>
<br>
.
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------
Francis F. MUGUET Ph.D
MDPI Foundation Open Access Journals
<a class="moz-txt-link-freetext" href="http://www.mdpi.org">http://www.mdpi.org</a> <a class="moz-txt-link-freetext" href="http://www.mdpi.net">http://www.mdpi.net</a>
<a class="moz-txt-link-abbreviated" href="mailto:muguet@mdpi.org">muguet@mdpi.org</a> <a class="moz-txt-link-abbreviated" href="mailto:muguet@mdpi.net">muguet@mdpi.net</a>
KNIS <a class="moz-txt-link-freetext" href="http://knis.org">http://knis.org</a>
Academic Collaboration / University of Geneva
<a class="moz-txt-link-freetext" href="http://syinf.unige.ch/recherche/cooperation">http://syinf.unige.ch/recherche/cooperation</a>
Mobile France +33 6 71 91 42 10
Switzerland +41 78 927 06 97
Cameroun +237 96 55 69 62 ( mostly in July )
World Summit On the Information Society (WSIS)
Civil Society Working Groups
Scientific Information : <a class="moz-txt-link-freetext" href="http://www.wsis-si.org">http://www.wsis-si.org</a> chair
Patents & Copyrights : <a class="moz-txt-link-freetext" href="http://www.wsis-pct.org">http://www.wsis-pct.org</a> co-chair
Financing Mechanismns : <a class="moz-txt-link-freetext" href="http://www.wsis-finance.org">http://www.wsis-finance.org</a> web
Info. Net. Govermance : <a class="moz-txt-link-freetext" href="http://www.wsis-gov.org">http://www.wsis-gov.org</a> web
NET4D : <a class="moz-txt-link-freetext" href="http://www.net4D.org">http://www.net4D.org</a>
UNMSP : <a class="moz-txt-link-freetext" href="http://www.unmsp.org">http://www.unmsp.org</a>
WTIS : <a class="moz-txt-link-freetext" href="http://www.wtis.org">http://www.wtis.org</a> REUSSI : <a class="moz-txt-link-freetext" href="http://www.reussi.org">http://www.reussi.org</a>
------------------------------------------------------
</pre>
</body>
</html>