[At-Large] Opera now lets you ditch boring web links and use emojis instead

sivasubramanian muthusamy 6.internet at gmail.com
Mon Feb 21 16:13:06 UTC 2022


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)

Sivasubramanian M



On Mon, Feb 21, 2022 at 8:40 PM Carlton Samuels via At-Large <
at-large at atlarge-lists.icann.org> wrote:

> 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
> you reprised in commentary.
>
> Karl wrote.........
>
>
> *"...I also am of the belief that on the net attributes are often more
> important than names.  For instance, if I am looking to buy some machine*
>
>
>
>
>
> *screws I care more about the attribute "hardware store" than
> anyparticular name of such a store.  In that vein I sense that it might bea
> useful endeavor to create a list of attribute types [and for each
> some definition of the possible values].  I'm thinking something like
> theDublin Core metadata definitions, but of more universal
> applicability.  To make use of such a world in which things are known by
> theirattributes as much as by their names we would need new protocol
> and server machinery to do the kind of soft lookups that attribute
> systemsneed.  As is my tendency, I sense that such things might well learn
> from the biological world in which "adequate matching" is often a key
> tosurvival."*
>
> 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.
> 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.
>
> To the larger point you make on accommodating innovation from the edge,
> one of my friends, Evan Leibovitch, has been arguing for years
> that a reckoning is coming and will come to the DNS by several
> usurpations, among them implementations based on attribute systems.
> History will absolve him, I think.
>
> Carlton
>
>
>
>
> ==============================
> *Carlton A Samuels*
>
> *Mobile: 876-818-1799Strategy, Process, Governance, Assessment &
> Turnaround*
> =============================
>
>
> On Sun, 20 Feb 2022 at 23:36, Karl Auerbach via At-Large <
> at-large at atlarge-lists.icann.org> wrote:
>
>> As a personal issue I think the notion of emojis in DNS is little more
>> than a concession to a (hopefully) passing childish fad.
>>
>> And from a security perspective (not to mention the confusion of users
>> in genera) I have a intuitive sense that it is a fad that contains seeds
>> of trouble.
>>
>> But I'm just one person out of billions of us.  I don't use emojis, but
>> it seems that a lot of us do.
>>
>> And I don't want to be like the voice of Ma Bell in the 1960's loudly
>> proclaiming that packet switching and the attachment of foreign devices
>> were something to be avoided and banned.
>>
>> So how do I decide?
>>
>> So using the rubric of my "first law of the internet" I start with the
>> position of "emojis ought to be allowed" on the basis of them being of
>> private benefit (although I personally find it hard to see that benefit
>> or credit it with value.)
>>
>> Then I say "but is there a public detriment and if so is it substantial
>> enough to block that private benefit?"
>>
>> As things stand right now I can't clearly and concretely articulate the
>> public detriments (although I feel that they are out there) much less
>> measure them.
>>
>> Which, according to my rule means that I would conclude to take no
>> action (at this time) against emojis in domain names.  But I'd suggest
>> inquiries and research to obtain more concrete information about the
>> issue.  (Yes, I realize that my conclusion contains a strong possibility
>> that we could end up with an deeply entrenched ill practice.)
>>
>> Part of this is informed by my belief that the domain name system is
>> slowly fading from the public eye; that we are moving into a world in
>> which DNS names are becoming more a part of the hidden machinery of the
>> net (like MAC addresses) and that higher level naming abstractions,
>> things like Twitter names or Facebook handles, are becoming the more
>> prevalent forms of naming on the net.
>>
>> I also am of the belief that on the net attributes are often more
>> important than names.  For instance, if I am looking to buy some machine
>> screws I care more about the attribute "hardware store" than any
>> particular name of such a store.  In that vein I sense that it might be
>> a useful endeavor to create a list of attribute types [and for each some
>> definition of the possible values].  I'm thinking something like the
>> Dublin Core metadata definitions, but of more universal applicability.
>> To make use of such a world in which things are known by their
>> attributes as much as by their names we would need new protocol and
>> server machinery to do the kind of soft lookups that attribute systems
>> need.  As is my tendency, I sense that such things might well learn from
>> the biological world in which "adequate matching" is often a key to
>> survival.
>>
>>         --karl--
>>
>>
>> On 2/20/22 17:29, Alejandro Pisanty wrote:
>> > Karl,
>> >
>> > TL;DR, QED for no emojis in DNS. Thanks.
>> >
>> > Alejandro Pisanty
>> >
>> > On Sun, Feb 20, 2022 at 3:52 PM Karl Auerbach via At-Large
>> > <at-large at atlarge-lists.icann.org
>> > <mailto:at-large at atlarge-lists.icann.org>> wrote:
>> >
>> >     On 2/20/22 8:52 AM, sivasubramanian muthusamy via At-Large wrote:
>> >
>> >      > What does ICANN think about private and often proprietary
>> >      > 'innovations' that aspire to "cause a major shift in the way the
>> >      > Internet [DNS] works" ?
>> >      >
>> >     Remember, the Internet came from a rejection of the status-quo, the
>> >     world of circuit switching and central control.
>> >
>> >     The question you asked is not far distant from a question whether we
>> >     ought to nail down the Internet in the same way the telcos of the
>> first
>> >     three quarters of the 20th century ossified the telephone networks.
>> >
>> >     Ma Bell and other telco's imposed extreme, and often arbitrary,
>> limits
>> >     on innovation at the edges. Take a look at the 1956 US case
>> regarding
>> >     the Hush-a-Phone. (In that case AT&T tried to block the attachment
>> of
>> >     what was essentially a plastic hand that would be attached by the
>> user
>> >     to the mouthpiece of a telephone. At&T made wild claims that that
>> would
>> >     cause the telephone network to collapse and repairmen would blown
>> off
>> >     the top of telephone poles.)  Then look at the Carterphone and MCI
>> >     cases.
>> >
>> >     One of the hallmarks of the Internet is permissionless innovation at
>> >     the
>> >     edges. Clearly there are balances to be made, but we risk a balance
>> >     that
>> >     pushes too much control to the center.
>> >
>> >     Some decades ago I distilled this balance into a short formulation:
>> >
>> >     First Law of the Internet
>> >
>> >     + Every person shall be free to use the Internet in any way
>> >         that is privately beneficial without being publicly
>> >         detrimental.
>> >
>> >          - The burden of demonstrating public detriment shall
>> >            be on those who wish to prevent the private use.
>> >
>> >              - Such a demonstration shall require clear and
>> >                convincing evidence of public detriment.
>> >
>> >          - The public detriment must be of such degree and extent
>> >            as to justify the suppression of the private activity.
>> >
>> >     https://www.cavebear.com/old_cbblog/000059.html
>> >     <https://www.cavebear.com/old_cbblog/000059.html>
>> >
>> >               --karl--
>> >
>> >
>> >     _______________________________________________
>> >     At-Large mailing list
>> >     At-Large at atlarge-lists.icann.org
>> >     <mailto:At-Large at atlarge-lists.icann.org>
>> >     https://atlarge-lists.icann.org/mailman/listinfo/at-large
>> >     <https://atlarge-lists.icann.org/mailman/listinfo/at-large>
>> >
>> >     At-Large Official Site: http://atlarge.icann.org
>> >     <http://atlarge.icann.org>
>> >     _______________________________________________
>> >     By submitting your personal data, you consent to the processing of
>> >     your personal data for purposes of subscribing to this mailing list
>> >     accordance with the ICANN Privacy Policy
>> >     (https://www.icann.org/privacy/policy
>> >     <https://www.icann.org/privacy/policy>) and the website Terms of
>> >     Service (https://www.icann.org/privacy/tos
>> >     <https://www.icann.org/privacy/tos>). You can visit the Mailman
>> link
>> >     above to change your membership status or configuration, including
>> >     unsubscribing, setting digest-style delivery or disabling delivery
>> >     altogether (e.g., for a vacation), and so on.
>> >
>> >
>> >
>> > --
>> > - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> >       Dr. Alejandro Pisanty
>> > Facultad de Química UNAM
>> > Av. Universidad 3000, 04510 Mexico DF Mexico
>> > +525541444475
>> > Blog: http://pisanty.blogspot.com <http://pisanty.blogspot.com>
>> > LinkedIn: http://www.linkedin.com/in/pisanty
>> > <http://www.linkedin.com/in/pisanty>
>> > Unete al grupo UNAM en LinkedIn,
>> > http://www.linkedin.com/e/gis/22285/4A106C0C8614
>> > <http://www.linkedin.com/e/gis/22285/4A106C0C8614>
>> > Twitter: http://twitter.com/apisanty <http://twitter.com/apisanty>
>> > ---->> Unete a ISOC Mexico, http://www.isoc.org <http://www.isoc.org>
>> > .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
>> _______________________________________________
>> At-Large mailing list
>> At-Large at atlarge-lists.icann.org
>> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>>
>> At-Large Official Site: http://atlarge.icann.org
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your
>> personal data for purposes of subscribing to this mailing list accordance
>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
>> the website Terms of Service (https://www.icann.org/privacy/tos). You
>> can visit the Mailman link above to change your membership status or
>> configuration, including unsubscribing, setting digest-style delivery or
>> disabling delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> At-Large mailing list
> At-Large at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>
> At-Large Official Site: http://atlarge.icann.org
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20220221/c017425a/attachment-0001.html>


More information about the At-Large mailing list