ietf-822
[Top] [All Lists]

Re: remove X.400 types

1991-04-29 07:15:54
Excerpts from transarc.system.ietf-822: 28-Apr-91 Re: remove X.400 types
Bob(_at_)mel(_dot_)dit(_dot_)csiro(_dot_)au (819)

It will be desirable for mail UAs to be able to find out what optional
bodyparts are supported by the recipients UA [so your UA can at least make
helpful comments like: "Recipient doesn't support Scribe, suggest you send
postscript."]

The obvious place to keep such information is in the X.500 directory.
I know there is a project to evaluate X.500 in the Internet. How is
that going? Will my suggested application [given user(_at_)dom(_dot_)ain type 
address
return some special information about the user] work? Will the performance
be acceptable?

Use of directory services for this problem has bothered me for years.

What does a composing/sending-UA do when it can't find out what the
receiver's message-format capabilities are?  Query the human driver
(send formatted, send MAILASCII, send PostScript rather than Scribe,
hold the message to be sent later)?

What does the receiving-UA do when it can't decode a received message? 
The minimal thing, given that the real message headers are still
MAILASCII, is for the human driver to send an ordinary reply saying that
the message was unintelligible.  Is this adequate?  What automatic
support should receiving-UAs provide to their human drivers for managing
the task of sending rejection messages?  This is a bit of new ground.

                Craig

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