Subject: IOTP Net Locations

From: David Burdett <[email-masked]>
Date: Tue, 22 Dec 1998 01:38:50 -0000

I've just been working through the following change ...

I. Net Locations. Change net locations in Protocol Options or Trading
Role Elements to reflect:
A. 	SuccessNetLocn - per transaction - Where the Consumer goes if the
transaction is successful
B. 	CancelNetLocn - per trading role - where the Consumer goes if the
Consumer cancels the transaction at some point
C. 	xxxRequestLocn - where xxx is payment, delivery, etc the location to
which incoming messages with either no errors or technical errors of any
Severity are sent. This means that anybody who sends a message with
errors in it receives a message that indicates there was an error
D.	ErrorLogNetLocn - per trading role, optional -  where the Consumer
sends IOTP messages if they receive an incoming message in which they
detect a technical error with Severity of HardError or TransientError.
Could be used to send error messages to the software company or some
other organisation responsible for fixing problems in the software which
sent the incoming message.
E.	ErrorNetLocn - per trading role - where the consumer goes after
receiving or generating an Error Block with severity of HardError or
TransientError
F.	Also need to provide guidelines which indicate how the consumer
determines which redirect location to use based on where they are

... and I've come up with a small problem in that the Consumer needs to
know, definitively, which is the "current" Trading Role which should be
used for cases B, D and E above. As it currently stands, the Consumer
has to infer which Organisation sent the message by knowing what sort of
block has been received and which trading role is responsible for it.

What I suggest is that:
*	we include in the Message Id Component (see section 3.3.2) an optional
SenderTradingRoleRef to identify the TradingRole to be used when
problems occur. This element is only optional for messages sent by the
Consumer role and is required for all others
*	we remove SenderNeLocn from the ProtocolOptions Component as its no
longer needed
*	we also add an ID attribute to the Trading Role Element (see section
6.5.2) so that it can be identified

Thoughts?

David

>Mondex International Limited
mailto:<[email-masked]>
>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>94111
Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]