<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>SG16 will hold a telecon on Wednesday, January 12th at 19:30 UTC
      (<a
href="https://www.timeanddate.com/worldclock/converter.html?iso=20220112T193000&amp;p1=1440&amp;p2=tz_pst&amp;p3=tz_mst&amp;p4=tz_cst&amp;p5=tz_est&amp;p6=tz_cet"
        moz-do-not-send="true">timezone conversion</a>).</p>
    <p>The agenda is:</p>
    <ul>
      <li>D2286R5: Formatting Ranges</li>
      <ul>
        <li>Review pending availability of proposed wording and
          continued targeting of C++23.</li>
      </ul>
      <li><a moz-do-not-send="true" href="https://wg21.link/p2491r0">P2491R0:
          Text encodings follow-up</a></li>
      <ul>
        <li>Initial review.</li>
      </ul>
      <li><a moz-do-not-send="true" href="https://wg21.link/p2498r0">P2498R0:
          Forward compatibility of text_encoding with additional
          encoding registries</a></li>
      <ul>
        <li>Initial review.<br>
        </li>
      </ul>
    </ul>
    <p>I don't yet have confirmation of the existence of a D2286R5 so,
      unless I hear otherwise, the first item on the agenda won't
      happen.<br>
    </p>
    <p>We last reviewed a draft of <a moz-do-not-send="true"
        href="https://wg21.link/p2286r4">P2286R4</a> during the <a
        moz-do-not-send="true"
href="https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#december-15th-2021">2021-12-15
        SG16 telecon</a> where we approved forwarding it to LEWG despite
      the absence of wording. Prior to that, we had reviewed <a
        moz-do-not-send="true" href="https://wg21.link/p2286r3">P2286R3</a>
      during the <a moz-do-not-send="true"
href="https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#december-1st-2021">2021-12-01
        SG16 telecon</a>. LEWG has since reviewed the proposal during
      its <a moz-do-not-send="true"
href="https://wiki.edg.com/bin/view/Wg21telecons2022/P2286?twiki_redirect_cache=e1d7621f93ffd926fb2c8172a10fead5">2022-01-04
        telecon</a> and plans to review again during its 2022-01-18
      telecon. In this telecon, we'll review the available wording to
      look for new SG16 concerns and to validate the wording reflects
      previous design guidance. Previous design discussion related to
      the following concerns:</p>
    <ol>
      <li>Use of <a href="https://wg21.link/p2290">P2290</a> style
        brace delimited hexadecimal notation to preserve the values of
        code units that appear in an ill-formed code unit sequence.</li>
      <li>Use of <a moz-do-not-send="true"
          href="https://wg21.link/p2290">P2290</a> style brace delimited
        UCN notation (as opposed to hexadecimal notation) for
        non-printable characters.</li>
      <li>Whether it is always possible to map an input character to a
        Unicode character for the purpose of determining printability.</li>
      <li>How characters are determined to be printable or
        non-printable.</li>
      <li>Handling of lone surrogate characters; whether they are
        encoded in UCN notation (like a non-printable character) or in
        hexadecimal notation (like an invalid code unit).<br>
      </li>
      <li>Handling of unassigned code points.</li>
      <li>Handling of Private Use Area (PUA) code points.</li>
      <li>How to determine the boundaries of ill-formed code unit
        sequences.</li>
      <li>Whether a replacement character should be emitted for an
        ill-formed code unit sequence (as opposed to emitting
        hexadecimal notation for each contributing code unit).</li>
      <li>Stability guarantees.</li>
      <li>Support for non-Unicode platforms.</li>
      <li>Handling of <font face="monospace">std::filesystem::path</font>.</li>
    </ol>
    <p><a moz-do-not-send="true" href="https://wg21.link/p2491r0">P2491R0</a>
      proposes changes to P1885; primarily with regard to handling of
      wide encodings. The recently communicated <a
        moz-do-not-send="true"
        href="https://isocpp.org/files/papers/D1885R9.pdf">D1885R9</a>
      draft revision removes support for wide encodings thus making much
      (but not all) of what P2491R0 proposes moot.<br>
    </p>
    <p> <a moz-do-not-send="true" href="https://wg21.link/p2498r0">P2498R0</a>
      also proposes changes to P1885 to make way for the possibility of
      supporting different encoding registrars in the future. Note that
      the ISO does specify its own registry of encodings that have been
      registered for use with <a moz-do-not-send="true"
        href="https://www.iso.org/standard/22747.html">ISO/IEC 2022</a>.
      The registry is called ISO-IR (officially, "INTERNATIONAL REGISTER
      OF CODED CHARACTER SETS TO BE USED WITH ESCAPE SEQUENCES") and the
      registration procedures are specified in <a
        moz-do-not-send="true"
        href="https://www.iso.org/standard/32184.html">ISO/IEC 2375</a>.
      Unfortunately, I don't think any of these publications is freely
      available, though copies can be found online. <a
        moz-do-not-send="true"
        href="https://www.iso.org/standard/22747.html">ISO/IEC 2022</a>
      is also published as <a moz-do-not-send="true"
href="https://www.ecma-international.org/publications-and-standards/standards/ecma-35/">ECMA-35</a>.<br>
    </p>
    <p>Please review the updates made to <a
        href="https://isocpp.org/files/papers/D1885R9.pdf">D1885R9</a>
      prior to this telecon for applicability to our review of the
      latter two papers.<br>
    </p>
    <p>Tom.<br>
    </p>
  </body>
</html>

