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

From: [email-masked]
Date: Mon, 11 Jul 2011 16:25:04 -0700

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)       : Marc Blanchet
                          Andrew Sullivan
	Filename        : draft-ietf-precis-problem-statement-03.txt
	Pages           : 18
	Date            : 2011-07-11

   Using Unicode codepoints in protocol strings that expect comparison
   with other strings 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 needs 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-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-precis-problem-statement-03.txt

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Jul 2011 19:34:20 -0400

Dear colleagues,

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

Marc and I submitted an update to the problem statement.  There's not
a great deal of progress, I admit to my chagrin, but there is some.  Notably,

    - the "bucket" terminology has bene put into line with the latest
      IAB draft on the topic

    - we incorporated a categorization heavily cribbed from Peter
      Saint Andre's "Nameythings" &c. presentation and draft

    - a table in an appendix is started to summarize the reviews along
      the above lines.

I'd be especially interested in whether people think that table is
worth anything, before I complete it.  I'm of two minds.

Thanks and best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Tue, 12 Jul 2011 00:14:24 +0000

Andrew Sullivan asked:
> I'd be especially interested in whether people think that table is worth
> anything, before I complete it.  I'm of two minds.

I'd say yes.

To its credit, it made me go look at one of the reviews (Alexey's review of 
RFC4314 at http://www.ietf.org/mail-archive/web/precis/current/msg00086.html)
for more info.   I'm not that familiar with IMAP or SASLprep so I am confused about
one thing and hope someone can explain it in simple terms for me :)

The review says:
> Most likely case sensitive. Exact requirements on case-sensitivity/case-preservation
> depend on a specific implementation, e.g. an implementation might treat all user 
> identifiers as case insensitive (or case insensitive for US-ASCII subset only).

But RFC 4013 says:
> This profile is not intended for use in
> preparing identity strings that are not simple user names (e.g.,
> email addresses, domain names, distinguished names), or where
> identity or password strings that are not character data, or require
> different handling (e.g., case folding).

The table Andrew added has "a,d" (but not "i").  That would be correct if all
implementations agreed on the case sensitivity rules.   And RFC 4013 says it's
not appropriate for things that aren't case sensitive.

So I'm confused about the part of the review saying:
"Exact requirements on case-sensitivity/case-preservation
depend on a specific implementation, e.g. an implementation might treat all user 
identifiers as case insensitive (or case insensitive for US-ASCII subset only)."

Can someone elaborate on this?

Thanks,
-Dave

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Jul 2011 10:21:27 -0600

>     - the "bucket" terminology has bene put into line with the latest

Super.

>       Saint Andre's "Nameythings" &c. presentation and draft

BTW in draft-precis-framework-02 I changed the terminology because my
co-author thought that *thing was a bit too informal. :)

>     - a table in an appendix is started to summarize the reviews along

Excellent. I'll review that in more detail today.

> worth anything, before I complete it.  I'm of two minds.

I do think it's helpful to have much of that data available at a glance.

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Jul 2011 19:32:43 +0100

Hi Dave,

>>different handling (e.g., case folding).
I don't think there is necessarily a contradiction. Case folding can be 
applied as an extra step after RFC 4013 processing.

>Can someone elaborate on this?
Ok, let me try to elaborate on my review and why I wrote what I wrote. I 
was talking specifically about IMAP/POP/SMTP usernames (passwords are 
another story). Many email servers support all of the three protocols 
and use the same identity format in all three. For a given email address 
the corresponding user identity is either the left hand side of the 
email address and/or the whole email address. (This isn't documented 
anywhere, but it is one of the things that all email implementors need 
to know.) The domain part (if included) is case-insensitive. SMTP (RFC 
5321) says that the left hand side is case sensitive. In practice this 
restriction turned out to be quite problematic in real deployments 
(because humans just don't pay attention to case sometimes) and most of 
the systems I know of treat left hand sides as case sensitive. However 
until and unless an update to RFC 5321 declares that all left hand sides 
of email addresses are case insensitive, we can't say that left hand 
sides are always case insensitive, as some systems might rely on case 
sensitivity of left hand sides.

Does this help?

Best Regards,
Alexey

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Jul 2011 18:11:39 +0000

Thanks for the elaboration.

Doesn't that make 4314's use of identifiers qualify as Indefinite?
(If so, Andrew's table should be updated.)

-Dave

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Sunday, July 17, 2011 11:33 AM
To: Dave Thaler
Cc: Andrew Sullivan; [email-masked]
Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-03.txt

Hi Dave,

Dave Thaler wrote:

>>depend on a specific implementation, e.g. an implementation might 
>>treat all user identifiers as case insensitive (or case insensitive for US-ASCII subset only).
>>    
>>
>
>But RFC 4013 says:
>  
>
>>This profile is not intended for use in preparing identity strings 
>>that are not simple user names (e.g., email addresses, domain names, 
>>distinguished names), or where identity or password strings that are 
>>not character data, or require different handling (e.g., case 
>>folding).
>>
I don't think there is necessarily a contradiction. Case folding can be applied as an extra step after RFC 4013 processing.

>depend on a specific implementation, e.g. an implementation might treat 
>all user identifiers as case insensitive (or case insensitive for US-ASCII subset only)."
>
Ok, let me try to elaborate on my review and why I wrote what I wrote. I was talking specifically about IMAP/POP/SMTP usernames (passwords are another story). Many email servers support all of the three protocols and use the same identity format in all three. For a given email address the corresponding user identity is either the left hand side of the email address and/or the whole email address. (This isn't documented anywhere, but it is one of the things that all email implementors need to know.) The domain part (if included) is case-insensitive. SMTP (RFC
5321) says that the left hand side is case sensitive. In practice this restriction turned out to be quite problematic in real deployments (because humans just don't pay attention to case sometimes) and most of the systems I know of treat left hand sides as case sensitive. However until and unless an update to RFC 5321 declares that all left hand sides of email addresses are case insensitive, we can't say that left hand sides are always case insensitive, as some systems might rely on case sensitivity of left hand sides.

Does this help?

Best Regards,
Alexey

---

From: Dave Thaler <[email-masked]>
Date: Sun, 24 Jul 2011 16:34:08 +0000

Alexey wrote:
[...]
> Ok, let me try to elaborate on my review and why I wrote what I wrote. I was
> talking specifically about IMAP/POP/SMTP usernames (passwords are
> another story). Many email servers support all of the three protocols and
> use the same identity format in all three. For a given email address the
> corresponding user identity is either the left hand side of the email address
> and/or the whole email address. (This isn't documented anywhere, but it is
> one of the things that all email implementors need to know.) The domain
> part (if included) is case-insensitive. SMTP (RFC
> 5321) says that the left hand side is case sensitive. In practice this restriction
> turned out to be quite problematic in real deployments (because humans
> just don't pay attention to case sometimes) and most of the systems I know
> of treat left hand sides as case sensitive. 

Did you mean to say sensitive or insensitive above?

> However until and unless an
> update to RFC 5321 declares that all left hand sides of email addresses are
> case insensitive, we can't say that left hand sides are always case insensitive,
> as some systems might rely on case sensitivity of left hand sides.
> 
> Does this help?

Yes, it clarifies that currently it's Indefinite, and hence dangerous to use
for many security purposes.

(And btw simply declaring that something is case insensitive but not restricted
to ASCII, is also Indefinite.)

Thanks!
-Dave

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 Jul 2011 10:49:19 -0400

> Did you mean to say sensitive or insensitive above?
Right, I meant "case insensitive" in the last quoted sentence.