Message-Id: <199707122304.TAA16722@CS.UTK.EDU>
From: "Jeff Stephenson" <jeffstep@microsoft.com>
To: "John C Klensin" <klensin@mci.net>
Cc: <drums@cs.utk.edu>
Subject: Re: Sizes in draft-ietf-drums-smtpupd05.txt
Date: Sat, 12 Jul 1997 16:06:32 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Saturday, July 12, 1997 12:39 PM John C Klensin <klensin@mci.net> wrote

>> I think we should go beyond advice, as 821bis would then still brand MTAs
>> attempting to send longer addresses as non-compliant.
>
>Jeff, unless I've screwed up, that is not the case today.
>What 1123 does is to tell
>
>   * servers that *they* are non-compliant if they won't
>accept addresses at least as long as the limits
>
>   * clients that they must be prepared for servers to
>reject longer strings.  That doesn't make them
>non-compliant if they send them; it does make them
>non-complaint if the response to a rejection of a longer
>address is pathological behavior (e.g., blowing up, closing
>connections, ignoring the response code,...)

Yep, you're right.  What was I thinking ;-)?

>> Another suggestion would be to simply remove the phrase "but SHOULD
>> NOT send objects larger than these sizes" from section 4.5.3 and to
reword
>> the limits to indicate that they are minimum required sizes, not maximum
>> allowed sizes.  Warnings about former 821 limits would still be
appropriate.
>
>The difficulty is that there are too many shadings of
>"Should".  Here it was intended to mean "not unless you
>have to, and don't make it a routine practice".  I'll work
>on it, but would welcome specific text.

How about:

----------------------------------------------------------------------------

4.5.3.  SIZES AND TIMEOUTS

There are several objects that have required minimum maximum sizes.  That
is, every implementation MUST be able to receive objects of at least these
sizes.  Further, implementations SHOULD NOT send objects larger than these
sizes except in special circumstances as noted below.  When implementations
send objects larger than these sizes in a command, they MUST be prepared for
an error response rejecting the command because of the size of the objects.

****************************************************
*                                                  *
*  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
*  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
*  OF THESE OBJECTS SHOULD BE USED.                *
*                                                  *
****************************************************

local-part

   An implementation MUST be able to receive a user name or other local-part
   which is not longer than 64 characters.  Because this size may not be
   sufficient to accomodate important cases (such as encoded X.400 addresses
   [RFC-X400]), larger local-parts MAY be sent, but the receiving
implementation
   MAY reject them.

domain

   An implementation MUST be able to receive a domain name or number which
   is not longer than 64 characters.  Because this size is smaller than the
DNS
   limit on domain names, implementations MAY send domain names which are
   not longer than than 255 characters, but the receiving implementation MAY
   reject them.

----------------------------------------------------------------------------


BTW, you've got a note in the draft concerning the "552 Too many
recipients." response wondering if it should be 452 instead.  I think that
_both_ are useful: 552 means "You just hit my hard-coded limit; I'll never
accept more.", whereas 452 means "I might be able to handle this many
recipients at another time, but not now."  In the latter case you might
decide to requeue the message and try later, whereas in the former you've
got to do something else.

-- jeff