<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>You are quite right about the constrictions of predefined
taxonomy of attributes such as Dublin Core. I suggested it merely
to get people thinking about lookups by attribute rather than by
name. My sense is that we need something that allows growth via
use, much like the hash tagging that we see in so many places.
There will, of course be conflicts and collisions.</p>
<p>But if we look at the most successful of all resource-binding
systems, the biological systems of living entities to find food
and mates, we see a lot of collisions and conflicts. We see
butterflies and moths adopting color patterns as signals for the
attribute of "species" (for mate finding) and also as a defense
"my color pattern makes me look like another species that tastes
bad, so don't eat me even though I am of a good tasting species".</p>
<p>(In something as large, diverse, and changing as the internet we
may have a lot to learn from the biological world.)<br>
</p>
<p>Attribute systems are usually just a preliminary culling to find
potential targets of interest.</p>
<p>My example of wanting to buy some M-4 screws and looking up via
attributes "hardware store" and "near me" could lead to results
that are closed or deal only in wholesale sales. So I'd have to
do some additional refinement of the search results. (This is
true in biological systems as well.)</p>
<p>Lookups by attribute create an interesting, and often quite
valuable, side effect often called "serendipity" - that happens
when you are looking for things of type X and you come across
something close to X that turns out to be useful. This occurs in
libraries as one wanders the stacks looking for a particular
volume (perhaps to discover that some professor checked it out 20
years ago and never returned it, grrrr) and you stumble across
something else of interest. DNS doesn't have serendipity. DNS is
a good system for use underneath attribute systems.</p>
<p> --karl--<br>
</p>
<div class="moz-cite-prefix">On 2/21/22 8:13 AM, sivasubramanian
muthusamy wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKsgsGzcbX+kYegTZggb5he5fk2TyKzvwDLDjFJM4bNnNYOPNw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">The attributes concept of the Dublin Core model
could be applied in public interest to enrich the way Domain
names are chosen / registered, especially in the case of highly
valuable/useful generic names. The cataloguing model alone
wouldn't suffice, because the library-class metadata coding by
all segments of users (even business) would not happen so
methodically as in the libraries, leaving autotagging by machine
learning as the predominant method by which the catalogues would
be compiled. ( comment based on a quick, rapid look for the
first time on Dublin Core documentation, it is possible that I
might have missed something very basic)<br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div dir="ltr">Sivasubramanian M</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Feb 21, 2022 at 8:40
PM Carlton Samuels via At-Large <<a
href="mailto:at-large@atlarge-lists.icann.org"
moz-do-not-send="true" class="moz-txt-link-freetext">at-large@atlarge-lists.icann.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Thank you Karl for
prompting organic thinking every time you intervene in
these discussions. As an AT&T alumnus and having sat
through a year of training ( a week every month) at Bell
Labs, the fellas were keen to teach us some of those
lessons </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">you reprised in
commentary. </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Karl wrote.........</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-size:large"><font
face="tahoma, sans-serif"> </font><i><font
face="trebuchet ms, sans-serif">"...<span
style="font-size:small">I also am of the belief that
on the net attributes are often more </span><span
class="gmail_default"> </span><span
style="font-size:small">important than names. For
instance, if I am looking to buy some machine</span><br>
</font></i></div>
<i><font face="trebuchet ms, sans-serif">screws I care more
about the attribute "hardware store" than any<span
class="gmail_default" style="font-size:large"></span>particular
name of such a store. In that vein I sense that it
might be<br>
a useful endeavor to create a list of attribute types
[and for each some<span class="gmail_default"
style="font-size:large"> </span>definition of the
possible values]. I'm thinking something like the<br>
Dublin Core metadata definitions, but of more universal
applicability.<span class="gmail_default"
style="font-size:large"> </span>To make use of such a
world in which things are known by their<br>
attributes as much as by their names we would need new
protocol and<span class="gmail_default"
style="font-size:large"> </span>server machinery to do
the kind of soft lookups that attribute systems<br>
need. As is my tendency, I sense that such things might
well learn from<span class="gmail_default"
style="font-size:large"> </span>the biological world
in which "adequate matching" is often a key to<br>
survival.<span class="gmail_default"
style="font-size:large">"</span></font></i>
<div><span class="gmail_default"
style="font-family:tahoma,sans-serif;font-size:large"><br>
</span></div>
<div><span class="gmail_default"
style="font-family:tahoma,sans-serif">By gum! I taught
in the library school at the UWI for years Karl,
specifically digital libraries and associated concepts
of cataloguing and searching where the Dublin Core is
central to defining a metadata element set that is
inclusive of coding special collections. </span></div>
<div><span class="gmail_default"
style="font-family:tahoma,sans-serif">I share your views
on the relative importance of attributes vs. names for
information gathering. And have encouraged a kind of
extension to the Dublin Core orthodoxy in service. </span></div>
<div><font face="tahoma, sans-serif"><br>
</font></div>
<div><font face="tahoma, sans-serif"><span
class="gmail_default"
style="font-family:tahoma,sans-serif;font-size:large"></span><span
class="gmail_default"
style="font-family:tahoma,sans-serif">To the larger
point you make on accommodating innovation from the
edge, one of my friends, Evan Leibovitch, has been
arguing for years </span></font></div>
<div><font face="tahoma, sans-serif"><span
class="gmail_default"
style="font-family:tahoma,sans-serif">that a reckoning
is coming and will come to the DNS by several
usurpations, among them implementations based on
attribute systems. </span></font></div>
<div><font face="tahoma, sans-serif"><span
class="gmail_default"
style="font-family:tahoma,sans-serif">History will
absolve him, I think.</span></font></div>
<div><font face="tahoma, sans-serif"><span
class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</span></font></div>
<div><font face="tahoma, sans-serif"><span
class="gmail_default"
style="font-family:tahoma,sans-serif">Carlton</span><br>
</font>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;font-size:large"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;font-size:large">
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;font-size:large"><br>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
==============================<br>
<i><font face="comic sans ms, sans-serif">Carlton
A Samuels</font></i><br>
<font face="comic sans ms, sans-serif"><i>Mobile:
876-818-1799<br>
<font color="#33CC00">Strategy, Process,
Governance, Assessment & Turnaround</font></i></font><br>
=============================</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 20 Feb 2022 at
23:36, Karl Auerbach via At-Large <<a
href="mailto:at-large@atlarge-lists.icann.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">at-large@atlarge-lists.icann.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">As a personal issue I
think the notion of emojis in DNS is little more <br>
than a concession to a (hopefully) passing childish fad.<br>
<br>
And from a security perspective (not to mention the
confusion of users <br>
in genera) I have a intuitive sense that it is a fad that
contains seeds <br>
of trouble.<br>
<br>
But I'm just one person out of billions of us. I don't
use emojis, but <br>
it seems that a lot of us do.<br>
<br>
And I don't want to be like the voice of Ma Bell in the
1960's loudly <br>
proclaiming that packet switching and the attachment of
foreign devices <br>
were something to be avoided and banned.<br>
<br>
So how do I decide?<br>
<br>
So using the rubric of my "first law of the internet" I
start with the <br>
position of "emojis ought to be allowed" on the basis of
them being of <br>
private benefit (although I personally find it hard to see
that benefit <br>
or credit it with value.)<br>
<br>
Then I say "but is there a public detriment and if so is
it substantial <br>
enough to block that private benefit?"<br>
<br>
As things stand right now I can't clearly and concretely
articulate the <br>
public detriments (although I feel that they are out
there) much less <br>
measure them.<br>
<br>
Which, according to my rule means that I would conclude to
take no <br>
action (at this time) against emojis in domain names. But
I'd suggest <br>
inquiries and research to obtain more concrete information
about the <br>
issue. (Yes, I realize that my conclusion contains a
strong possibility <br>
that we could end up with an deeply entrenched ill
practice.)<br>
<br>
Part of this is informed by my belief that the domain name
system is <br>
slowly fading from the public eye; that we are moving into
a world in <br>
which DNS names are becoming more a part of the hidden
machinery of the <br>
net (like MAC addresses) and that higher level naming
abstractions, <br>
things like Twitter names or Facebook handles, are
becoming the more <br>
prevalent forms of naming on the net.<br>
<br>
I also am of the belief that on the net attributes are
often more <br>
important than names. For instance, if I am looking to
buy some machine <br>
screws I care more about the attribute "hardware store"
than any <br>
particular name of such a store. In that vein I sense
that it might be <br>
a useful endeavor to create a list of attribute types [and
for each some <br>
definition of the possible values]. I'm thinking
something like the <br>
Dublin Core metadata definitions, but of more universal
applicability. <br>
To make use of such a world in which things are known by
their <br>
attributes as much as by their names we would need new
protocol and <br>
server machinery to do the kind of soft lookups that
attribute systems <br>
need. As is my tendency, I sense that such things might
well learn from <br>
the biological world in which "adequate matching" is often
a key to <br>
survival.<br>
<br>
--karl--<br>
<br>
<br>
On 2/20/22 17:29, Alejandro Pisanty wrote:<br>
> Karl,<br>
> <br>
> TL;DR, QED for no emojis in DNS. Thanks.<br>
> <br>
> Alejandro Pisanty<br>
> <br>
> On Sun, Feb 20, 2022 at 3:52 PM Karl Auerbach via
At-Large <br>
> <<a href="mailto:at-large@atlarge-lists.icann.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">at-large@atlarge-lists.icann.org</a>
<br>
> <mailto:<a
href="mailto:at-large@atlarge-lists.icann.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">at-large@atlarge-lists.icann.org</a>>>
wrote:<br>
> <br>
> On 2/20/22 8:52 AM, sivasubramanian muthusamy via
At-Large wrote:<br>
> <br>
> > What does ICANN think about private and
often proprietary<br>
> > 'innovations' that aspire to "cause a major
shift in the way the<br>
> > Internet [DNS] works" ?<br>
> ><br>
> Remember, the Internet came from a rejection of
the status-quo, the<br>
> world of circuit switching and central control.<br>
> <br>
> The question you asked is not far distant from a
question whether we<br>
> ought to nail down the Internet in the same way
the telcos of the first<br>
> three quarters of the 20th century ossified the
telephone networks.<br>
> <br>
> Ma Bell and other telco's imposed extreme, and
often arbitrary, limits<br>
> on innovation at the edges. Take a look at the
1956 US case regarding<br>
> the Hush-a-Phone. (In that case AT&T tried to
block the attachment of<br>
> what was essentially a plastic hand that would be
attached by the user<br>
> to the mouthpiece of a telephone. At&T made
wild claims that that would<br>
> cause the telephone network to collapse and
repairmen would blown off<br>
> the top of telephone poles.) Then look at the
Carterphone and MCI<br>
> cases.<br>
> <br>
> One of the hallmarks of the Internet is
permissionless innovation at<br>
> the<br>
> edges. Clearly there are balances to be made, but
we risk a balance<br>
> that<br>
> pushes too much control to the center.<br>
> <br>
> Some decades ago I distilled this balance into a
short formulation:<br>
> <br>
> First Law of the Internet<br>
> <br>
> + Every person shall be free to use the Internet
in any way<br>
> that is privately beneficial without being
publicly<br>
> detrimental.<br>
> <br>
> - The burden of demonstrating public
detriment shall<br>
> be on those who wish to prevent the
private use.<br>
> <br>
> - Such a demonstration shall require
clear and<br>
> convincing evidence of public
detriment.<br>
> <br>
> - The public detriment must be of such
degree and extent<br>
> as to justify the suppression of the
private activity.<br>
> <br>
> <a
href="https://www.cavebear.com/old_cbblog/000059.html"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.cavebear.com/old_cbblog/000059.html</a><br>
> <<a
href="https://www.cavebear.com/old_cbblog/000059.html"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.cavebear.com/old_cbblog/000059.html</a>><br>
> <br>
> --karl--<br>
></blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>