Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard




--On Tuesday, 02 July, 2002 23:09 -0700 ned.freed at mrochek.com
wrote:

> Well, it is certainly possible to arrange the additional
> conneg data so it is identifiable as such. As for not
> affecting the response, I'm not sure I see the problem: If the
> client wants an interop guarantee, it requires a conneg
> response, and handles 4yz and 5yz codes as temporary or
> permanent failures without regard to what's causing the error.
> If, on the other hand, it wants conneg info as long as its
> available, it makes a conneg response optional, in which case
> the status codes no longer have anyhing to do with conneg
> information.

Ned, purely as a strawman, suppose we turned things around as
follows:

C: EHLO ...
S: 250-Yep we speak that here
S: 250-...
S: 250-CONNEG
C: MAIL FROM:<poor-sod at foo.bar> CONNEG
S: 250 OK
C: RCPT TO:<recipient1 at target1>
S: 250-OK I actually know her capabilities
S: 250-<...capability stuff>
S: 250-<more capability stuff>
C: RCPT TO:<recipient2 at target2>
S: 250 OK but that is a relay site and I dont have a clue

Client now figures out that it has one recipient with known
capabilities and one with unknown ones.  Based on that, it
either  sends RSET and tries something else, or sends DATA and
the default [fax?] format.  Considerably cleaner, IMO, than
"REQUIRED" on some, "OPTIONAL" on others, etc.

This does, however, point out another problem with the general
approach, regardless of whether CONNEG appears with MAIL, RCPT,
or VRFY.  Let's assume the latter, since it doesn't get involved
with other semantics, but the other cases are pretty much the
same.

C: EHLO ...
S: 250-OK
S: 250- ...
S: 250- CONNEG
S: 250 SILLYSTATE
C: VRFY <foo at bar.baz> CONNEG=REQUIRED SILLYSTATE=FALSE
S: 250-foo at bar.baz ok. probably.
S: 250-CONNEG <some capabilities stuff>
S: 250-<some silly state stuff>
S: 250 CONNEG <more capabilities stuff>

Looks like an interesting parsing/accumulation problem in the
best of cases.   Now, of course, this wouldn't occur with the
document as written, because it appears to prohibit the use of
CONNEG with any other options that might impact the RCPT reply.
Another case not analysed and documented?

     john





Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.