[Standards] roster schema

[Peter Saint-Andre]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070704/5768e699/smime-0001.bin