Re: Keywords for "SMTP Service Extension for Content Negotiation"
2002-07-12 21:44:07
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:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.850.1850
|
|