Closed Lockhead closed 7 years ago
any remarks to this topic? I'm pretty sure the IETF people will raise this question and it should be covered in the document to simply anticipate that...
There are multiple ways to do it:
We picked a single way to do BIMI, and not support multiple methods. That reduces operational complexity to do it one way, vs. two different ways. Each method has its pros and cons, but we are sticking with just one.
The advantage of DNS is that it can support more than just email, and images can also be dynamically resolved (i.e., publish a new image in the drop location) which you can't do with a header.
But the whole doc is written exclusivly for mail as the only channel. It only want's to register the header for mail, perhaps we should work on a more open version that simply brings in mail as it's first big example but also offers the usage in HTTP response headers, that would allow a HEAD request to construct an icon for website.
Your argument for DNS is feeble, as the header is static in both cases, you can also replace the image in the header only variant without any issues. But I can totally understand why DNS is favored over the static header. You or we need to bring that into the document.
Who is the audience that this more open version is supposed to be for? Do we have any implementers? For email, we have several implementers, all at large receivers or email client maintainers. To make a specific version for them AND a more general version for others expands the scope of the work and delays implementation.
Since if we don't have more general implementers other than email, we have a doc that can be extended in the future but is currently scoped to email. And since it is scoped to email, we had to pick and choose what methods we wanted to support. Additional complexity is a deployment blocker (since an implementer would now have to code up multiple mechanisms, and test them). Rather than adding operational complexity, we picked a single way and lived with the trade-offs.
It could be used as a favicon replacement and I think browser vendors would be happy to have something like this, because of the same reason we want that for email. But yeah you are right, concentrating on the actual need is the way to go. Offtopic are there any thoughts about my pull request? (I only added the author stuff like @AntiFreeze did, I'm fine as a silent contributer) But I reworded the example and think this would fit better.
I'll look into this soon and let you know
On Fri, Apr 7, 2017 at 9:57 AM, Tobias Herkula notifications@github.com wrote:
It could be used as a favicon replacement and I think browser vendors would be happy to have something like this, because of the same reason we want that for email. But yeah you are right, concentrating on the actual need is the way to go. Offtopic are there any thoughts about my pull request? (I only added the author stuff like @AntiFreeze https://github.com/AntiFreeze did, I'm fine as a silent contributer) But I reworded the example and think this would fit better.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/authindicators/rfc-brand-indicators-for-message-identification/issues/3#issuecomment-292592058, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKPFlffy85dm8BAQL0_-MSAPhITYEJ_ks5rtmsGgaJpZM4MbZsJ .
--
[image: logo for sig file.png]
Bringing Trust to Email
Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724>
The current version of the document substantially reworked how this is communicated. It covers why DNS and not a header is the vector for image suggestion, and how the BIMI-Location header is constructed and trust is relayed.
Can you confirm if the latest document refresh has addressed all your concerns from this issue and your pull request?
Wouldn't it be easier if the sender simply puts the BIMI-location Header into the mail? You still have to track all the stuff but you would avoid additional DNS requests and if the Header is in the list of signed headers in the corresponding DKIM signature you can still use that as trust anchor.