Re: Keywords for "SMTP Service Extension for Content Negotiation"

At 07:11 PM 7/12/2002 +0900, Hiroshi Tamura wrote:
>There will be lots of discussion at FAX WG meeting in Yokohama.
>For your convenience, I summarize the keywords at very random,
>although they may not be covered.

Tamura-san, thank you very much for listing these terms.  It is easy to 
forget that these terms are not familiar to everyone.  Also, the discussion 
has sometimes been confusing  I encourage people to list additional terms 
that should be explained.

Here are my own, personal comments and explanations.  I think some are 
simple, but others might be controversial.  Also there might be more than 
one explanation.  I encourage others to offer their own versions:


>- fax-specific or not

It is strange,  but I think this is the most difficult term.  When we talk 
about T.30, it is easy to know what it means to say "fax-specific".  When 
we talk about FFPIM, perhaps it is not so easy.

For the IETF Fax working group, I believe "fax-specific" refers to features 
and functions that emulate T.30.  That is, we are trying to make Internet 
mail provide the same service as T.30.  So, "fax-specific" refers to email 
enhancements that permit email to work like fax.


>- multi-recipient

Internet mail permits a message to be addressed to more than one 
person.  For example, see the To and CC fields of this message.  T.30 
permits addressing a single receiving device.  Some fax store-and-forward 
services permit the sender to specify more than one receiver.  This is 
multi-recipient.


>- LCD

Least Common Denominator.  So, we are borrowing a term from math, to apply 
to our discussion of ESMTP/CONNEG, it is possible to receive CONNEG 
parameters for multiple recipients.  If the recipients have different 
capabilities, what capabilities should the sender use?  One possibility is 
to end the current SMTP session and then send each recipient the best 
content they can receive.  Another possibility is to find the 
"intersection" of capabilities for all the recipients and send this "least 
common denominator" or "most common format" to all of the recipients at once.


>- new command RCAP??

The current ESMTP/CONNEG specification uses the RCPT command for finding 
each recipient's capabilities.

Moore-san prefers to have the capabilities query be in a separate 
command.  For convenience, he has given this command a name, RCAP.  So, the 
name refers to an idea that Moore-san has.  There is no written 
specification for that command.  In my opinion, the current specification 
is satisfactory.


>- RSET
>- VRFY

These are SMTP commands.  RSET ends the current SMTP session.  The command 
means "reset".  VRFY lets a client SMTP ask a server SMTP to "verify" the 
validity of an address, before using it.  This command is no longer very 
popular, because it provides an easy way for spam senders to test for new 
addresses.


>- consideration of relay

Facsimile is direct, point-to-point.  The sending device and the receiving 
device are connected to each other at the same time.  They talk with each 
other directly.

Internet mail is store-and-forward.  The sender and the receiver are not 
required to be connected to the Internet at the same time.  The email may 
go through intermediate email services, when moving from the sender to the 
receiver.  (For example, it may go from a department's SMTP mail system to 
the enterprise system; the enterprise system may send it to the receiving 
enterprise's system; the receiving system may then send it to the 
receiver's department email server.) This is like packet switching.  Each 
intermediate system is "relaying" the email.

The primary difference between relaying versus direct is that relaying 
might take much longer.  Therefore the sender does not know when it will 
receive a response.

On the Internet, a direct connection usually has a response time of a few 
minutes, maximum.  Normally it is much shorter, of course.  For email 
relaying, response time can be days, not minutes.  This difference in 
latency requires different design choices.


>- content transforamation

Converting content from TIF to JPEG, and JPEG to GIF are examples of 
content transformation.  Converting from UTF-8 to UTF-16 is also an example 
of content transformation.


>- only CONNEG or CONNEG=REQUIRED/OPTIONAL

I do not know what "only CONNEG" means, here.


>- interoprability with existing environment

When we add a new feature, how does it affect the old operation?  Sometimes 
adding a new features makes the old system stop working.  For MIME, the 
goal was to add a new feature that made no change to email transport and 
also would not break an old email user agent.

The goal with ESMTP options is to make old operations behave the old way, 
but permit participants who support a new option to use them with each other.


>- how to handle with response/status code

I believe this refers to a concern that ESMTP/CONNEG uses extended ESMTP 
response/status codes in an usual way.  The concern is not widely held.


>- real-time

I think that we use this term very informally in the Fax working group 
discussions.  Probably it simply means "quickly".  Perhaps we can simply 
use it to mean "within the limits of T.30 timeouts" -- 2 seconds?

For the design of human interaction, real-time usually mean 1/2 second, or 
less.  For the design or high performance system, it can refer to 
milliseconds or microseconds.


>- bandwidth

The amount of data that can be send within a period of time.  The bandwidth 
of a T1 (or E1) line is very much greater than a dial-up connection.


>- multipart/alternative

The MIME standard for Internet mail specifies a means of attaching one or 
more segments (body-parts) of content.

Multipart/mixed is used for specifying multiple attachments that are not 
related to each other.

Multipart/alternate is use to specify multiple attachments that are 
different versions of the same content.  For example, one might be ASCII; 
another might be HTML, and another might be PDF.

When the sender does not know the capabilities of the recipient, the sender 
can use multipart/alternative to send more than one version of the 
content.  The sender is guessing that the receiver can process at least one 
of the forms.


>- security

Gomen nasai.  This is a very big topic, of course.

I think the discussion of security for ESMTP/CONNEG only has the concern 
about violating privacy.   By using this option, the receiving server is 
divulging features of the recipient.  It is possible that such information 
is private, or that distribution of such information must be restricted.


>- Experimental or Proposed Standard

The IETF standards process has 3 classes of categorization:

And Experimental document is NOT on the standards track.  The document is 
published for the benefit of the community and the author is requesting 
feedback, especially comments about experiments that use the specification.

A Best Current Practises categorization refers to documents that describes 
operations and administration procedures.  They do not define protocols, 
they define the USE of protocols and procedures.

The IETF standards track has 3 levels:  Proposed, Draft and (full) 
Standard.  Proposed is the first level.  A document must be complete, for 
the task it defines and must have no known errors.  However the 
specification usually does not have to be implemented and 
tested.  Implementation and testing are required to reach Draft standard.

In the discussion for ESMTP/CONNEG, some participants are concerned that 
the option may cause bad effects on normal SMTP usage.  They believe that 
the specification should be classed as Experimental until it is tested.  My 
own comments about this are that all new protocols carry some risk.  The 
pressure to select Experimental (non-standards) status usually is reserved 
for specifications that are complicated and poorly understand, or for 
specifications that have an inherently high degree of risk.

In my opinion, ESMTP/CONNEG is a simple option with little risk.  I believe 
that we DO need to learn to use it.  It DOES add some complexity and it 
extends use of the ESMTP option feature in some way.  However I believe 
that the risks involve efficiency, not core functionality.  That is, I 
believe that implementors must learn to make the option work well, but that 
the option should be relatively safe.

d/

----------
Dave Crocker  <mailto:[email protected]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850