I see we're still painting the bike shed here... Tomasz Sterna wrote: > 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 XXXX characters > > I would rather phrase it, that the client MAY NOT expect server to > handle names longer than XXXX characters.
The phrase "MAY NOT expect" is meaningless in a protocol specification. A spec defines what the two entities in an exchange MUST, SHOULD, or optionally MAY do. Expectations have nothing to do with it. > If the server could handle and client knows it could handle, it could > use longer names. How does the client know? Shall we define a discoverable feature for something so trivial? But we don't want RFC 3921 to depend on XEP-0030. So it would need to be a stream feature or somesuch. Which seems really silly to me. >> 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 XXXX 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." 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. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
