[comp.protocols.iso.x400] ? no feedback to submit.rq possible ?

am@heike.informatik.uni-dortmund.de (Arnulf Mester) (07/20/90)

Hello!

As I understood X.400(84), an originator of a message may never get
ANY feedback about the fate of his message. There seems to be no
mandatory feedback to the originator, only "desirable" (non)-delivery
notices and/or IPM (non)-receipt notifications. These notifictions
may be discarded anytime when not deliverable/forwardable to the
originator of the original message.

Am I right?

Does X.400(88) also have this "sloppy behaviour"?

Kind regards,
	Arnulf Mester

j.onions@computer-science.nottingham.ac.UK (Julian Onions) (07/20/90)

> As I understood X.400(84), an originator of a message may never get
> ANY feedback about the fate of his message. There seems to be no
> mandatory feedback to the originator, only "desirable" (non)-delivery
> notices and/or IPM (non)-receipt notifications. These notifictions
> may be discarded anytime when not deliverable/forwardable to the
> originator of the original message.
>
> Am I right?

Well I guess so in a sense. But you can't do much more than this
anyway. X.400 allows you to set the report level at the P1 (envelope)
level. You can request no-reports, failure-reports or failure +
delivery reports. If you set the last of these, you should get some
response under normal conditions.

However, Email is basically datagram like in nature. There is no way
to gaurantee a message will get delivered from here to there. For
instance, one of the intermediate systems may be struck by lightning
while it has the message in its queues and so reduce to ash -- or less
drastically the routing tables will screw up and deliver the response
to the University of Mars.

All that X.400 gives you is the attempt at reporting back what
happened, and this will work under normal conditions. What it
advantage it has over RFC-822 (in this area) is the ability to request
sucessful delivery reports as well as failures.

If you really want your message to get through, you should set the
full report level, and no confirmation/failure note has arrived, you
can resend.

Think of it as a datagram network, you send out a packet (message) and
await an ACK/NAK. If one doesn't arrive, you timeout and resend.


There are similar facilities at the P2 (message) level. This is more
oriented to the user taking action though, so they can say they have
seen your message. It is possible to make this automatic in a UA when
the message is shown to the user, but that opens up a whole can of
worms about what you mean by "the user has read this message".


X.400(88) has a whole host of features for proving that a message has
got to the recipient you wanted it to get to, but these are more
oriented to giving you proof that the letter you sent declaring war on
Antarctica was really from you and for the recipient.


Julian.