As far as the tables go, with BCP47 we defined the initial contents of the language-subtag registry in a document (that became RFC4645) that was separate from all the 'real' specifications. Once BCP47 went live, and the contents started being hosted on IANA, the lists in that document were not necessary, and it was published with the following section:<br>
<br><div style="margin-left: 40px;">3. Initial Registry Contents<br><br> The remainder of this section specified the initial set of records<br> for the registry. This material was deleted on publication of this<br> memo, to avoid any potential confusion with the registry itself. The<br>
IANA language subtag registry can be found at<br> <<a href="http://www.iana.org/numbers.html">http://www.iana.org/numbers.html</a>> under "Language Tags".<br></div><br>I'd suggest doing the same here.<br>
<br>Then we could have three docs:<br><ul><li>protocol* (incorporates bidi.txt, normative part of tables.txt, normative part of rationale.txt)</li><li>tables* ( the long lists from tables.txt, the context rules, exception lists: all to go onto IANA and be updated there with successive versions of Unicode and any the Expert Reviewer Committee's changes)</li>
<li>rationale* (the non-normative part of rationale, however much we want there)</li></ul>Mark
<br><br><div class="gmail_quote">...<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I've no problem with the document structure, and<br>
long drafts with more than 92 pages can be hard<br>
to read. If the bulk of the "tables" would go<br>
in a IANA registry later, not in the published<br>
RFC (same idea as in 4645bis, or before in the<br>
4645 drafts), joining three I-Ds can make sense.</blockquote><div>... <br></div></div><br>