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
