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

At 12:04 PM 7/13/02 +0900, Dave Crocker wrote:
>>- 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.

I'm uneasy about (appearing to) equate fax-specific with just T.30 -- I 
think your last sentence carries the intent if not the desired precision -- 
maybe:
[[
"fax-specific" refers to email enhancements that permit email to negotiate, 
transmit and confirm the transfer of images in timely fashion, like 
traditional fax.

Traditional email, by contrast, transmits any data and does not impose any 
requirement that the data can be processed by the recipient or that the 
recipient confirm its receipt.
]]

>>- 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.

If you mention fax store-and-forward, I'd suggest a comment to the effect 
that such services behave in a fashion more like ordinary email than 
fax.  (I.e. saying that fax does store and forward like email doesn't of 
itself mean that providing a fax-like service requires Internet fax should 
support all fax features for multiple recipients.)

>>- 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.

This term has often puzzled me as being incorrect in its mathematical 
allusion.  The terms "greatest common divisor" or "highest common factor" 
seem more apposite.

>>- 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.

I think there's a more fundamental architectural issue that is exploited by 
traditional fax operating in a non-relay mode:  normal operation requires 
that the sender can receive some indication from the receiver before it 
starts to send any actual data.

>>- 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.

A further consideration that very strongly influenced the user-agent-based 
negotiation mechanism is that no messages should be sent in assumption that 
the receiver is anything other than a plain old fashioned mail client, and 
that all messages received by such a client could be presented to the 
recipient user as ordinary email messages.  ("No administrative non-messages").

>>- 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.

My working definition of real-time:  if some data is received late, then it 
is wrong.  This pointedly doesn't say what it means to be late.

>>- 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.

A closely related concept is latency:  the amount of time that elapses from 
sending some data to the point that the receiver starts to receive it.

#g


-------------------
Graham Klyne
<[email protected]>