Re: Last Call: SMTP Service Extension for ContentNegotiation to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 23:43 -0700 on 07/02/2002, ned.freed@mrochek.com wrote about Re:
Last Call: SMTP Service Extension for Content Negot:

>  > Keith's operational plan can be done by sending RCPT TO (where he would
>>  send RCAP) and terminating the sequence with RSET.   This way the RCPT
>>  TO acts just as the RCAP would act in his model (as I understand it).
>>  Sure, it isn't as clean by any means, and makes the server do a little
>>  extra work, as it doesn't know the RCPT TO's aren't real ones when it
>>  receives them, but as a trade off, it seems OK.
>
>Ah. Using the first round of RCPT TOs as capabilities checks only and sending
>the RSET unconditionally is really quite cute. It still has the added
>complexity of having multiple commands per recipient, but now it is the same
>command repeated, which eliminates a bunch of the edge conditions
>and makes the
>silly states very silly indeed.

The RSET can be made optional by ONLY sending it if the replies to
the RCPT TO requests return a result that requires multiple copies of
the message.

IOW: If the LCD of all the replies is the BEST version you are
capable of sending (such as getting back some "I support color"
replies mixed with "B+W-only support" replies when you only have a
B+W Fax), then just bypass the RSET and retransmission of the RCPT
TOs and go direct to DATA (and collect your $200).


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]