Richard Dobson wrote: > >> 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). > > 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"/>.
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. > This will allow the client to present the appropriate message to the > user as to what they need to modify, this along with the not set in > stone limit of 1023 is flexible enough for me. 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. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
