<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Maybe we could state that “editorial” changes could be made without restarting the discussion period. “Editorial” could be defined something like 1 and 2 below (taken from the W3C Process Document):<div class=""><br class=""></div><div class=""><h4 id="correction-classes" style="font-size: medium; line-height: normal; font-family: sans-serif;" class="">6.2.5 Classes of Changes</h4><p style="font-family: sans-serif;" class="">This document distinguishes the following 4 classes of changes to a specification. The first two classes of change are considered <dfn id="editorial-change" class="">editorial changes</dfn>, the latter two <dfn id="substantive-change" class="">substantive changes</dfn>.</p><dl style="font-family: sans-serif;" class=""><dt style="margin-top: 0px; margin-bottom: 0px; font-weight: bold;" class=""><font color="#0433ff" class="">1. No changes to text content</font></dt><dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font color="#0433ff" class="">These changes include fixing broken links, style sheets or invalid markup.</font></dd><dt style="margin-top: 0px; margin-bottom: 0px; font-weight: bold;" class=""><font color="#0433ff" class="">2. Corrections that do not affect conformance</font></dt><dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font color="#0433ff" class="">Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements and do not fall into this class.</font></dd><dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font color="#0433ff" class="">Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or dissent as to whether requirements are changed, such changes do not fall into this class.</font></dd><dt style="margin-top: 0px; margin-bottom: 0px; font-weight: bold;" class=""><font color="#0433ff" class="">3. Corrections that do not add new features</font></dt><dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font color="#0433ff" class="">These changes <em class="rfc2119" style="font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-caps: small-caps; font-variant-alternates: normal; font-variant-position: normal; font-variant-east-asian: normal;">may</em> affect conformance to the specification. A change that affects conformance is one that:</font><ul class=""><li class=""><font color="#0433ff" class="">makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or</font></li><li class=""><font color="#0433ff" class="">makes non-conforming data, processors, or other agents become conforming, or</font></li><li class=""><font color="#0433ff" class="">clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.</font></li></ul></dd><dt style="margin-top: 0px; margin-bottom: 0px; font-weight: bold;" class=""><font color="#0433ff" class="">4. New features</font></dt><dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font color="#0433ff" class="">Changes that add a new functionality, element, etc.</font></dd></dl><div class="">Best regards,<br class=""><br class="">Virginia Fournier<br class="">Senior Standards Counsel<br class=""> Apple Inc.<br class="">☏ 669-227-9595<br class="">✉︎ <a href="mailto:vmf@apple.com" class="">vmf@apple.com</a><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""></div><br class="">On Dec 8, 2017, at 10:29 AM, Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com" class="">Kirk.Hall@entrustdatacard.com</a>> wrote:<br class=""><br class="">Gerv, this started as your ballot, so it's up to you - do you want to allow such minor edits without restarting the discussion period, or not?<br class=""><br class="">If yes, you need to put defining / permissive language in the ballot. I won't be comfortable if we have no written permission for edits, but then allow them informally later when ballots have errors - it needs to be in the ballot.<br class=""><br class="">-----Original Message-----<br class="">From: Gervase Markham [<a href="mailto:gerv@mozilla.org" class="">mailto:gerv@mozilla.org</a>] <br class="">Sent: Friday, December 8, 2017 1:23 PM<br class="">To: Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com" class="">Kirk.Hall@entrustdatacard.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>>; Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>><br class="">Cc: Virginia Fournier <<a href="mailto:vfournier@apple.com" class="">vfournier@apple.com</a>><br class="">Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period<br class=""><br class="">On 08/12/17 18:17, Kirk Hall via Public wrote:<br class=""><blockquote type="cite" class="">Just putting the question to you in the abstract – do you think we <br class="">should have to restart a seven day discussion just to correct an <br class="">obvious typo?<br class=""></blockquote><br class="">Let us say the answer to that question is "no". Then the obvious next question is: "how do you, the proponent of this idea, define 'obvious typo' in a way which does not open the door to substantive changes, or changes which people would argue about the substantiveness of, and without inventing Yet Another Voting/Polling Mechanism"?<br class=""><br class="">Gerv<br class=""><br class=""></div></body></html>