One document matched: draft-blanchet-precis-problem-statement-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="info" ipr="pre5378Trust200902" docName="draft-blanchet-precis-problem-statement-00.txt">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <front>
    <title>Stringprep Revision Problem Statement</title>
    <author initials="M." surname="Blanchet" fullname="Marc Blanchet">
      <organization>Viagenie</organization>
      <address>
    <postal>
      <street>2600 boul. Laurier, suite 625</street>
      <city>Quebec</city>
      <region>QC</region>
      <code>G1V 4W1</code>
      <country>Canada</country>
    </postal>
    <email>Marc.Blanchet@viagenie.ca</email>
    <uri>http://viagenie.ca</uri>
  </address>
    </author>
    <date month="July" year="2010"/>
    <abstract>
      <t>
Using Unicode codepoints in protocol strings requires preparation of the string.
Internationalized Domain Names(idn) initial work defined and used Stringprep and Nameprep. Other protocols have defined Stringprep profiles. A new approach different from Stringprep/Nameprep is used for a revision of IDN. The Stringprep profiles need to be updated or a replacement of Stringprep need to be designed. This document summarizes the findings of the current usage of Stringprep  and identifies directions for a new Stringprep replacement protocol.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
As part of the Internationalized Domain Names(idn) initial work <xref target="RFC3490"/><xref target="RFC3491"/><xref target="RFC3492"/>, the Unicode-based strings needed to be prepared and normalized to enable their use in the DNS with exact match mechanism. The method, called Nameprep <xref target="RFC3491"/>, is specific to idn, but is generalized as Stringprep <xref target="RFC3454"/>, to help other protocols with similar needs, but with different constraints than idn.
</t>
<t>Strinprep defines a framework where protocols defines their Stringprep profiles. Known IETF specifications using Strinprep are:
<list style="symbols">
<t>The Nameprep profile<xref target="RFC3490"/> for use in Internationalized Domain Names (IDNs)</t>
<t>The iSCSI profile <xref target="RFC3722"/> for use in Internet Small Computer Systems Interface (iSCSI) Names</t>
<t>The Nodeprep and Resourceprep profiles <xref target="RFC3920"/> for use in the Extensible Messaging and Presence Protocol (XMPP)</t>
<t>The Policy MIB profile <xref target="RFC4011"/> for use in the Simple Network Management Protocol (SNMP)</t>
<t>The SASLprep profile <xref target="RFC4013"/> for use in the Simple Authentication and Security Layer (SASL)</t>
<t>The trace profile <xref target="RFC4505"/> for use with the SASL ANONYMOUS mechanism</t>
<t> The LDAP profile <xref target="RFC4518"/> for use with LDAP</t>
</list>
</t>
<t>Based on findings <xref target="RFC4690"/> on early deployments of idn, 
IDNs specifications have been updated /* note to add ref to idnabis RFCs*/  and do not use stringprep/nameprep anymore. Instead, an algorithm based on Unicode properties of codepoints is defined. That algorithm generates a stable and  complete table of the supported Unicode codepoints. This algorithm is based on an inclusion-based approach, instead of the exclusion-based approach of Stringprep/Nameprep. 
</t>
<t>This document lists the shortcomings and issues found by protocols listed above that defined Stringprep profiles. It also lists some early conclusions and requirements for a potential replacement of Stringprep.</t>
</section>
<section title="Usage and Issues of Stringprep">
<t>During IETF 77, a BOF discussed the current state of the protocols that have defined Stringprep profiles. The main conclusions are /* ref meeting notes */:
<list style="symbols">
 <t>Stringprep is bound to a specific version of Unicode: 3.2. Stringprep has not been updated to new versions of Unicode. Therefore, the protocols using Stringprep are stuck to Unicode 3.2.</t>
 <t>The protocols need to be updated to support new versions of Unicode. The protocols would like to not be bound to a specific version of Unicode, but rather have better Unicode agility as IDNAbis.</t>
 <t>The protocols require better bidirectional support (bidi) than currently offered by Stringprep. </t>
 <t>If the protocols are updated to use a new version of Stringprep or another framework, then backward compatibility is an important requirement. For example, Stringprep uses NFKC[UAX15], while IDNAbis uses NFC[UAX15].</t>
<t>protocols are using each other, for example, a protocol can use user identifiers that are later passed to SASL, LDAP or another authentication mechanism. Therefore, common set of rules or classes of strings are preferred over specific rules for each protocol.</t>
</list>
</t>
<t>Stringprep profiles protocols  use strings for different purposes:
<list style="symbols">
<t>XMPP uses a different Stringprep profiles for each part of the XMPP address (JID): a localpart which is similar to a username and used for authentication, a domainpart which is a domain name and a resource part which is less restrictive than the localpart.</t>
<t>iSCSI uses a Stringprep profile for the IQN which is essentially a domain name. </t>
<t>SASL and LDAP uses a Stringprep profile for usernames.</t>
<t>LDAP uses a set of Stringprep profiles.</t>
</list>
</t>
<t>During the newprep BOF, it was the concensus of the attendees that the Stringprep profiles protocols would highly prefer to have a replacement of Stringprep, with similar characteristics as the IDNA2008. That replacement should be defined so that the protocols would not have to "deal" with i18n strings in too much details since i18n expertise is not available in the respective protocols or working groups.</t>
</section>
<section title="Considerations for Stringprep replacement">
<t>From the findings about, the following directions are proposed:
<list style="symbols">
<t>A stringprep replacement should be defined.</t>
<t>The replacement should take an approach similar to IDNA2008, enabling Unicode agility.</t>
<t>Protocols share similar characteristics of strings. Therefore, defining i18n preparation algorithms for a small set of string classes may be sufficient for most cases and provides the coherence among a set of protocol friends.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
     <t>
        This document has no actions for IANA.
      </t>
    </section>
    <section title="Discussion home for this draft">
      <t>
        This document is intended to define the problem space discussed in the precis@ietf.org mailing list.
      </t>
    </section>
  </middle>
  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.3454" ?>
      <?rfc include="reference.RFC.3490" ?>
      <?rfc include="reference.RFC.3491" ?>
      <?rfc include="reference.RFC.3492" ?>
      <?rfc include="reference.RFC.3722" ?>
      <?rfc include="reference.RFC.3920" ?>
      <?rfc include="reference.RFC.4011" ?>
      <?rfc include="reference.RFC.4013" ?>
      <?rfc include="reference.RFC.4505" ?>
      <?rfc include="reference.RFC.4518" ?>
      <?rfc include="reference.RFC.4690" ?>
    </references>
  </back>
</rfc>