Re: [Standards] roster schema
Yes, it is a good idea to define more granular errors for these conditions. I'll try to add those to the -04 draft, since I will probably submit the -03 draft today and won't have time to do this (mostly today I'm just going to check for egregious errors). The reason for the hurry is that there's an IETF deadline of first-thing Monday morning to submit Internet-Drafts before IETF 69, missing that deadline will mean the -03 drafts would not be published until after July 23 and I'd like to get my updated documents out there before then so I can gather feedback. Cool OK. It's not set in stone, it's set in wax (SHOULD not MUST). But I'm not going to spend more time on this so I retract the recommendation (not requirement) of limiting the size to 1024 characters or whatever. One thing I was thinking of along these lines would be rather than set the sizes in this way regarding how clients would interact with the server, have a implementation guide for server developers to the recommended sizing for certain fields, not sure if the place for that would be in the RFC but it would help developers by letting them immediately see how they will need to likely size their databases without having to go out and look at other existing XMPP software to try and determine what others are doing first, just a thought. Richard
Re: [Standards] roster schema
Richard Dobson wrote: One thing I was thinking of along these lines would be rather than set the sizes in this way regarding how clients would interact with the server, have a implementation guide for server developers to the recommended sizing for certain fields, not sure if the place for that would be in the RFC but it would help developers by letting them immediately see how they will need to likely size their databases without having to go out and look at other existing XMPP software to try and determine what others are doing first, just a thought. Well, we've always needed an implementation guide. Probably one for server developers and another for client developers. IMHO that would be a great project for a few people to work on (perhaps after the next set of RFCs is published, or concurrent with the RFC process). I don't think all those implementation details belong in the RFCs, however. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] roster schema
Dnia 05-07-2007, czw o godzinie 16:49 -0600, Peter Saint-Andre napisał(a): If the server could handle and client knows it could handle, it could use longer names. How does the client know? It tried to put a long name in a minute ago and it succeeded. 640KB SHOULD be enough for anyone. We're talking about a handle for an IM contact or the name of a roster group here, not the functioning of a complete operating system. Get some perspective. I'm giving you the perspective. We'll defining standards for future use and we simply cannot envision what will be the future requirements. Many tried and failed miserably. Ergo - let's not introduce arbitrary restrictions where these are not needed. This is an implementation issue, so let the implementer and administrator decide. Your concern is clients failing roster sets. Mridul recommended a MINIMUM though and I'm all for for it. When you specify that server MUST handle at least 163 characters (yes Unicode characters, not bytes - again this is an implementation issue), then client authors could set the max limit on 163 and live perfectly fine. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] roster schema
Hello On Fri, Jul 06, 2007 at 10:54:01AM +0100, Richard Dobson wrote: It would be handy to also specify an extended additional error along with the not-allowed/ so that the client can know what part of the roster item is wrong which would add to the flexibility, e.g. name-limit-exceeded xmlns=urn:xmpp:roster:errors/ and groupname-limit-exceeded xmlns=urn:xmpp:roster:errors/. Maybe even add the longest allowed item in the error so the client can know how much it must restrict the user? Like name-limit-exceeded xmlns=urn:xmpp:roster:errors max-len=511/ -- A nuclear war can ruin your whole day. Michal 'vorner' Vaner pgp1GdqT4liGm.pgp Description: PGP signature
Re: [Standards] roster schema
Dnia 25-06-2007, pon o godzinie 09:52 -0600, Peter Saint-Andre napisał(a): If we say that the length SHOULD NOT be more than characters I would rather phrase it, that the client MAY NOT expect server to handle names longer than characters. If the server could handle and client knows it could handle, it could use longer names. It's not like this is completely subjective. Mostly I was thinking about database storage of rosters. It would be helpful for server developers to know that roster item handles and roster group names won't need to be more than characters / octets / bytes long. This is not how modern databases work. Handling of variable length strings and fixed length strings works equally well. Actually it would be a pure waste of space to pre-allocate fixed string of 1023 characters to store 5. This is the server implementation detail. If server could handle it, why discourage it? And if server cannot (or does not want, by config option) to handle it, it should communicate it with well-defined error. If it's a SHOULD then you have flexibility. 640KB SHOULD be enough for anyone. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] roster schema
Hi, I agree with Michal on this one. IMO, ad-hoc limits like these have no place in a protocol standard (especially not in a flexible one like XMPP), because there is nothing 'logic' about them. You are limiting the use of your protocol for no real reason (except that today, most clients don't need/want more). 1024 might seem a good number now, but you'll have to change the number in the RFC over time. Limits like these should be set on the server side, and the server should refuse to create groups larger than 1024 or something like that. cheers, Remko
Re: [Standards] roster schema
The server needs these limits in order to figure out how to size database tables, so there exists a reason. Given that constraint, there are two paths to go down: 1) specify a maximum length 2) specify a way for the client to find out the maximum length either way, you need to specify what happens if the length is exceeded (error, truncation, etc.) The first way is much simpler. It is, but given the reason for it that its for database implementation constraints (i.e. edging towards implementation specific) IMO it would be better to be flexible and go for option 2 and let the implementations decide their limits rather than have it hard coded in the protocol to a value that might not allow for optimal performance in certain environments. I would go for option 2 and specify what error should be returned if the client goes over the limit so it can present the appropriate user interface for the end user. Richard
Re: [Standards] roster schema
Peter Saint-Andre wrote: Currently, the XML schema for the jabber:iq:roster namespace does not limit the length of an item name or a group name. I think that might cause problems. In particular I think it might be good to specify that: 1. The 'name' attribute can be a string between 0 and 1023 characters in length. [1] 2. The XML character data of the group/ element can be a string between 1 and 1023 characters in length. Objections? /psa [1] I am assuming that the following are equivalent: item jid='[EMAIL PROTECTED]' name=''/ item jid='[EMAIL PROTECTED]'/ If we don't like name='' then we could specify that the 'name' attribute must be of non-zero length. But I see no harm in saying that including name='' in a roster set is equivalent to not including the 'name' attribute. +1 for specifying upper limit for octets for each. Naturally there are existing limits to this, but those are implementation details - something standard will give both clients and servers a upper limit confidence. Regards, Mridul PS: Strange, I was discussing about this with some others just a couple of weeks back :)
Re: [Standards] roster schema
What do you mean by character? - Glyph? - Codepoint? Do you have to perform some sort of canonicalization before counting? Combining characters make this particularly difficult, which is why we settled on something easy to describe and understand in JIDs. On Jun 24, 2007, at 7:39 AM, Matthias Wimmer wrote: Hi Joe! Joe Hildebrand schrieb: +1 for limiting it. However, 1024 octets please, rather than characters, like JIDs. +1 for limiting it ... but please based on characters, not on octets. (I also voted against limiting JIDs based on octets.) Reasons: - Modern database systems as well as modern programming languages do store characters, not bytes. - XMPP is based on top of XML and XML does handle characters, not bytes. (e.g. you cannot store a NULL byte in XML, even not as an entity) - A limitation based on characters is what a user will expect. (e.g. Why can I enter 1024 times the letter 'a' here but only 341 times the character €?) - In GUI forms you can often already limit the number of characters a user can enter, but mostly you cannot limit the number of octets the UTF-8 representation of the string the user has entered. ... I'd even propose that the JID limitation should be changed to characters in RFC3920bis. Matthias
Re: [Standards] roster schema
Hello On Sun, Jun 24, 2007 at 11:01:26AM -0400, Andrew Plotkin wrote: On Sun, 24 Jun 2007, Michal 'vorner' Vaner wrote: And it would seem more reasonable to specify (or allow servers to do so) the limit of stanza? Because it is not only the roster then, but private storage, privacy lists... If there must be a limit, then I think the limit should be enforcible by the server, and if server wants to have 2047, then why not? Only if we can guarantee that there will never be cases where one server has to store (or cache) another server's entry. That's a worrisome promise to make. A fixed limit also makes it easier for an admin to migrate server software transparently to his users. With users that store books in their rosters ;-) As I said, such user deserves odd behaviour. I admit that not a lot of people are going to hit this edge case, but in principle... I just do not like setting hard limits in protocol when they do not come out from the logic. I accept there is no need for such long names now and probably will not be at any time, but if I ask why on earth 1023? There were points where there was no choice to put a hard limit (ipv4, for example). But I do not like this limit in the protocol because of someone might be crazy. Is there a limit for size of EMail in the protocol? No, there isn't, if the server considers it to be too big, it tells you. But the too big grows with time, varies by the server and so on. And as I said, if there is a problem with roster items, is there problem with private storage, privacy list and so on? Will all of them be limited? What is the problem with saying the server can have a limit and deny to perform such crazy operation. (BTW, did it happen that someone stored so long string somewhere, or is it just a _possible_ problem?) -- There is one difference between linux and windows. With windows, you pay for the software, but you get all the T-shirts for free. With linux, you get all the software for free, but you buy the T-shirts. Michal 'vorner' Vaner pgpzfpRQZkcLn.pgp Description: PGP signature
Re: [Standards] roster schema
Michal 'vorner' Vaner wrote: Hello On Fri, Jun 22, 2007 at 03:07:05PM -0600, Peter Saint-Andre wrote: Currently, the XML schema for the jabber:iq:roster namespace does not limit the length of an item name or a group name. I think that might cause problems. In particular I think it might be good to specify that: 1. The 'name' attribute can be a string between 0 and 1023 characters in length. [1] 2. The XML character data of the group/ element can be a string between 1 and 1023 characters in length. Objections? I see one possible problem. If you leave the length infinite, everyone counts with it as with infinite. If you set the length to N characters, this may happen: • Someone says no more than N will come and may get a buffer overflow/whatever. • Someone checks it is short enough to fit into a buffer, but uses N bytes instead of characters. What was the problem with infinite length? (Especially, when we do not know how much memory it can take anyway). Typically, both the handle (i.e., the value of the 'name' attribute) and the group name are stored in a database. If you can put the complete text of RFC 3920 as the handle and the complete text of RFC 3921 as the group name, then those values probably can't be stored as sent. Also if these strings can be of infinite length then the packets may become too big to process in the server (10 Meg roster set, anyone?). It seems reasonable to limit the sizes. I doubt that anyone will ever set handles or group names to be even 1024 characters in length, but at least that limit will enable client and server developers to handle the roster items and make sure that roster sets and pushes can be processed. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] roster schema
On Jun 23, 2007, at 7:42 PM, Joe Hildebrand wrote: However, 1024 octets please, rather than characters, like JIDs. +1 on that over here. :) -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
