-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/9/12 9:25 AM, SM wrote:
At 06:44 09-10-2012, The IESG wrote:
The IESG has received a request from the Preparation and
Comparison of Internationalized Strings WG (precis) to consider
the following document: - 'Stringprep Revision and PRECIS Problem
Statement' <draft-ietf-precis-problem-statement-08.txt> as
Informational RFC
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the ietf(_at_)ietf(_dot_)org mailing lists by 2012-10-23.
Exceptionally, comments may be
Section 2 could be dropped as it isn't that important to have RFC
2119 in a problem statement. In Section 4:
"For example, Stringprep is based on and profiles may use NFKC
[UAX15], while IDNA2008 mostly uses NFC [UAX15]."
I suggest reviewing the references to see what background
information is required for the reader to understand "NFKC".
At the least, spelling out these acronyms on first use would be
helpful (e.g., "Unicode Normalization Form KC").
In Section 6:
"The above suggests the following guidance for replacing
Stringprep: o A stringprep replacement should be defined."
That sounds obvious.
The appendix is more informative than the rest of the draft. The
text in the Appendix B comes out as rough notes though.
Indeed, that appendix consists of notes copied from a wiki page that
the PRECIS WG used to collect the information.
In Section 5.3.3.2:
"It is important to identify the willingness of the protocol-using
community to accept backwards-incompatible changes."
The "tolerance for change" for several "protocol-using communities"
is rated as "not sure". I understand that it is difficult to get
definitive answers for these questions. It's doubtful that people
will choose "better support for different linguistic environments
against the potential side effects of backward incompatibility".
It seems that the WG has taken on an intractable problem.
Your conclusion does not follow. Yes, it is true that we're not sure
how willing some developer communities are to upgrade from Stringprep
(based on Unicode 3.2) to PRECIS (version-agile, currently Unicode
6.1). However, we know that some developer communities are in fact
willing to upgrade, and they have been more involved in the PRECIS WG.
Furthermore, in general applications don't have a choice about what
Unicode version is installed on the underlying system, so as time goes
by Stringprep will become more and more problematic. There was strong
agreement at the NEWPREP BoF to work on a common solution that all
Stringprep-using protocols could re-use. The approach taken in the
PRECIS framework specification is closely modelled on IDNA2008 and
follows the recommendations from RFC 4690. If you are going to
maintain that the PRECIS WG has taken on an intractable problem, then
I think you're also arguing that the IDNABIS WG took on an intractable
problem and that IDNA2008 failed to provide a viable solution to the
shortcomings of IDNA2003 and the Nameprep profile of Stringprep.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlB0UAEACgkQNL8k5A2w/vwxggCfY5oXnRgP3UhOkZY3cu+1A/QX
gK4AoN5kxFk+5T19loPFsXup5YhzimWy
=LRQY
-----END PGP SIGNATURE-----