Re: [I18nrp] proposed charter for an Internationalization Directorate

[Peter Saint-Andre <[e-mail]>]

Hi Jiankang, thanks for your feedback.

In general I agree with Adam's reply. However, I've provided further
thoughts below.

On 8/9/18 7:44 PM, Jiankang Yao wrote:
> *From:* Peter Saint-Andre <mailto:[e-mail]>
> *Date:* 2018-08-10 00:29
> *To:* i18nrp <mailto:[e-mail]>
> *Subject:* [I18nrp] proposed charter for an Internationalization Directorate
>  
> Hi Peter,
> Thanks a lot for your good start.
>  
>  
>>Internationalization Directorate (i18ndir)
>  
>>The Internationalization Directorate is a specialized advisory group
>>that assists the Area Directors of the Applications and Real-Time Area
>>with regard to internationalization, in accordance with RFC 2418.
>>
>  
> I hope that it is not just an  advisory group.
> In short term, it is suggested to have a working group, and in long
> term, it can be an advisory group.

Although it's possible that we might need both, a working group usually
needs to produce well-scoped technical documents within a limited period
of time, whereas the directorate would be a standing team that
continually reviews Internet-Drafts (and provides other kinds of
guidance) for as long as internationalization issues arise.

> The reason is in the next paragraph.
>  
>>In support of a global Internet, the IETF has long worked on
>>internationalization of the Internet through various technologies,
>>including but not limited to text encodings (RFC 20, RFC 3629, RFC
>>5198), character sets (RFC 2277), language tags (RFC 5646), URIs (RFC
>>3986), domain names (RFC 5890), email addresses (RFC 6530) and headers
>>(RFC 5335), HTTP headers (RFC 7231, RFC 8187), and usernames and
>>passwords (RFC 8265). Because the appropriate use of these technologies
>>in any particular Internet protocol is not always clear-cut,
>>specifications developed within the IETF often need to be reviewed by
>>individuals with competence in internationalization. Another sort of
>>review is required for adjustments to the underlying technologies
>>themselves, for instance handling issues with internationalized domain
>>names that arise because of updates to the Unicode standard.
>>
>  
> There are many Internationalization related RFCs, which you have listed.
> Many experts are good at some of these RFCs, but few are good at all of
> them.
> Many may not understand the internationalization issues in the same level.
> This mean that we lack a framework document which covers all RFCs above.
> This document may cover
> 1. what internationalziation may cover (can discuss and summarize the
> current internationalized  related RFCs, what are these RFCs' relationship)
> 2. what kind of issues will be reviewed
> 3. how the new drfat to be reviewed 
>  
> That means that we need a WG to produce such document.
> Through the WG discussion, there are 2 benefits.
> 1) we can try to understand the internationalization in the same level
> 2) we can have a guideline RFC for future internationalization related
> document and its review.
>  
> for your kind reference.

At IETF 102, we talked about the need for documentation of common
internationalization problems and solutions. I believe we had rough
agreement that initially such documentation could be created in a less
formal way (e.g., on a wiki), and that eventually such documentation
might or might not evolve into an Internet-Draft or RFC.

What you propose has a much wider scope: it would be a sort of "grand
unified theory" of internationalization at the IETF. Although that might
be helpful in guiding our future work, I think it would be difficult to
agree on the success criteria for such a document, or to reach consensus
on a framework that might be somewhat theoretical and not closely
related to practical engineering problems.

My perspective is that we have a semi-urgent need to establish a
functioning directorate, and a less urgent desire to define a larger
framework for all of our i18n technologies - and that these two
initiatives have different goals, timelines, and chances of success.
Therefore it seems best to address them separately.

> BTW, RFC5335 has been Obsoleted by RFC 6532 .

Ah, I missed that, thanks for the error report.

Peter