nor have I managed to find a use case for treating no conneg
string as a fatal error, though I don't claim to have exhaustively
analyzed all possibilities yet.
The obvious case would be one where interoperability between sender and
recipient has to be guaranteed. Whether this is a case we should care
about is another matter.
I note in passing that the original proposal required treating the lack of a
conneg string as a fatal error. I saw far more utility in allowing the case of
no conneg string to be allowed without an error.
Sigh. This is pretty much a strawman argument, but rather than get into that
let me simply repeat my earlier conclusion: I believe that if support for
sending more than one variant of the same message is likely then a separate
command makes sense. If, on the other hand, this is the very uncommon case,
then RCPT TO piggybacking is much simpler and a separate command doesn't
make
sense.
Do you really wish to claim otherwise?
Hmm. If I'm trying to compare protocol and implementation complexity then
I care about the amount of code that's required to accomodate all cases even
if many of those cases aren't used very often. If I'm thinking about protocol
efficiency then I care more about the commonly occuring cases.
as for what is a commonly occuring case, I get a different answer depending
on whether I think of this as a fax-specific mechanism or a general purpose
SMTP mechanism. if it's only fax specific then I suspect the common case
is for most messages to have only one recipient, so if the rare
multi-recipient
message takes a slow path that might not be so bad. if the mechanism is
more general purpose then I suspect multi-recipient messages (and
widely-varying
capabilities) will be much more common and it will be more desirable to
avoid sending a separate copy of each message, and this in turn makes
reasonable implementations (of either proposal) more complex.
I'm less sanguine about making this assessment a FAX-vs-other-uses thing, but
the bottom line is that I think we're pretty much in agreement here.
what I'm discovering is that I'm much more concerned about overloading
the RCPT reply/status code rsponses (using them to mean two different)
things than I am about piggybacking a conneg string onto the RCPT
response. if the conneg response didn't affect the reply and status
codes, and if other extensions could also piggyback additional data
onto the RCPT response, then I don't think that the fact that additional
information is being requested along with RCPT would bother me. the
thing that bothers me is that RCPT error codes are being used to signal a
case that really has nothing to do with the recipient's ability to
receive a message.
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.
but it's hard to see how the client can avoid implementing some
kind of logic to convert differently for different recipients, since
there's clearly the potential for the recipients' conneg strings to
have no format in common. perhaps if the client can only do one
or two different kinds of conversion (otherwise it has to bounce)
then the decision becomes a bit easier, but this again looks more
like a fax-specific facility than a general one.
On the contrary, I suspect that this issue can and will be avoided. John
phrased it well: Select the least common demoninator that's above a certain
threshhold. That sounds like the right implementation strategy to me.
that assumes that there is a LCD, which is not true in general.
(though it might be true for a fax-only extension.)
and unless the set of permissable content-types is severely restricted,
how can the client know what is a reasonable threshhold?
Such thresholds are driven by the client's own capabilities, not on the
capabilities of the recipient.
Ned