> --On Tuesday, 02 July, 2002 23:09 -0700 ned.freed@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@foo.bar> CONNEG > S: 250 OK > C: RCPT TO:<recipient1@target1> > S: 250-OK I actually know her capabilities > S: 250-<...capability stuff> > S: 250-<more capability stuff> > C: RCPT TO:<recipient2@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. Well, it certainly makes sense if you're eliminating REQUIRED to move CONNEG to the MAIL FROM. But as for eliminating REQUIRED, I can only reiterate what I've said before: I was willing to be convinced there was a problem, but the discussion has done exactly the opposite. The only clearly valid argument I've seen so far for removing REQUIRED is that it may not really be needed and things that aren't needed should not be there. But whether or not it is needed is really a question for the WG. Perhaps those who actually plan to implement CONNEG clients could comment on whether or not they view REQUIRED as something they need. > 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@bar.baz> CONNEG=REQUIRED SILLYSTATE=FALSE > S: 250-foo@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? I think what you're driving at is that the CONNEG material needs to appear as a unit and needs to be identifiable as such in the response. If so, this concern was raised previously and I have previously stated that I think it needs to be addressed. It is a simple fix, however. Ned