[lac-discuss-es] Fwd: Singular / Plural en los nuevos gTLD

carlton.samuels en gmail.com carlton.samuels en gmail.com
Mie Sep 4 19:29:18 UTC 2013


[[--Translated text (en -> es)--]]

 Asunto: Fwd: Singular / Plural en los nuevos gTLD 
 Desde: carlton.samuels en gmail.com

 ============================== 
 Carlton Un Samuels 
 Móvil: 876-818-1799 
 * Estrategia, Planificación, Gobierno, Evaluación y Turnaround * 
 ============================= 




 ---------- Mensaje reenviado ---------- 
 De: Evan Leibovitch <evan en telly.org>
 Fecha: Miércoles, 04 de septiembre 2013 a las 11:48 AM 
 Asunto: Re: [ALAC] Singular / Plural de nuevos gTLD 
 A: Rinalia Abdul Rahim <rinalia.abdulrahim en gmail.com>
 Cc: Lista de trabajo ALAC <alac en atlarge-lists.icann.org>




 El 04 de septiembre 2013 10:44, Rinalia Abdul Rahim <rinalia.abdulrahim en gmail.com 
> wrote:
> They would have to be bundled and allocated to the same entity, Alan. No
> other way around it.
>








 Como se ha dicho, plurales y singulares podrían añadirse a la misma 
 conjunto en disputa.Es decir, las solicitudes de. &quot;Hoteles&quot; y las solicitudes de 
 . &quot;Hotel&quot; se agrupan como si fueran múltiples aplicaciones para el 
 misma cadena. Cualquier solicitante que aplica para ambos plural y singular - 
 probablemente defensiva - podrían solicitar un reembolso por un caso de que 
 elegir. Eso no significa que el solicitante ganador obtendría ambos. Habían 
 obtener la solicitaron y el otro (s) serían sin asignar. 


 Tener singulares y plurales de una cadena en la delegación paralelo - aunque 
 Del mismo registro - seguiría siendo una fuente de confusión para el consumidor. 


 - Evan 
 > 
> Best,
>
> Rinalia
> On Sep 4, 2013 10:42 PM, "Alan Greenberg" <alan.greenberg en mcgill.ca>
> wrote:
>
> >  Thanks Rinalia.
> >
> > Regarding 1, yes, is the decision were revered, it would establish some
> > new (or larger) contenction sets.
> >
> > On blocking a name so that it is only one of the TLDs (or alternatively
> > bundling them together), a bit problematic if the two TLDs are operated
> by
> > different registries.
> >
> > Alan
> >
> > At 04/09/2013 12:53 AM, Rinalia Abdul Rahim wrote:
> >
> > Dear Alan,
> >
> > I support doing something about this.
> >
> > 2 thoughts:
> > 1. A positive result of intervention on this matter where singular and
> > plural strings are deemed similarly confusing (and thus not allowed)
> > result in the strings implicated to be in contention. This will no doubt
> > heat up the string contention and objection resolution process. No
> > judgment in this, just stating an observation of what to expect.
> >
> > 2. There is a practice in IDN variant management that can theoretically
> be
> > applied to avoid applicants from having to "buy" two confusingly similar
> > names (if the policy is not to allow singular and plural names). This is
> > the practice/rule of allocating both names to an applicant and then
> > blocking one of those names or allowing both names (perhaps for the
> > of one - need to check on whether they charge for the "variants" - I
> > suspect not). And yes, the IP-interested folks might have something to
> say
> > about it depending on whether they are in favor of over-protection or
> less.
> >
> > Best regards,
> >
> > Rinalia
> > On Sep 4, 2013 12:29 PM, "Alan Greenberg" <alan.greenberg en mcgill.ca >
> > wrote:
> >  That could be done. But first I wanted to find out if there was any
> > interest within the ALAC. If there is little interest, I will do
> something
> > on my own, but with far less impact than if it is advice from the ALAC.
> >
> > Also note that this is an issue that is extremely time-sensitive, since
> if
> > the issue is to be re-opened, it will have to be done very quickly.
> >
> > Alan
> >
> > At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
> >  Dear Alan,
> >
> > Thank you for monitoring this space. I would suggest opening the
> > discussions within the broader At Large to solicit views and feedback,
> > preferably if the discussions could ensue on both the mailing list as
> well
> > as the wiki before a statement is drafted.
> >
> > Kind Regards,
> > Sala
> >
> > Sent from my iPad
> >
> > On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg en mcgill.ca >
> > wrote:
> >
> > > On 24 June 2013 as requested by the GAC, the Board New gTLD Program
> > Committee (NGPC) considered the issue of singular and plural stings
> > confusingly similar and decided to let the original process stand
> (subject
> > to individual objections). The record of the decision can be found at
> >
>
 . 
