ietf-smtp
[Top] [All Lists]

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

2002-07-02 19:06:10

Keith,

At 09:14 PM 7/2/2002 -0400, Keith Moore wrote:
        1. do the necessary protocol fixes to make it generally
           applicable for email

Given that we DID make this generally applicable for email, someone still 
needs to list the way(s) the current specifications is deficient in that 
regard.  What capabilities or scenarios need to be support that cannot be 
with the current specification?

go back and reread my earlier messages.

        2. make clear that it has only limited applicability
           for smtp-to-fax gateways,

Perhaps you missed the portion of my response that pointed out that it is 
not limited to that use and, in fact, that is not even its primary intended 
use.  If there is something in the specification that indicates otherwise, 
please point it out.

I've done so.  go back and reread my earlier mssages.

           same capabilities, and where relaying and forwarding
           were specifically disallowed.

There is a difference between being optimized for single-user and/or 
single-hop scenarios, versus prohibiting multi-user and/or multi-hop 
scenarios.  As nearly as I can tell, you are missing that difference.

the current document leaves relaying and forwarding undefined.
this needs to be fixed.  it might be a simple fix, but it's still an
omission.

           however if pursuing this path it would still be necessary to
           leave room for VOICENEG or MIMENEG or whatever,

If you would supply some sort of functional description for these, it might 
be possible to understand how the current specifications fails to satisfy 
them.  I have no idea what you are intending, and therefore cannot even 
guess at the deficiencies you are implying.

I'm not going to waste the time to try to specify something which I'm
clearly convinced is a Bad Idea.  

- Also, unless the client is acting directly on behalf of the
recipient (which is not required by the draft)

Please specify what you mean by "acting directly on behalf of the 
recipient" and how the current specification fails to provide the necessary 
technical specification.

I've already done so, by saying that the recipient needs a standard way
to set the conneg string that is returned.  

 the client
is being asked to make a convert-or-fail decision without
any reasonable (sender-supplied or standardized) criteria as
to what kinds of conversions are acceptable.

This seems like another major omission in the current spec.

You again seem to be missing the fact that that "omission" predates CONNEG 
and has been part of Internet mail for 8 years.

I'm not aware of a content-specific convert-or-fail decision that has to be 
made as part of Internet mail, much less one that has been around for 8 years.

Keith  

<Prev in Thread] Current Thread [Next in Thread>