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

> 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