DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
 h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth;
 b=DrhZlcXgfFqxBJHekbhsFRk9j+Duy4JHPKcUU9eDNBIbOyLxZsLX9g7Xw+YwCWuaBTLF1xB8TkrHOS5iXXcoPGIJ6jabFOGfpXC+AedqtRRG8NbUtDd0qlNixt1xO/xb2ZzetZu3W6OcHgWfIrl9R5yHVn+9NX3f2xOoDDBFgps=
Message-ID: <30b660a20707011618m67fe32e6n73e81f8d3bddd69d@mail.gmail.com>
Date: Sun, 1 Jul 2007 16:18:30 -0700
From: "Mark Davis" <mark.davis@icu-project.org>
To: "LTRU Working Group" <ltru@ietf.org>
MIME-Version: 1.0
Subject: [Ltru] Suggested text for future compatibility of registry processors.
Precedence: list
Content-Type: multipart/mixed; boundary="===============0768083903=="
Errors-To: ltru-bounces@ietf.org

--===============0768083903==
Content-Type: multipart/alternative; 
 boundary="----=_Part_117081_22776107.1183331910169"

------=_Part_117081_22776107.1183331910169
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Doug noted the following in his email on UTF-8 (on which topic I agree with
him, btw).

> Addison is correct; any structural change to the Registry will break RFC
4646-conformant processors.  This is true not only for UTF-8, but also for
new fields such as "Macrolanguage" or "Modified."  (Section 3.1 says the
Type "MUST" be one of the seven currently defined values.)

I suggest that we add language to 4646bis noting this, with the following
suggested text.

Add to the end of 3.1.2.  Record Definitions:

Future versions of the language subtag registry may add more fields.
Processors of the registry that are not intended to be updated with each
successive version of BCP 47 and thus need to be compatible with future
versions of the registry, SHOULD be written so as to ignore additional
fields.
<http://wiki/Main/IIIObjectives>
-- 
Mark

------=_Part_117081_22776107.1183331910169
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Doug noted the following in his email on UTF-8 (on which topic I agree with him, btw).<br><br>&gt; Addison is correct; any structural change to the Registry will break RFC<br>4646-conformant processors. &nbsp;This is true not only for UTF-8, but also for
<br>new fields such as &quot;Macrolanguage&quot; or &quot;Modified.&quot; &nbsp;(Section 3.1 says the<br>Type &quot;MUST&quot; be one of the seven currently defined values.)<br><br>I suggest that we add language to 4646bis noting this, with the following suggested text.
<br><br><span>Add to the end of 3.1.2.&nbsp; Record Definitions:<br><br></span><div style="margin-left: 40px;">Future versions of the language subtag registry may add more fields. Processors of the registry that are not intended to be updated with each successive version of BCP 47 and thus need to be compatible with future versions of the registry, SHOULD be written so as to ignore additional fields.
<br clear="all"></div><a href="http://wiki/Main/IIIObjectives" target="_top"></a><br>-- <br>Mark

------=_Part_117081_22776107.1183331910169--



--===============0768083903==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

--===============0768083903==--