Subject: [precis] I-D Action:draft-ietf-precis-problem-statement-00.txt

From: [email-masked]
Date: Mon, 18 Oct 2010 14:30:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF.

	Title           : Stringprep Revision Problem Statement
	Author(s)       : M. Blanchet, A. Sullivan
	Filename        : draft-ietf-precis-problem-statement-00.txt
	Pages           : 12
	Date            : 2010-10-18

Using Unicode codepoints in protocol strings that expect comparison
with other strings [[anchor1: The WG will need to decide whether
"other strings" is too broad.  In particular, what about protocol
slots that can take strings other than plain ASCII?
[email-masked]]] requires preparation of the string that contains
the Unicode codepoints.  Internationalizing Domain Names in
Applications (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 need to
be designed.  This document outlines the issues to be faced by those
designing a Stringprep replacement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-precis-problem-statement-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Oct 2010 21:18:09 -0400

Dear colleagues,

> 	Filename        : draft-ietf-precis-problem-statement-00.txt

This is the much-delayed problem statement draft.  My apologies for
how long it took.

I hereby ask for a slot in the Beijing meeting to try to come to some
conclusion on the open questions in the draft.  I do not anticipate
going through it, but there are several open issues identified in the
draft & I think we need to make some decisions.  Assuming the chairs
grant some time in the meeting, I'll prepare a list of issues I'd like
to nail down in the meeting, and then we can try to do some of that
work.

One "hot" issue that really needs attention is the list of protocols
already identified, and the issues they have with stringprep as it
exists today.  There's a set of open tickets on the WG trac, and it'd
be great if, before the meeting, people went and had a look at
protocols that interest them and update those tickets with some
background.  We have an entire section in the draft that is currently
empty for want of this work.  I can't do it myself, partly because I
don't have the time to read all the relevant RFCs; but more
importantly because I'm not an expert in most of those protocols, so
I'd probably get any evaluation wrong.  Please help!

In addition, I want to draw your attention to a newly emerged issue,
which arose too late for us to include in this draft.  Unicode has
just issued Unicode 6.0.  In this release, there is a code point that,
for IDNA2008, moves from PVALID to DISALLOWED.  This strikes me as a
big deal.  The IDNA2008 discussions suggested such an eventuality was
pretty unlikely, but we seem to have arrived at it anyway.

In IDNA2008, for the case under consideration, the chances that
there's a serious problem are pretty remote.  I would be rather more
worried, however, if we were talking about things like usernames,
which is one of the kinds of things for which we can expect the output
of precis to be used.  So I think we need to say something about
stability of identifiers across versions, or to work out some sort of
signalling about versioning or something.  I'm being hand-wavy because
I really don't have a clear idea of what to do here.

Best,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Oct 2010 10:29:40 +0200

> 	Filename        : draft-ietf-precis-problem-statement-00.txt

  Section 1 could also list 4282 (NAI), which depends on saslprep.
Since the EAP identity (3748) is also used as the NAI, it would be good
to have a consistent approach.

  Section 2.6 could also note that some protocols (EAP, RADIUS,
Diameter) already specify UTF-8 rather than ASCII.  So i18n is needed,
but ASCII-compatible encoding is not a requirement.

  Alan DeKok.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Oct 2010 10:31:59 -0400

> to have a consistent approach.

Good catch, I'll add it.  I didn't check just now -- is that on the wg
trac's list of things to be reviewed?  If not, could you add it (and
ideally, do that review)?

> but ASCII-compatible encoding is not a requirement.

This touches on the remark I have as a cref in the abstract: are we
concerned only with protocols where the protocol slot is ASCII-only,
or are we going to try to do something for protocols that accept any
collection of octets in protocol slots?

The analogy with DNS is instructive.  Remember that, strictly
speaking, a DNS label is 8 bits.  There's no DNS-protocol reason why
you couldn't put a UTF-8 label "Grünwald's.com" (that's got a U-umlaut
and an apostrophe in it, for those of you using other encodings) into
a zone file.  Among other issues, however, we have the problem is that
the DNS has the strange ASCII case-preserving but case-insensitive
matching rules (which means that DNS is kinda-ASCII-centric); and that
DNS was deployed with assumptions about the old-fashioned hostname
rules.  So we were stuck with letter, digit, hyphen for practical
purposes anyway.

The WG has to make some decisions about where those kinds of policies
are applied in our work.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Oct 2010 16:41:32 +0200

> ideally, do that review)?

  I've added "review RFC 4282" to trac, and added myself as responsible.

  I also had a draft proposal to update 4282.  I've put a URL in the
ticket, along with a note that the draft was written before precis
started, so it might not be correct.

> collection of octets in protocol slots?

  For 4282, the issue is both.  The authentication protocols allow
UTF-8, but they also suggest taking UTF-8 user names, and converting
portions of the names via the DNS "ToAscii" function.  The result may be
used for comparison, or for DNS lookups.

> The WG has to make some decisions about where those kinds of policies

  If we can solve it for DNS, the authentication protocols should be
able to leverage that solution.  So any additional work might be minimal.

  Alan DeKok.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Oct 2010 10:48:57 -0400

>   I've added "review RFC 4282" to trac, and added myself as responsible.

Thanks!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Oct 2010 10:45:38 -0600

On 10/18/10 7:18 PM, Andrew Sullivan wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Preparation and
>> Comparison of Internationalized Strings Working Group of the IETF.
>> 
>> 
>> Title           : Stringprep Revision Problem Statement Author(s)
>> : M. Blanchet, A. Sullivan Filename        :
>> draft-ietf-precis-problem-statement-00.txt Pages           : 12 
>> Date            : 2010-10-18
> 

Many thanks for working on this!

> I hereby ask for a slot in the Beijing meeting to try to come to
> some conclusion on the open questions in the draft.  I do not
> anticipate going through it, but there are several open issues
> identified in the draft & I think we need to make some decisions.
> Assuming the chairs grant some time in the meeting, I'll prepare a
> list of issues I'd like to nail down in the meeting, and then we can
> try to do some of that work.

+1

> exists today.  There's a set of open tickets on the WG trac, and
> it'd be great if, before the meeting, people went and had a look at 
> background.  We have an entire section in the draft that is
> currently empty for want of this work.  I can't do it myself, partly
> because I don't have the time to read all the relevant RFCs; but
> more importantly because I'm not an expert in most of those
> protocols, so I'd probably get any evaluation wrong.  Please help!

I've taken on issues 6, 7, and 23, which are related to XMPP.

> just issued Unicode 6.0.  In this release, there is a code point
> that, for IDNA2008, moves from PVALID to DISALLOWED.  This strikes me
> as a big deal.  The IDNA2008 discussions suggested such an
> eventuality was pretty unlikely, but we seem to have arrived at it
> anyway.
> 
> which is one of the kinds of things for which we can expect the
> output of precis to be used.  So I think we need to say something
> about stability of identifiers across versions, or to work out some
> sort of signalling about versioning or something.  I'm being
> hand-wavy because I really don't have a clear idea of what to do
> here.

Yes, that's a sticky issue, and one that we didn't think we'd run into
so fast with IDNA. The fact that it arose so quickly makes it more
urgent to figure out our approach for PRECIS.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/