Subject: [Bimi] Logo/Trademark conflict

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Apr 2019 09:10:31 -0700

Relative to the general topic of international trademarks, conflicts for 
domain names are pretty simple.

And yet this isn't that unusual or even unexpected:

      ICANN takes the reins again as .amazon talks fail

http://domainincite.com/24133-icann-takes-the-reins-again-as-amazon-talks-fail?fbclid=IwAR1klnGGJtlFSdbE_OvNLUCSgD_uuhKGttRaKcsRzF7pwC7nQaN1dn8SAjM

When the design of Bimi can deal with resolving this sort of problem, it 
will be reasonable to consider it more substantially.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Wed, 10 Apr 2019 18:20:49 +0200

> will be reasonable to consider it more substantially.

You could say the same thing about DNS or gTLD registrations. Legal
conflicts like this are outside the scope of what an interoperability spec
can reasonably address. No?

Seth

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Apr 2019 09:26:19 -0700

On 4/10/2019 9:20 AM, Seth Blank wrote:
> On Wed, Apr 10, 2019 at 6:10 PM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> conflicts like this are outside the scope of what an interoperability 
> spec can reasonably address. No?

If there is no viable operational framework for a technical standard, 
then producing the standard is a study in -- at best -- futility or -- 
more likely -- a rich array of deception and significant damage.

This barrier to Bimi's working at scale has been noted constantly since 
the first Bimi talks.  Nothing about that barrier has changed.

d/

---

From: Seth Blank <[email-masked]>
Date: Wed, 10 Apr 2019 18:30:56 +0200

> the first Bimi talks.  Nothing about that barrier has changed.

We went through these issues in detail at the BoF and discussed our
starting point for addressing them, which we agree doesn't cover use cases
at scale. Your example from this thread is similar to the Stripe of
Delaware vs Stripe of Kentucky attack we discussed, but without any intent
to deceive. What is your suggestion for addressing these issues?

-- 

Seth Blank | Director, Industry Initiatives

e: [email-masked] |* p: *415-273-8818

<https://www.valimail.com/>

<https://twitter.com/valimail> <https://twitter.com/valimail>
<https://www.linkedin.com/company/valimail/>
<https://www.linkedin.com/company/valimail/>
<https://www.facebook.com/ValiMail-649042791951699>
<https://www.facebook.com/Valimail-649042791951699/>

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it.  If you are not an intended and authorized
recipient you are hereby notified any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful.  Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Apr 2019 12:00:17 -0700

On 4/10/2019 9:30 AM, Seth Blank wrote:
> starting point for addressing them, which we agree doesn't cover use 
> cases at scale.

IMO, unless and until there are use cases for this working at scale, the 
effort won't work at scale.  It might not work then, either, but this at 
least is a foundational requirement for serious discussions.

 > What is your suggestion for addressing these issues?

Besides advising that there be serious discussions that start with a 
robust characterization of the problem space for working at scale, I've 
no idea how to 'solve' this.  Given at least 120 years of discussion in 
this space, it's unlikely anyone else does, either.

Problems with such discouraging histories sometimes do get solved.  But 
never by ignoring the challenges they post.

d/