<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 8, 2018 at 10:30 PM Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9221861048706639590WordSection1"><p class="MsoNormal">From: <a href="mailto://tim.hollebeek@digicert.com" target="_blank">mailto://tim.hollebeek@digicert.com</a><u></u><u></u></p><p class="MsoNormal">To: <a href="mailto://sleevi@google.com" target="_blank">mailto://sleevi@google.com</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">To make it clear, I don’t think turning things into URIs adds value for customers.  E-mail addresses usually AREN’T in the form of URIs, as noted above.</p></div></div></blockquote><div><br></div><div>Except, again, this is dodging the point that Corey raised, and which you haven't at all addressed, in which you're proposing a form that leaves it entirely ambiguous to the CA, and subjective to their interpretation, as to the form - and ambiguous for customers.</div><div><br></div><div>If your view is that you're being customer focused, then that's not really sustained by any of the positions being advocated here. The ambiguity you're arguing is a strength is going to lead to misissued certificates and confused customers. The fact that there's multiple ways to do it - URI (CAA) vs non-URI (TXT) - is going to lead to confusion. The fact that you're arguing the non-URI form is the preferred approach, while TXT is the legacy approach, is entirely logically inconsistent.</div><div><br></div><div>Your proposals don't make sense. And they don't stand serious scrutiny on their merits.</div><div><br></div><div>Lets say, however, that you decide to say that the CAA value should match the contents of the TXT value, and that both need to be 'some' form of email address. You need to define what that format is going to be, in a clear, consistent, and unambiguous form. As you do so, it's going to be inconsistent with how the iodef field is defined, adding more complexity - and the very risk of error you're seemingly trying to avoid.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9221861048706639590WordSection1"><p class="MsoNormal">My position is easy to square given that I originally didn’t want to have URIs in the original proposal.  It was only added in an attempt to gain support for the ballot.  Since that doesn’t seem to have worked, I think we should seriously consider returning to the customer friendly form for all use cases.  </p></div></div></blockquote><div><br></div><div>You haven't demonstrated it's customer friendly. Nor have you demonstrated how the form you're proposing can actually achieve those goals, because, as it stands, what is written and what has been proposed is CA-hostile and user-hostile.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9221861048706639590WordSection1"><p class="MsoNormal">Especially if, as seems common recently, any attempt to address objections to proposals just results in an endless series of more objections. </p></div></div></blockquote><div><br></div><div>You haven't put forward any attempt that meaningfully addresses the objections though. What you see as an endless series of more objections is the same objections being highlighted as unmet, and multiple attempts to highlight why that's the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9221861048706639590WordSection1"><p class="MsoNormal">Also, as usual, your tone is unhelpful.  It’s best to be respectful of other people’s positions and attempts to overcome objections, especially if they’re working hard to address your concerns.  I can certainly stop doing that, and work with the rest of the WG instead, if you want.</p></div></div></blockquote><div><br></div><div>I haven't seen any attempt that actually addresses the concerns raised. And I don't think these objections you're making to using URIs consistently - between CAA properties and between CAA and TXT - are at all reasonable, because they're not at all internally consistent. At best, it's "Tim doesn't like them". And that's profoundly unhelpful. I don't think <a href="https://en.wikipedia.org/wiki/Tone_policing">tone policing</a> is going to overcome the structural deficiencies with your proposal either.</div></div></div>