Re: JID case sensitivity
On Sat, 2010-01-30 at 09:17 -0800, Yann Kerherve wrote: > Yeah, this later clone is not synchronized with subversion. I haven't > touched it for a while. Sorry, I should have said http://github.com/apparentlymart/djabberd , which was pointed to in the 0.85_01 announcement sent 10/14/2009. - Alex
Re: JID case sensitivity
> It's applied in my git repo at > http://github.com/bestpractical/djabberd which is a significantly > cleaner conversion of the repository than the one at > http://github.com/yannk/djabberd . Yeah, this later clone is not synchronized with subversion. I haven't touched it for a while. Yann
Re: JID case sensitivity
On Fri, 2010-01-29 at 21:41 -0800, Gavin wrote: > was this ever actually applied? Not to my knowledge. I believe I addressed all of the concerns I heard raised about it, though. It's applied in my git repo at http://github.com/bestpractical/djabberd which is a significantly cleaner conversion of the repository than the one at http://github.com/yannk/djabberd . - Alex
Re: JID case sensitivity
was this ever actually applied? On Thu, Apr 30, 2009 at 8:47 AM, Alex Vandiver wrote: > On Wed, 2009-04-29 at 09:46 -0700, Martin Atkins wrote: > > What is the back-compact impact of this on sites that do not use the > flag? > > > > This is only an issue for systems that have existing, non-normalized > > JIDs in their RosterStorage, right? > > Correct -- well, any persistent storage of JIDs which your djabberd > might have, but roster storage is the most likely. > > > If so, I'll commit this patch. I assume that most folks won't actually > > need to use the back-compat flag since most folks will have normalized > > JIDs stored. > > It's worth putting a caution in the changelog, since they're apparently > more common than I originally thought, as well. > Thanks! > - Alex > >
Re: JID case sensitivity
On Wed, 2009-04-29 at 09:46 -0700, Martin Atkins wrote: > What is the back-compact impact of this on sites that do not use the flag? > > This is only an issue for systems that have existing, non-normalized > JIDs in their RosterStorage, right? Correct -- well, any persistent storage of JIDs which your djabberd might have, but roster storage is the most likely. > If so, I'll commit this patch. I assume that most folks won't actually > need to use the back-compat flag since most folks will have normalized > JIDs stored. It's worth putting a caution in the changelog, since they're apparently more common than I originally thought, as well. Thanks! - Alex
Re: JID case sensitivity
Alex Vandiver wrote: On Thu, 2009-03-26 at 22:02 -0400, Alex Vandiver wrote: That sounds correct. Attached is a patch, which _does_ add a dep of Unicode::Stringprep, but is probably as faithful of an implementation of the spec as we might be able to get. An updated patch is attached, which fixes an error which caused resources with spaces to be (wrongly) treated as illegal. The other two patches make domain checks case-insensitive, and add a flag for backwards compatibility. Any thoughts on getting these applied? What is the back-compact impact of this on sites that do not use the flag? This is only an issue for systems that have existing, non-normalized JIDs in their RosterStorage, right? If so, I'll commit this patch. I assume that most folks won't actually need to use the back-compat flag since most folks will have normalized JIDs stored.
Re: JID case sensitivity
On Thu, 2009-03-26 at 22:02 -0400, Alex Vandiver wrote:
> That sounds correct. Attached is a patch, which _does_ add a dep of
> Unicode::Stringprep, but is probably as faithful of an implementation of
> the spec as we might be able to get.
An updated patch is attached, which fixes an error which caused
resources with spaces to be (wrongly) treated as illegal. The other two
patches make domain checks case-insensitive, and add a flag for
backwards compatibility. Any thoughts on getting these applied?
- Alex
>From 2f197b0f12c8db8af7ad51e8c9289f3dec4a33c5 Mon Sep 17 00:00:00 2001
From: Alex Vandiver
Date: Thu, 26 Mar 2009 21:24:28 -0400
Subject: [PATCH 1/3] Do stringprep, as specified by the RFC, on JID object creation
---
DJabberd/Makefile.PL |1 +
DJabberd/lib/DJabberd/JID.pm | 89 +-
2 files changed, 89 insertions(+), 1 deletions(-)
diff --git a/DJabberd/Makefile.PL b/DJabberd/Makefile.PL
index 6de3e23..cfc06e2 100644
--- a/DJabberd/Makefile.PL
+++ b/DJabberd/Makefile.PL
@@ -14,6 +14,7 @@ WriteMakefile(
'Net::SSLeay' => 0,
'Log::Log4perl'=> 0,
'Digest::HMAC_SHA1'=> 0,
+ 'Unicode::Stringprep' => 0,
},
clean => { FILES => 't/log/*' },
AUTHOR => 'Brad Fitzpatrick ',
diff --git a/DJabberd/lib/DJabberd/JID.pm b/DJabberd/lib/DJabberd/JID.pm
index 3959ee5..f37e29c 100644
--- a/DJabberd/lib/DJabberd/JID.pm
+++ b/DJabberd/lib/DJabberd/JID.pm
@@ -13,6 +13,84 @@ use constant AS_STRING => 3;
use constant AS_BSTRING => 4;
use constant AS_STREXML => 5;
+# Stringprep functions for converting to canonical form
+use Unicode::Stringprep;
+use Unicode::Stringprep::Mapping;
+use Unicode::Stringprep::Prohibited;
+my $nodeprep = Unicode::Stringprep->new(
+3.2,
+[
+\...@unicode::Stringprep::Mapping::B1,
+\...@unicode::Stringprep::Mapping::B2,
+],
+'KC',
+[
+\...@unicode::Stringprep::Prohibited::C11,
+\...@unicode::Stringprep::Prohibited::C12,
+\...@unicode::Stringprep::Prohibited::C21,
+\...@unicode::Stringprep::Prohibited::C22,
+\...@unicode::Stringprep::Prohibited::C3,
+\...@unicode::Stringprep::Prohibited::C4,
+\...@unicode::Stringprep::Prohibited::C5,
+\...@unicode::Stringprep::Prohibited::C6,
+\...@unicode::Stringprep::Prohibited::C7,
+\...@unicode::Stringprep::Prohibited::C8,
+\...@unicode::Stringprep::Prohibited::C9,
+[
+0x0022, undef, # "
+0x0026, undef, # &
+0x0027, undef, # '
+0x002F, undef, # /
+0x003A, undef, # :
+0x003C, undef, # <
+0x003E, undef, # >
+0x0040, undef, # @
+]
+],
+1,
+);
+my $nameprep = Unicode::Stringprep->new(
+3.2,
+[
+\...@unicode::Stringprep::Mapping::B1,
+\...@unicode::Stringprep::Mapping::B2,
+],
+'KC',
+[
+\...@unicode::Stringprep::Prohibited::C12,
+\...@unicode::Stringprep::Prohibited::C22,
+\...@unicode::Stringprep::Prohibited::C3,
+\...@unicode::Stringprep::Prohibited::C4,
+\...@unicode::Stringprep::Prohibited::C5,
+\...@unicode::Stringprep::Prohibited::C6,
+\...@unicode::Stringprep::Prohibited::C7,
+\...@unicode::Stringprep::Prohibited::C8,
+\...@unicode::Stringprep::Prohibited::C9,
+],
+1,
+);
+my $resourceprep = Unicode::Stringprep->new(
+3.2,
+[
+\...@unicode::Stringprep::Mapping::B1,
+],
+'KC',
+[
+\...@unicode::Stringprep::Prohibited::C12,
+\...@unicode::Stringprep::Prohibited::C21,
+\...@unicode::Stringprep::Prohibited::C22,
+\...@unicode::Stringprep::Prohibited::C3,
+\...@unicode::Stringprep::Prohibited::C4,
+\...@unicode::Stringprep::Prohibited::C5,
+\...@unicode::Stringprep::Prohibited::C6,
+\...@unicode::Stringprep::Prohibited::C7,
+\...@unicode::Stringprep::Prohibited::C8,
+\...@unicode::Stringprep::Prohibited::C9,
+],
+1,
+);
+
+
# returns DJabberd::JID object, or undef on failure due to invalid format
sub new {
#my ($class, $jidstring) = @_;
@@ -29,7 +107,16 @@ sub new {
(?: /(.{1,1023}) )? # $3: optional resource
$!x;
-return bless [ $1, $2, $3 ], $_[0];
+# Stringprep uses regexes, so store these away first
+my ($node, $host, $res) = ($1, $2, $3);
+
+return eval {
+bless [
+defined $node ? $nodeprep->($node) : undef,
+$nameprep->($host),
+defined $res ? $resourceprep->($res) : undef,
+], $_[0]
+};
}
sub is_bare {
--
1.6.3.rc0.7.g2f866
>From 5553fd59f818ee2fe70913d29ff02d1bef8895dc Mon Sep 17 00:00:00 2001
From:
Re: JID case sensitivity
On Fri, 2009-03-27 at 17:27 -0400, Alex Vandiver wrote: > Attached is a script which walks a DJabberd::RosterStorage::SQLite > database, and adjusts rosters, groups, and the like for case folding. Attached is an updated version, which fixes non-duplicated but non-normalized names as well. - Alex fix-jabber-roster-case Description: Perl program
Re: JID case sensitivity
On Fri, 2009-04-03 at 14:18 -0700, Artur Bergman wrote:
> Global is better than none.
Attached. In writing it, I went to document the new config option, and
noticed that there doesn't seem to be any POD about known config
options. Would lib/DJabberd/Config.pod be the right place?
- Alex
>From 535480246809af9a1005ce355aa98a982bf18e02 Mon Sep 17 00:00:00 2001
From: Alex Vandiver
Date: Fri, 3 Apr 2009 17:47:36 -0400
Subject: [PATCH] Add global CaseSensitive flag for backwards compatibility
---
DJabberd/lib/DJabberd.pm |5 +
DJabberd/lib/DJabberd/JID.pm |7 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/DJabberd/lib/DJabberd.pm b/DJabberd/lib/DJabberd.pm
index 9debd3d..a168fdb 100644
--- a/DJabberd/lib/DJabberd.pm
+++ b/DJabberd/lib/DJabberd.pm
@@ -167,6 +167,11 @@ sub fake_s2s_peer {
return $fake_peers{$host};
}
+sub set_config_casesensitive {
+my ($self, $val) = @_;
+$DJabberd::JID::CASE_SENSITIVE = as_bool($val);
+}
+
sub add_vhost {
my ($self, $vhost) = @_;
my $sname = lc $vhost->name;
diff --git a/DJabberd/lib/DJabberd/JID.pm b/DJabberd/lib/DJabberd/JID.pm
index b644742..bf9a80b 100644
--- a/DJabberd/lib/DJabberd/JID.pm
+++ b/DJabberd/lib/DJabberd/JID.pm
@@ -3,6 +3,9 @@ use strict;
use DJabberd::Util qw(exml);
use Digest::SHA1;
+# Configurable via 'CaseSensitive' config option
+our $CASE_SENSITIVE = 0;
+
use overload
'""' => \&as_string_exml;
@@ -108,6 +111,10 @@ sub new {
(?: /(.{1,1023}) )? # $3: optional resource
$!x;
+# If we're in case-sensitive mode, for backwards-compatibility,
+# then skip stringprep
+return bless [ $1, $2, $3 ], $_[0] if $DJabberd::JID::CASE_SENSITIVE;
+
# Stringprep uses regexes, so store these away first
my ($node, $host, $res) = ($1, $2, $3);
--
1.6.2.1.321.g7b198.dirty
Re: JID case sensitivity
On Apr 3, 2009, at 1:59 PM, Alex Vandiver wrote: On Fri, 2009-04-03 at 13:10 -0700, Artur Bergman wrote: Maybe a config flag that controls the behaviour? Such a change would unfortunately be either global to all djabberd servers in the same process, or be fairly invasive, as DJabberd::JID objects are currently created without a reference to the server of vhost they're being created for. Preferences? - Alex Global is better than none. Artur
Re: JID case sensitivity
On Fri, 2009-04-03 at 13:10 -0700, Artur Bergman wrote: > Maybe a config flag that controls the behaviour? Such a change would unfortunately be either global to all djabberd servers in the same process, or be fairly invasive, as DJabberd::JID objects are currently created without a reference to the server of vhost they're being created for. Preferences? - Alex
Re: JID case sensitivity
On Apr 3, 2009, at 1:05 PM, Alex Vandiver wrote: On Fri, 2009-04-03 at 13:00 -0700, Artur Bergman wrote: Does the patch not break backwards compatibility? The patch _does_ break backwards compatibility in roster storage, yes. I send a patch to the list a week ago which fixes existing SQLite roster storage, however. If there are other workarounds which folks would want in place before applying, I'd be happy to work on them. - Alex Maybe a config flag that controls the behaviour? Artur
Re: JID case sensitivity
On Fri, 2009-04-03 at 13:00 -0700, Artur Bergman wrote: > Does the patch not break backwards compatibility? The patch _does_ break backwards compatibility in roster storage, yes. I send a patch to the list a week ago which fixes existing SQLite roster storage, however. If there are other workarounds which folks would want in place before applying, I'd be happy to work on them. - Alex
Re: JID case sensitivity
On Apr 3, 2009, at 12:48 PM, Alex Vandiver wrote: On Thu, 2009-03-26 at 22:02 -0400, Alex Vandiver wrote: That sounds correct. Attached is a patch, which _does_ add a dep of Unicode::Stringprep, but is probably as faithful of an implementation of the spec as we might be able to get. Thoughts on getting this applied? - Alex Does the patch not break backwards compatibility? Artur
Re: JID case sensitivity
On Thu, 2009-03-26 at 22:02 -0400, Alex Vandiver wrote: > That sounds correct. Attached is a patch, which _does_ add a dep of > Unicode::Stringprep, but is probably as faithful of an implementation of > the spec as we might be able to get. Thoughts on getting this applied? - Alex
Re: JID case sensitivity
On 3/27/09 3:27 PM, Alex Vandiver wrote: > On Thu, 2009-03-26 at 22:01 -0400, Alex Vandiver wrote: >> That sounds correct. Attached is a patch, which _does_ add a dep of >> Unicode::Stringprep, but is probably as faithful of an implementation of >> the spec as we might be able to get. > > Note that this has an effect on existing rosters (which is actually > where I first noticed it). Specifically, JIDs which are "the same", > like ale...@example.com and ale...@example.com, show up separately in > the roster, and hence can have different subscriptions. Yes, this was a common bug in the old days (I recall having a difficult time convincing jabber.org that "Akuma" was the same person as "akuma"). Thanks for the fix! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: JID case sensitivity
On Thu, 2009-03-26 at 22:01 -0400, Alex Vandiver wrote: > That sounds correct. Attached is a patch, which _does_ add a dep of > Unicode::Stringprep, but is probably as faithful of an implementation of > the spec as we might be able to get. Note that this has an effect on existing rosters (which is actually where I first noticed it). Specifically, JIDs which are "the same", like ale...@example.com and ale...@example.com, show up separately in the roster, and hence can have different subscriptions. For instance, the query below[1], on Hiveminder's DJabberd::RosterStorage::SQLite backend, returns 24 JIDs that exist more than once, with anywhere between 2 and 4 different variations of case. If the patch I previously sent is applied, JIDs which exist in the roster in a non-canonical form will appear vanish from the roster. Attached is a script which walks a DJabberd::RosterStorage::SQLite database, and adjusts rosters, groups, and the like for case folding. - Alex [1] SQL query to detect multiply-ocurring JIDs in the roster: SELECT LOWER(first.jid), COUNT(DISTINCT other.jid) FROM jidmap first JOIN jidmap other ON LOWER(first.jid) = LOWER(other.jid) LEFT JOIN jidmap later ON LOWER(later.jid) = LOWER(first.jid) AND later.jidid > first.jidid GROUP BY first.jid HAVING COUNT(DISTINCT other.jid) > 1 AND later.jid IS NULL ORDER BY COUNT(DISTINCT other.jid), LOWER(first.jid); fix-jabber-roster-case Description: Perl program
Re: JID case sensitivity
On Thu, 2009-03-26 at 18:44 -0700, Martin Atkins wrote:
> So when DJabberd parses a JID, it ought to normalize the case in the
> node and domain parts. It must presumably do this in a way defined in
> stringprep rather than relying on Perl's in-built ability to turn
> strings to lowercase.
>
> Is this correct? (and does anyone want to send in a patch? :) )
That sounds correct. Attached is a patch, which _does_ add a dep of
Unicode::Stringprep, but is probably as faithful of an implementation of
the spec as we might be able to get.
- Alex
>From 958320315b7e7a3e5c4e8c9cdfb3809d6a90ecee Mon Sep 17 00:00:00 2001
From: Alex Vandiver
Date: Thu, 26 Mar 2009 21:24:28 -0400
Subject: [PATCH] Do stringprep, as specified by the RFC, on JID object creation
---
DJabberd/Makefile.PL |1 +
DJabberd/lib/DJabberd/JID.pm | 91 +-
2 files changed, 91 insertions(+), 1 deletions(-)
diff --git a/DJabberd/Makefile.PL b/DJabberd/Makefile.PL
index 6de3e23..cfc06e2 100644
--- a/DJabberd/Makefile.PL
+++ b/DJabberd/Makefile.PL
@@ -14,6 +14,7 @@ WriteMakefile(
'Net::SSLeay' => 0,
'Log::Log4perl'=> 0,
'Digest::HMAC_SHA1'=> 0,
+ 'Unicode::Stringprep' => 0,
},
clean => { FILES => 't/log/*' },
AUTHOR => 'Brad Fitzpatrick ',
diff --git a/DJabberd/lib/DJabberd/JID.pm b/DJabberd/lib/DJabberd/JID.pm
index 3959ee5..c1dd0c3 100644
--- a/DJabberd/lib/DJabberd/JID.pm
+++ b/DJabberd/lib/DJabberd/JID.pm
@@ -12,6 +12,86 @@ use constant RES=> 2;
use constant AS_STRING => 3;
use constant AS_BSTRING => 4;
use constant AS_STREXML => 5;
+use constant CANONICAL => 6;
+
+# Stringprep functions for converting to canonical form
+use Unicode::Stringprep;
+use Unicode::Stringprep::Mapping;
+use Unicode::Stringprep::Prohibited;
+my $nodeprep = Unicode::Stringprep->new(
+3.2,
+[
+\...@unicode::Stringprep::Mapping::B1,
+\...@unicode::Stringprep::Mapping::B2,
+],
+'KC',
+[
+\...@unicode::Stringprep::Prohibited::C11,
+\...@unicode::Stringprep::Prohibited::C12,
+\...@unicode::Stringprep::Prohibited::C21,
+\...@unicode::Stringprep::Prohibited::C22,
+\...@unicode::Stringprep::Prohibited::C3,
+\...@unicode::Stringprep::Prohibited::C4,
+\...@unicode::Stringprep::Prohibited::C5,
+\...@unicode::Stringprep::Prohibited::C6,
+\...@unicode::Stringprep::Prohibited::C7,
+\...@unicode::Stringprep::Prohibited::C8,
+\...@unicode::Stringprep::Prohibited::C9,
+[
+0x0022, undef, # "
+0x0026, undef, # &
+0x0027, undef, # '
+0x002F, undef, # /
+0x003A, undef, # :
+0x003C, undef, # <
+0x003E, undef, # >
+0x0040, undef, # @
+]
+],
+1,
+);
+my $nameprep = Unicode::Stringprep->new(
+3.2,
+[
+\...@unicode::Stringprep::Mapping::B1,
+\...@unicode::Stringprep::Mapping::B2,
+],
+'KC',
+[
+\...@unicode::Stringprep::Prohibited::C12,
+\...@unicode::Stringprep::Prohibited::C22,
+\...@unicode::Stringprep::Prohibited::C3,
+\...@unicode::Stringprep::Prohibited::C4,
+\...@unicode::Stringprep::Prohibited::C5,
+\...@unicode::Stringprep::Prohibited::C6,
+\...@unicode::Stringprep::Prohibited::C7,
+\...@unicode::Stringprep::Prohibited::C8,
+\...@unicode::Stringprep::Prohibited::C9,
+],
+1,
+);
+my $resourceprep = Unicode::Stringprep->new(
+3.2,
+[
+\...@unicode::Stringprep::Mapping::B1,
+],
+'KC',
+[
+\...@unicode::Stringprep::Prohibited::C11,
+\...@unicode::Stringprep::Prohibited::C12,
+\...@unicode::Stringprep::Prohibited::C21,
+\...@unicode::Stringprep::Prohibited::C22,
+\...@unicode::Stringprep::Prohibited::C3,
+\...@unicode::Stringprep::Prohibited::C4,
+\...@unicode::Stringprep::Prohibited::C5,
+\...@unicode::Stringprep::Prohibited::C6,
+\...@unicode::Stringprep::Prohibited::C7,
+\...@unicode::Stringprep::Prohibited::C8,
+\...@unicode::Stringprep::Prohibited::C9,
+],
+1,
+);
+
# returns DJabberd::JID object, or undef on failure due to invalid format
sub new {
@@ -29,7 +109,16 @@ sub new {
(?: /(.{1,1023}) )? # $3: optional resource
$!x;
-return bless [ $1, $2, $3 ], $_[0];
+# Stringprep uses regexes, so store these away first
+my ($node, $host, $res) = ($1, $2, $3);
+
+return eval {
+bless [
+defined $node ? $nodeprep->($node) : undef,
+$nameprep->($host),
+defined $res ? $resourceprep->($res) : undef,
+], $_[0]
+};
}
sub is_
Re: JID case sensitivity
Peter Saint-Andre wrote: So, to summarize: * The node (before the @) and domain should be case-insensitive. * The resource should be case-sensitive. With the caveat that the concept of case sensitivity applies only to US-ASCII characters and not the rest of the Unicode characters, yes. So when DJabberd parses a JID, it ought to normalize the case in the node and domain parts. It must presumably do this in a way defined in stringprep rather than relying on Perl's in-built ability to turn strings to lowercase. Does Perl's in-built ability apply to US-ASCII only or also to any Unicode character (e.g., normalizing ∏ to π or whatever)? If we only need to worry about US-ASCII characters then this should be pretty easy. Perl's default behavior is to do ASCII-only case conversions, with the option of doing something Unicode-ish, but we don't really make use of Perl's Unicodey features in DJabberd so only having to worry about US-ASCII makes life much easier. Thanks for the hints.
Re: JID case sensitivity
On 3/26/09 7:44 PM, Martin Atkins wrote: > Peter Saint-Andre wrote: >> >> Correct. That might change slightly in rfc3920bis (probably by ripping >> out the dependency on stringprep because it is tied to Unicode 3.2 and >> has all those long, scary character tables), but in a way that will be >> as backwards-compatible as possible. >> > > I would love to see the XMPP spec define the JID syntax without > referring to stringprep. I find it incredibly difficult to understand > definitively what the requirements are. Most people do, which is why we're going to fix it. > So, to summarize: > > * The node (before the @) and domain should be case-insensitive. > * The resource should be case-sensitive. With the caveat that the concept of case sensitivity applies only to US-ASCII characters and not the rest of the Unicode characters, yes. > So when DJabberd parses a JID, it ought to normalize the case in the > node and domain parts. It must presumably do this in a way defined in > stringprep rather than relying on Perl's in-built ability to turn > strings to lowercase. Does Perl's in-built ability apply to US-ASCII only or also to any Unicode character (e.g., normalizing ∏ to π or whatever)? > Is this correct? (and does anyone want to send in a patch? :) ) Sorry, my Perl is awfully rusty. :| Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: JID case sensitivity
Peter Saint-Andre wrote: Correct. That might change slightly in rfc3920bis (probably by ripping out the dependency on stringprep because it is tied to Unicode 3.2 and has all those long, scary character tables), but in a way that will be as backwards-compatible as possible. I would love to see the XMPP spec define the JID syntax without referring to stringprep. I find it incredibly difficult to understand definitively what the requirements are. So, to summarize: * The node (before the @) and domain should be case-insensitive. * The resource should be case-sensitive. So when DJabberd parses a JID, it ought to normalize the case in the node and domain parts. It must presumably do this in a way defined in stringprep rather than relying on Perl's in-built ability to turn strings to lowercase. Is this correct? (and does anyone want to send in a patch? :) )
Re: JID case sensitivity
On 3/26/09 6:03 PM, Alex Vandiver wrote: > On Thu, 2009-03-26 at 16:25 -0700, Martin Atkins wrote: >> Can you reference the specific section of the spec you're referring to? > > http://xmpp.org/rfcs/rfc3920.html#rfc.section.3.3 > > ...states that: > > A node identifier MUST be formatted such that the Nodeprep > profile of [STRINGPREP] can be applied without failing. Before > comparing two node identifiers, a server MUST (and a client > SHOULD) first apply the Nodeprep profile to each identifier. > > http://xmpp.org/rfcs/rfc3920.html#nodeprep > > ..defines the Nodeprep Stringprep type, which includes Table b.2 > in its mapping table. Table B.2 defines case folding for Unicode > in the KC normalization. > > Domain names apply Nameprep, which also specifies Table B.2 for > mappings, and are hence case-folded. Note that resources > identifiers (which use Resourceprep) do _not_ apply Table B.2, > and are thus case sensitive. Correct. That might change slightly in rfc3920bis (probably by ripping out the dependency on stringprep because it is tied to Unicode 3.2 and has all those long, scary character tables), but in a way that will be as backwards-compatible as possible. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: JID case sensitivity
On Thu, 2009-03-26 at 16:25 -0700, Martin Atkins wrote: > Can you reference the specific section of the spec you're referring to? http://xmpp.org/rfcs/rfc3920.html#rfc.section.3.3 ...states that: A node identifier MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied without failing. Before comparing two node identifiers, a server MUST (and a client SHOULD) first apply the Nodeprep profile to each identifier. http://xmpp.org/rfcs/rfc3920.html#nodeprep ..defines the Nodeprep Stringprep type, which includes Table b.2 in its mapping table. Table B.2 defines case folding for Unicode in the KC normalization. Domain names apply Nameprep, which also specifies Table B.2 for mappings, and are hence case-folded. Note that resources identifiers (which use Resourceprep) do _not_ apply Table B.2, and are thus case sensitive. - Alex
Re: JID case sensitivity
Alex Vandiver wrote: Heya, While looking at the roster created in DJabberd::RosterStorage::SQLite, I noticed that JIDs appeared more than once, with differing case. Additionally, case canonicalization doesn't look like it's done anywhere in DJabberd::JID. The RFC implies that resource identifiers are case-sensitive, but node identifiers and hostnames are _not_. Am I misreading the spec, or is there a notable bug here? Can you reference the specific section of the spec you're referring to?
