The following is a proposed charter for a "NewPrep" WG to work on replacements for stringprep profiles in application and security protocols such as XMPP and SASL. We plan to hold a BoF at IETF 77 to explore whether it makes sense to form a working group on this topic. If you are interested, please join the newprep@xxxxxxxx list: https://www.ietf.org/mailman/listinfo/newprep My apologies for cross-posting; please send replies to newprep@xxxxxxxxx Thanks! Peter ###### Proposed Charter for NewPrep WG Last Updated: 2010-01-14 Problem Statement The handling of non-ASCII strings in Internet protocols is a difficult problem that has still not been solved in a generalized way. In 2002, the IETF defined a method for preparation and comparison of internationalized strings that could be re-used by various applications. This method, stringprep (RFC 3454), has been re-used in several Internet protocols that have defined "profiles" of stringprep, namely: - The Nameprep profile (RFC 3490) for use in Internationalized Domain Names (IDNs) - The iSCSI profile (RFC 3722) for use in Internet Small Computer Systems Interface (iSCSI) Names - The Nodeprep and Resourceprep profiles (RFC 3920) for use in the Extensible Messaging and Presence Protocol (XMPP) - The Policy MIB profile (RFC 4011) for use in the Simple Network Management Protocol (SNMP) - The SASLprep profile (RFC 4013) for use in the Simple Authentication and Security Layer (SASL) - The trace profile (RFC 4505) for use with the SASL ANONYMOUS mechanism In completing revisions to the IDN technology, the IETF's IDNAbis WG decided to move away from the use of stringprep in domain names, instead defining sets of allowed and disallowed characters based on Unicode character properties (often called an "inclusion approach") rather than defining explicit mappings of Unicode characters as in stringprep (an "exclusion approach"). Although the IDNAbis WG had its reasons for moving away from stringprep, and some of those reasons might not apply to other applications (e.g., usernames in XMPP or usernames and passwords in SASL), other reasons might apply more generally. In particular, stringprep depends on a particular version of Unicode (3.2) and cannot be upgraded to a new Unicode version without revising the core stringprep technology. However, any move away from stringprep by existing profiles would introduce backward compatibility issues and migration challenges, which need to be weighed against the benefits of a new string preparation technology. Objectives The goal of this group is to assess whether an "inclusion approach" similar to that taken in the revisions to Internationalized Doman Names (IDNs) is appropriate for other stringprep profiles. Such an approach would involve: - A tiered model of permitted characters, especially the three categories of valid, disallowed, and unassigned characters - Protocol-specific lists of valid characters - Potentially a reduction in the number of characters that are permitted in usernames, passwords, and other identifiers - Application of the foregoing concepts to existing profiles in ways that respect the significant differences between those profiles The group will analyze existing stringprep profiles to assess if it is appropriate for them to move to an inclusion approach. If so, based on consensus the group will do one of the following with regard to each existing profile: 1. Directly complete a replacement for the profile, if it does not fall within the scope of another active working group. 2. Collaborate with another active working group on developing a replacement for its profile or profiles. 3. Advise the authors of profiles that were produced outside the context of any working group regarding how to proceed. Deliverables 1. Analysis of existing stringprep profiles. 2. Revisions to one or more existing stringprep profiles. Milestones To follow. ######
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf