<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Offering a previously stated suggestion.<br>
<br>
"Editorial changes" (the definitions 1 and 2 from W3C Process
Document seem reasonable) must be proposed to the public list and
clearly identified as such. If any voting member objects and
considers such change as "not editorial", then the formal ballot
process shall take place. if no objections are raised, then these
editorial changes shall be applied along with changes approved via
the next upcoming ballot.<br>
<br>
Does this make sense?<br>
Dimitris.<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/12/2017 9:14 μμ, Virginia Fournier
via Public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6044E3CC-8A9B-4A37-882F-253DB933E97E@apple.com">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 class="" color="#0433ff">1. No changes
to text content</font></dt>
<dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font
class="" color="#0433ff">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 class="" color="#0433ff">2.
Corrections that do not affect conformance</font></dt>
<dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font
class="" color="#0433ff">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
class="" color="#0433ff">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 class="" color="#0433ff">3.
Corrections that do not add new features</font></dt>
<dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font
class="" color="#0433ff">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 class="" color="#0433ff">makes
conforming data, processors, or other conforming
agents become non-conforming according to the new
version, or</font></li>
<li class=""><font class="" color="#0433ff">makes
non-conforming data, processors, or other agents
become conforming, or</font></li>
<li class=""><font class="" color="#0433ff">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 class="" color="#0433ff">4. New
features</font></dt>
<dd style="margin-top: 0px; margin-bottom: 0px;" class=""><font
class="" color="#0433ff">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=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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="" moz-do-not-send="true">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="" moz-do-not-send="true">Kirk.Hall@entrustdatacard.com</a>>;
CA/Browser Forum Public Discussion List <<a
href="mailto:public@cabforum.org" class=""
moz-do-not-send="true">public@cabforum.org</a>>; Ryan
Sleevi <<a href="mailto:sleevi@google.com" class=""
moz-do-not-send="true">sleevi@google.com</a>><br class="">
Cc: Virginia Fournier <<a href="mailto:vfournier@apple.com"
class="" moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>