Joe Hildebrand wrote: > > On Jul 4, 2007, at 8:34 AM, Richard Dobson wrote: > >> It is, but given the reason for it that its for database >> implementation constraints (i.e. edging towards implementation specific) > > I would argue that with PEP, and the access control models that it has, > although this may be implementation-specific, almost every server > implementation is going to grapple with this over time. > >> 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. > > It would be more flexible, at the cost of simplicity. I disagree that > this flexibility is important.
Has anyone put forward a use case for which this flexibility is needed?
>> 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.
>
> Would you suggest protocol and standards language then?
In my working copy of rfc3921bis I have:
***
The server SHOULD return a <not-allowed/> error to the client if the
roster set violates any of the following rules:
1. The <item/> element MAY contain a 'name' attribute, but the value
of the 'name' attribute SHOULD NOT be more than 1023 characters
in length.
2. The XML character data of any given <group/> element MUST NOT be
of zero length and SHOULD NOT be more than 1023 characters in
length.
***
It says SHOULD NOT. If a server has good reasons to go over 1024, it is
perfectly allowed to do so. So this is a guideline, not a requirement.
As a guideline I think it makes a lot of sense (we can quibble over the
size).
Are there objections to that text? Suggestions for improvement?
We're painting the bike shed here, folks.
http://www.bikeshed.com/
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
