Subject: [precis] Last Call: <draft-ietf-precis-problem-statement-08.txt> (Stringprep Revision and PRECIS Problem Statement) to Informational RFC

From: The IESG <[email-masked]>
Date: Tue, 09 Oct 2012 06:44:58 -0700

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
[email-masked] mailing lists by 2012-10-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   If a protocol expects to compare two strings and is prepared only for
   those strings to be ASCII, then using Unicode codepoints in those
   strings requires they be prepared somehow.  Internationalizing Domain
   Names in Applications (here called IDNA2003) defined and used
   Stringprep and Nameprep.  Other protocols subsequently defined
   Stringprep profiles.  A new approach different from Stringprep and
   Nameprep is used for a revision of IDNA2003 (called IDNA2008).  Other
   Stringprep profiles need to be similarly updated or a replacement of
   Stringprep needs to be designed.  This document outlines the issues
   to be faced by those designing a Stringprep replacement.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Oct 2012 10:25:37 -0600

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 [email-masked] 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/

---

From: SM <[email-masked]>
Date: Tue, 09 Oct 2012 13:16:03 -0700

Hi Peter,
>helpful (e.g., "Unicode Normalization Form KC").

Yes.

>the PRECIS WG used to collect the information.

Ok.

>shortcomings of IDNA2003 and the Nameprep profile of Stringprep.

My view is that the IDNABIS took on a difficult and 
politically-sensitive problem.  There's an open source implementation 
of the specification .  IDNABIS had the advantage of being related to 
domain names.  I'll take back the comment as you did a good write-up. :-)

Regards,
-sm