> Of particular note is a statement issued by three Board members (George
> > Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the
> > decision but regretted that, based on the Applicant Guidebook wording,
> they
> > did not believe that they had the leeway to vote against it. One Board
> > member (Mike Silber) did oppose the decision.
> > >
> > > A central issue is that "confusingly similar" test relies purely on
> > visual similarity and in the eyes of most (who were involved in the
> > decision), adding an "S" makes it a recognizably different string.
> > >
> > > The salient part of the Applicant Guidebook (
> http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf)
> is section 2.2.1.1 of Module 2.
> > >
> > >> This review involves a preliminary comparison of each applied-for
> > string against existing TLDs, Reserved Names (see subsection 2.2.1.2),
> and
> > other applied-for strings. The objective of this review is to prevent
> user
> > confusion and loss of confidence in the DNS resulting from delegation of
> > many similar strings.
> > >>
> > >> Note: In this Applicant Guidebook, "similar" means strings so similar
> > that they create a probability of user confusion if more than one of the
> > strings is delegated into the root zone.
> > >>
> > >> The visual similarity check that occurs during Initial Evaluation is
> > intended to augment the objection and dispute resolution process (see
> > Module 3, Dispute Resolution Procedures) that addresses all types of
> > similarity.
> > >
> > > I believe that the NGPC decision was incorrect. The problem is the
> > belief that "visual similarity" relies purely on what, in computer
> > terminology, would be called "pattern matching". Pattern matching is
> > certainly part of human perception, but it is not limited to that. At
> issue
> > is whether two strings will be PERCEIVED as being equivalent, and
> > perception is a far more complex (and less understood) issue.
> > >
> > > The real issue is that if you earlier found something at hilton.hotel,
> > or had decided that the reviews at sheraton.hotel were something you
> > trusted, will you later remember if it was really those sites or
> > hilton.hotels or sheraton.hotels?
> > >
> > > At best, this could be considered a means of forcing anyone who
> > registers a domain with .hotel or .hotels to register both, and map both
> of
> > them to the same site. If that were to happen, the predictions of the
> > Intellectual Property Constituency would be borne out, and all of those
> > using these TLDs would have to make double the investment in domain
> > (presuming this is even possible with differing rules for each TLD). But
> > the impact on users would be minimal.
> > >
> > > But since we cannot guarantee that both TLDs will remain forever in
> > sync, we do have a user problem. Once cannot expect the typical Internet
> > user to be able to differentiate between two such name spaces, and
> > therefore I believe that we have a genuine case of "confusingly
> > And one that will arguably have as much or more impact on real Internet
> > users, the ones that we are supposed to be here to defend, than any
> > case I can recall in my 7 year involvement with ICANN At-Large.
> > >
> > > If others on the ALAC agree, I would be happy to create a statement
> > reflecting what I have said here, that we can, in our formal Advisory
> > Committee role, forward as Advice to the Board.
> > >
> > > Alan
> > >
> > > _______________________________________________
> > > ALAC mailing list
> > > ALAC en atlarge-lists.icann.org
> > > https://atlarge-lists.icann.org/mailman/listinfo/alac
> > >
> > > At-Large Online: http://www.atlarge.icann.org
> > > ALAC Working Wiki:
> >
>
> >
> >
> > _______________________________________________
> > ALAC mailing list
> >  ALAC en atlarge-lists.icann.org
> >  https://atlarge-lists.icann.org/mailman/listinfo/alac
> >
> > At-Large Online: http://www.atlarge.icann.org
> > ALAC Working Wiki:
> >
>
> >
> >
> _______________________________________________
> ALAC mailing list
> ALAC en atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
>
 > 






 - 
 Evan Leibovitch 
 Toronto Canada 


 Em: evan a tele dot org 
 Sk: evanleibovitch 
 Tw: el56 
 _______________________________________________ 



[[--Original text (en)
http://mm.icann.org/transbot_archive/a7defb3603.html
--]]




Más información sobre la lista de distribución lac-discuss-es