If I ask nicely, can I recommend replacing username varchar(32) NOT NULL with username varchar(64) NOT NULL from the release of your code. Although I know how to go in and change everything before I run the wildfire program the first time, that is one administrative task I could avoid if it were already setup that way. I have found that many of my personnel in India, for example, have names that will go over the (32) char limit. Just a suggestion, but it would be nice!
Jeff
Hi Jeff,
as fas as I know the code one uses always a java String value of variable length and not a String(32) one so it should be no problem.
May one link me to the JEP / core where the username length is defined.
LG
THe VARCHAR length is defined in the .sql script under resources/database. Altering these scripts allows me to enter usernames that are longer than 32 chars adn lets my folks log in.
Jeff
Hi Jeff,
yeah, for the database this is likely no problem, but if someone defines a String(32) variable within Wildfire it will cause trouble.
LG
So I ask again, whoever writes the wildfire_postgresql.sql script, can you please alter the table VARCHAR for username to (64). heck if you like I will FTP you the entire database dir with changes and you can cut and paste…
Jeff
Hi Jeff,
I may quote “http://www.ietf.org/rfc/rfc3920.txt” 3.1 Overview:
Each allowable portion of a JID (node identifier, domain identifier,
and resource identifier) MUST NOT be more than 1023 bytes in length,
resulting in a maximum total size (including the ‘’@’’ and ‘’/’’
separators) of 3071 bytes.[/i]
It helps a lot to find a definition before changing values without the knowledge whether something will be violated.
So one may create an issue to change it for all databases and it’‘s not only the username, also the roster table where JID(1024) is defined but should be (1023*2+1). But I’'ll talk to Gato before creating an issue.
LG
So what you are saying is that if ones name takes up more than 32 characters then you must shorten it to fit in with the document? How narrowminded was that? I mean my name is short and easy. However if one’‘s name contains 21 characters in the first name, and 15 to 25 characters in the last name then I guess you are just out of luck as far as xmpp? IMHO, That is very mis-guided thinking on the committee’'s part.
Jeff
Hi Jeff,
was the RFC so confusing? It says 1023 characters are allowed (while Wildfire allows currently only 32 characters). One of the next releases will allow 1023 characters, you can track it with JM-700.
LG
the bytes descriptor was what threw me, along with your answer., I took it to mean that the 32 char limit equated out to the byte limit of the RFC.
Jeff
Jeff,
Thanks for the bug report. Just to clarify some of the messages in this thread: the JID should indeed allow for 1024 total characters. However, the username is not meant to be a full JID, just the “node” part of the JID. I agree that 64 characters is a more reasonable limit than 32, though, so will make the change.
Regards,
Matt
The RFC states that the (total) JID can be as large as 3071 bytes. Each allowable portion of the JID MUST NOT be larger than 1023 bytes (last paragraph of page 5 of RFC 3920). 1023*3 plus an @ and a slash make 3071.
With this in mind, does it make sense for Wildfire to allow up to the maximum for all components (node, domain and resource)? That way you shouldn’'t even be able to run into problems when connecting to other domains that allow (up to) the maximum number of bytes in a JID.
Hi Guus,
that’‘s indeed what the RFC states. But some databases have trouble with PK’'s larger than 400 bytes so with the current database design it is not possible to achive this.
I did post an ERD of how it could work here: http://www.jivesoftware.org/community/thread.jspa?threadID=20970 so JS.org could offer a more xmpp compliant server.
And I try to work with Gato on a wildfire_master.sql and make script to create the wildfire_$db.sql scripts for every database automatically. So one can define how long the whole JID may be for every database, this would be nice for HSQLDB and Oracle users but will not help MsSQL or MySQL users to use longer JID’'s.
LG