Subject: Re: IOTP Net Locations

From: [email-masked]
Date: Tue, 5 Jan 1999 14:09:12 -0500

It seems to me that as things stand, the consumer software needs to
maintain a state machine anyway and it already knows who it is talking to
and what messages are reasonable to receive.  So, for v1.0, adding this
SenderTradingRoleRef really just adds some redundant information to check
which can be inconsistant...

On the other hand, if later versions allow a more general transaction
structure, you might need this, especially on non-HTTP transport.  If you
had two emails coming in from two payment handlers or delivery handlers
that were being used in parallel, some more explicit labeling might be very
useful.

I guess I would personally opt for the second (i.e., making the changes
suggested).

Thanks,
Donald

PS:  How about replacing "NetLocn" with "URL"?

Donald E. Eastlake, 3rd
65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
Internet: [email-masked]
Notes: Donald Eastlake/Hawthorne/IBM@IBMUS
1-914-784-7913, fax: 1-914-784-3833, 1-914-276-2668(home)

David Burdett <[email-masked]> on 12/21/98 08:38:50 PM

To:   "'IETF Trade'" <[email-masked]>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  IOTP Net Locations

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]

---

From: "Kent M. Davidson" <[email-masked]>
Date: Tue, 05 Jan 1999 13:03:07 -0800

>PS:  How about replacing "NetLocn" with "URL"?

I agree with this, or "URI", I suppose would also be accurate.

-Kent.

>Tel/Voicemail: +1 415 645 6973     Fax: +1 415 956 9370

___________________________________________
Kent M. Davidson, VP of Advanced Technology
Differential, Inc.
direct (408)864-0604 
fax    (408)864-0601             
mailto:[email-masked]
http://www.differential.com

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 6 Jan 1999 10:48:04 +0100

> I agree with this, or "URI", I suppose would also be accurate.

I would propose URI, and not URL, as very few people know what a URL 
is -- in fact so few that we descided in the IESG to get rid of the 
term URL completely. Note for example that the latest syntax document 
is for URIs and not URLs.

    Patrik

------------------------------------------------------------------
Senior Researcher                             Email: [email-masked]
Tele2 AB                                        URL: http://paf.se
Borgarfjordsgatan 16, Kista, Sweden      PGP Key ID: 0xBD236602

   In theory there is no difference between theory and practice,
   but in practice, there is.
-----------------------------------------------------------------------
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]