Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOW00A01EXU3H@eListX.com>; Tue, 25 Jan 2000 10:56:18 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOW00A01EXT3F@eListX.com> (original mail from services@eListX.com); Tue, 25 Jan 2000 10:56:17 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOW00A03EXR3D@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Tue, 25 Jan 2000 10:56:16 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOW00A01EXQ3C@eListX.com> for ietf-trade@filter.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Tue, 25 Jan 2000 10:56:14 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-31 #39671) id <0FOW00A01EXQ3B@eListX.com> for ietf-trade@lists.eListX.com; Tue, 25 Jan 2000 10:56:14 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-31 #39671) with ESMTP id <0FOW007AZ4JNZS@eListX.com> for ietf-trade@lists.eListX.com; Tue, 25 Jan 2000 07:11:48 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21836; Tue, 25 Jan 2000 07:10:25 -0500 (EST) Resent-date: Tue, 25 Jan 2000 10:56:14 -0500 (EST) Date: Tue, 25 Jan 2000 07:10:25 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-xmlmsg-requirements-00.txt Sender: services@eListX.com To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Resent-message-id: <0FOW00A02EXQ3C@eListX.com> Message-id: <200001251210.HAA21836@ietf.org> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_nqcj9taOly7Lv8Ku/KtiDg)" --Boundary_(ID_nqcj9taOly7Lv8Ku/KtiDg) Content-type: TEXT/PLAIN; CHARSET=US-ASCII A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Requirements for XML Messaging Version 1.0 Release 00 Author(s) : D. Burdett Filename : draft-ietf-trade-xmlmsg-requirements-00.txt Pages : 60 Date : 24-Jan-00 This specification contains requirements for a generic approach to the reliable, resilient, secure, tamper resistant, authenticated exchange of XML or other electronic documents over insecure transport mechanisms. The specification provides the requirements and framework for a set of related specifications on XML Messaging covering: o Requirements for XML Messaging (this paper) o Common XML Message Elements o Document Exchange and Transactions o Reliable Messaging o Secure Messaging o Document Choreography Definitions o Common Document Exchanges o Transport Protocol Supplements Although much work has been carried out on the other parts of the XML Messaging specification described above, they are sill in development A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-xmlmsg-requirements-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-xmlmsg-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-xmlmsg-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_nqcj9taOly7Lv8Ku/KtiDg) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_Ckb1y4pjjPH2QjiNfZeEpw)" --Boundary_(ID_Ckb1y4pjjPH2QjiNfZeEpw) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000124125617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-xmlmsg-requirements-00.txt --Boundary_(ID_Ckb1y4pjjPH2QjiNfZeEpw) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-xmlmsg-requirements-00.txt Content-disposition: attachment; filename=draft-ietf-trade-xmlmsg-requirements-00.txt Content-Type: text/plain Content-ID: <20000124125617.I-D@ietf.org> --Boundary_(ID_Ckb1y4pjjPH2QjiNfZeEpw)-- --Boundary_(ID_nqcj9taOly7Lv8Ku/KtiDg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOV00801BQQ24@eListX.com>; Mon, 24 Jan 2000 20:49:38 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOV00801BQO23@eListX.com> (original mail from hiroya@sdl.hitachi.co.jp) ; Mon, 24 Jan 2000 20:49:37 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOV00803BQN21@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 24 Jan 2000 20:49:35 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOV00801BQM20@eListX.com> for ietf-trade@filter.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 24 Jan 2000 20:49:34 -0500 (EST) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by eListX.com (PMDF V5.2-31 #39671) with ESMTP id <0FOV0070XBQKZS@eListX.com> for ietf-trade@lists.eListX.com; Mon, 24 Jan 2000 20:49:33 -0500 (EST) Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id KAA09248; Tue, 25 Jan 2000 10:47:28 +0900 (JST) Received: from bisdmail.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id KAA20866; Tue, 25 Jan 2000 10:47:28 +0900 Received: from toro by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with ESMTP id KAA13560; Tue, 25 Jan 2000 10:47:27 +0900 Date: Tue, 25 Jan 2000 10:38:54 +0900 From: Masaaki Hiroya Subject: Re: IOTP Implementations - Who's on First? In-reply-to: <2B30A9965635D311A29F002035297FFB1B2AE1@se001010.rbc1.royal bank.com> X-Sender: hiroya@sdl99a.sdl.hitachi.co.jp To: "Smith, Chris " , IOTP Group Message-id: <4.2.0.58.J.20000125101802.00a47e00@bisdmail.bisd.hitachi.co.jp> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Content-type: text/plain; charset="us-ascii"; format=flowed Hitachi has been developing a software based on IOTP 1.0 and some additional specifications for an order packaged content, a pay note packaged content and server-to-server communication, consisting of servers (Merchant, Payment Handler and Delivery Handler) and a client in SMILE project funded by MITI. It will support purchase transaction using SET, SECE(debit), NTT Super Cash and Mondex. Actural trial of SMILE project is planned from March to the end of August in 2000. Masaaki Hiroya Hitachi, Ltd. At 14:27 00/01/18 -0500, Smith, Chris wrote: >At some point, those of working on IOTP will need to >consider testing interoperability. Right now, I know of only >2 (or maybe 3) groups actively working on IOTP components. > >For those who are doing so in anything remotely resembling >a corporate environment, it helps immensely if we can say, >with some evidence, how many different groups are involved. > >I realize that some people will want to be circumspect about >their plans. However, we can all help each other if we can >speak up to indicate that some implementation work is >planned or underway. > >Longer term, if IOTP is to move towards an IETF standard, >we would have to demonstrate interoperability of the >independent implementations. We might as well get started >on thinking about this, too. > >To get this started - from my point of view: > >Royal Bank (of Canada) has a production IOTP implementation >of Withdrawal and Deposit of Mondex value. We built both an >IOTP server and a Windows client. It is in use, in >production, by customers of the bank. > >------------------------------------------------------------ > Chris Smith +1.416.348.6090 > Royal Bank chris.smith@royalbank.com ----- Masaaki Hiroya Systems Development Laboratory Hitachi, Ltd. email: hiroya@sdl.hitachi.co.jp tel: +81-44-549-1531 fax: +81-44-549-1640 Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOU005017QNSR@eListX.com>; Mon, 24 Jan 2000 06:25:35 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOU005017QLSQ@eListX.com> (original mail from andras@metechnology.com) ; Mon, 24 Jan 2000 06:25:33 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOU005037QKSO@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 24 Jan 2000 06:25:32 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOU005017QISN@eListX.com> for ietf-trade@filter.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 24 Jan 2000 06:25:30 -0500 (EST) Received: from matavnet.hu (matavnet.hu [145.236.224.246]) by eListX.com (PMDF V5.2-31 #39671) with SMTP id <0FOU0055H7QHBD@eListX.com> for ietf-trade@lists.eListX.com; Mon, 24 Jan 2000 06:25:30 -0500 (EST) Received: (qmail 4129 invoked from network); Mon, 24 Jan 2000 11:00:28 +0100 Received: from line-217-134.dial.matav.net (HELO apps) (145.236.217.134) by mail.matav.hu with SMTP; Mon, 24 Jan 2000 11:00:28 +0100 Received: from 10.0.0.11 by apps ([10.0.0.1] running VPOP3) with SMTP for ; Mon, 24 Jan 2000 10:43:43 +0100 Date: Mon, 24 Jan 2000 10:51:59 +0100 From: Andras Varga Subject: IOTP implementation at Brokat -- was RE: IOTP Implementations - Who's on First? In-reply-to: <2B30A9965635D311A29F002035297FFB1B2AE9@se001010.rbc1.royalbank.com> To: "Ietf-Trade (E-mail)" Reply-to: andras@metechnology.com Message-id: <001301bf6650$a9186bb0$0b00000a@andras> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_8h2Lq/7CUUJE9y/5QU4Zdg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Server: VPOP3 V1.3.0b - Registered to: Me Technology This is a multi-part message in MIME format. --Boundary_(ID_8h2Lq/7CUUJE9y/5QU4Zdg) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit RE: IOTP Implementations - Who's on First?At Brokat Infosystems (more exactly, at MeTechnology - a Brokat company, we have implemented an IOTP system as part of a research project. The Merchant and the Payment Handler are based on Twister, Brokat's e-services platform (http://www.brokat.com/us/twister/index.html). The wallet is a Java applet, with a highly customizable Swing-based user interface. It can be started by the shop either by MIME-type or embedded in a HTML page. The wallet does address and payment instrument management; transactions are stored in a transaction log and can be examined or resumed any time later. The wallet is multi-user, user profiles and transactions are stored encrypted on the hard disk. For a start, we implemented Virtual Customer Card payments (a prepaid scheme). The system uses IOTP 1.0 messages, but we also defined Server-to-Server messages so that the Payment Handler can notify the Merchant about the progress of the payment. These messages can be used as an alternative to the explicit (Consumer-initiated) delivery requests. If you are interested in further details, please write. ----------------------------------------------------------------------------------- Andras Varga MeTechnology - A Brokat Company andras@metechnology.com -----Original Message----- From: Smith, Chris [mailto:CHRIS.SMITH@ROYALBANK.COM] Sent: Friday, January 21, 2000 11:10 PM To: 'IOTP Group' Subject: RE: IOTP Implementations - Who's on First? Perhaps I wasn't clear enough. I've had a request to bundle up the responses I received and forward them to the list. I won't do that. I won't presume to know that what someone sends me individually can be repeated on the open list. The intent is that individuals will respond *on the list*. These is one point I will draw from viewing several items. IOTP uses the concept of Roles to define 'who does what' during a transaction. However, nothing limits these roles to being occupied only for a B2C transaction. B2B uses the same roles, so - IOTP could certainly be used as part of B2B commerce solution. Don't think that just because you are *not* doing B2C that we aren't interested in what you might have to say. In addition - if you wish to add your voice to that of the interested audience, that too is welcome. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com > -----Original Message----- > From: Smith, Chris > Sent: January 18, 2000 02:28 PM > To: IOTP Group > Subject: IOTP Implementations - Who's on First? > > At some point, those of working on IOTP will need to > consider testing interoperability. Right now, I know of only > 2 (or maybe 3) groups actively working on IOTP components. > > For those who are doing so in anything remotely resembling > a corporate environment, it helps immensely if we can say, > with some evidence, how many different groups are involved. > > I realize that some people will want to be circumspect about > their plans. However, we can all help each other if we can > speak up to indicate that some implementation work is > planned or underway. > > Longer term, if IOTP is to move towards an IETF standard, > we would have to demonstrate interoperability of the > independent implementations. We might as well get started > on thinking about this, too. > > To get this started - from my point of view: > > Royal Bank (of Canada) has a production IOTP implementation > of Withdrawal and Deposit of Mondex value. We built both an > IOTP server and a Windows client. It is in use, in > production, by customers of the bank. > > ------------------------------------------------------------ > Chris Smith +1.416.348.6090 > Royal Bank chris.smith@royalbank.com --Boundary_(ID_8h2Lq/7CUUJE9y/5QU4Zdg) Content-type: text/html; charset="iso-8859-1" Content-transfer-encoding: quoted-printable RE: IOTP Implementations - Who's on First?
At=20 Brokat Infosystems (more exactly, at MeTechnology - a Brokat=20 company,
we=20 have implemented an IOTP system as part of a research=20 project.
 
The=20 Merchant and the Payment Handler are based on = Twister, Brokat's=20
e-services platform (http://www.brokat.co= m/us/twister/index.html).
 
The=20 wallet is a Java applet, with a highly customizable Swing-based user=20 interface.
It can be started by the shop either by = MIME-type or=20 embedded in a HTML=20 page.
The wallet does address and payment instrument = management;=20 transactions are stored
in a=20 transaction log and can be examined = or resumed any=20 time later. The wallet
is=20 multi-user,  user profiles and transactions are stored = encrypted on=20 the hard disk.
 
For a=20 start, we implemented Virtual Customer Card payments (a = prepaid=20 scheme).
 
The=20 system uses IOTP 1.0 messages, but we also=20 defined Server-to-Server messages
so=20 that the Payment Handler can notify the Merchant about the progress = of the=20 payment.
These messages can be used as = an=20 alternative to the explicit (Consumer-initiated) = delivery
requests.
 
If you=20 are interested in further details, please write.
 
----------------------------------------------------------------= -------------------=20
Andras=20 Varga          M= eTechnology - A=20 Brokat Company
 
-----Original Message-----
From: Smith, Chris=20 [mailto:CHRIS.SMITH@ROYALBANK.COM]
Sent: Friday, January 21, = 2000=20 11:10 PM
To: 'IOTP Group'
Subject: RE: IOTP=20 Implementations - Who's on First?


Perhaps I wasn't clear enough.

I've had a request to bundle up the responses I = received and=20 forward them
to the list. I won't do that. I = won't=20 presume to know that what someone
sends me=20 individually can be repeated on the open list.

The intent is that individuals will respond *on the=20 list*.

These is one point I will draw from viewing several = items.=20 IOTP uses
the concept of Roles to define = 'who does=20 what' during a transaction.
However, nothing = limits=20 these roles to being occupied only for a
B2C = transaction. B2B uses the same roles, so - IOTP could certainly =
be used as part of B2B commerce solution. Don't = think that=20 just because
you are *not* doing B2C that we = aren't=20 interested in what you might
have to = say.

In addition - if you wish to add your voice to that = of=20 the
interested audience, that too is = welcome.=20

------------------------------------------------------------=20
 Chris=20 = Smith           &n= bsp;           &nb= sp;       =20 +1.416.348.6090
 Royal=20 = Bank           &nb= sp;          =20 chris.smith@royalbank.com

> -----Original Message-----
>=20 From: Smith, Chris
> Sent: January 18, = 2000 02:28=20 PM
> To: IOTP Group
>=20 Subject: IOTP Implementations - Who's on First?
>=20
> At some point, those of working on IOTP = will need=20 to
> consider testing interoperability. = Right now,=20 I know of only
> 2 (or maybe 3) groups = actively=20 working on IOTP components.
> =
> For those who are doing so in anything remotely = resembling=20
> a corporate environment, it helps immensely if = we can=20 say,
> with some evidence, how many = different=20 groups are involved.
>
>=20 I realize that some people will want to be circumspect about =
> their plans. However, we can all help each other if we = can=20
> speak up to indicate that some implementation = work=20 is
> planned or underway. =
>
> Longer term, if IOTP is = to move=20 towards an IETF standard,
> we would have = to=20 demonstrate interoperability of the
> = independent=20 implementations. We might as well get started
> on=20 thinking about this, too.
> =
> To get this started - from my point of view: =
>
> Royal Bank (of Canada) = has a=20 production IOTP implementation
> of = Withdrawal and=20 Deposit of Mondex value. We built both an
> IOTP=20 server and a Windows client. It is in use, in
>=20 production, by customers of the bank.
>=20
>=20 ------------------------------------------------------------ =
>  Chris=20 = Smith           &n= bsp;           &nb= sp;       =20 +1.416.348.6090
>  Royal=20 = Bank           &nb= sp;          =20 chris.smith@royalbank.com

--Boundary_(ID_8h2Lq/7CUUJE9y/5QU4Zdg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00101OKMTE@eListX.com>; Fri, 21 Jan 2000 19:41:10 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00101OKLTD@eListX.com> (original mail from david.burdett@commerceone.com); Fri, 21 Jan 2000 19:41:09 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00103OKKTB@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 21 Jan 2000 19:41:08 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00101OKITA@eListX.com> for ietf-trade@filter.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 21 Jan 2000 19:41:06 -0500 (EST) Received: from zeus.commerceone.com (mail.commerceone.com [204.71.220.19]) by eListX.com (PMDF V5.2-31 #39671) with ESMTP id <0FOP00NI4OKH3G@eListX.com> for ietf-trade@lists.eListX.com; Fri, 21 Jan 2000 19:41:06 -0500 (EST) Received: by ZEUS with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jan 2000 16:43:50 -0800 Content-return: allowed Date: Fri, 21 Jan 2000 16:38:08 -0800 From: David Burdett Subject: XML Messaging To: "IETF Trade (E-mail)" Cc: "Donald E. Eastlake (E-mail)" Message-id: <123B7EB05559D311B0D900A0C9EA3D76DB6984@NEPTUNE> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_fbC2fYKDwhnRQJmuQYSxcw)" X-MS-TNEF-Correlator: <123B7EB05559D311B0D900A0C9EA3D76DB6984@NEPTUNE> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_fbC2fYKDwhnRQJmuQYSxcw) Content-type: text/plain; charset="iso-8859-1" I just want to let everyone know that I've submitted the first draft of a "requirements" paper for XML Messaging to the Internet drafts editor. I guess this is likely to be published sometime early next week. The objective of XML Messaging as stated in the paper to provide a "generic approach to the reliable, resilient, secure, tamper resistant, authenticated exchange of XML or other electronic documents over insecure, unreliable transport mechanisms". In thinking about XML Messaging I can see significant benefit in splitting the specification up into several different parts. So far I have identified the following in addition to a "requirements" specification: * Common XML Message Elements * Document Exchange and Transactions * Reliable Messaging * Secure Messaging * Document Choreography Definitions * Common Document Exchanges * Transport Protocol Supplements I think that the more we people we can get working on these the better. Finally this is a **first** draft and realize that there is a **lot** of discussion and thought required to make an XML Messaging standard real. I look forward to working with you all. Regards David Advanced Technology, CommerceOne 1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA Tel: +1 (925) 941 4422 or +1 (650) 623 2888; mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com --Boundary_(ID_fbC2fYKDwhnRQJmuQYSxcw) Content-type: application/ms-tnef Content-transfer-encoding: base64 eJ8+IjMAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0AcBABUAEAAmAAgABQAwAQEggAMADgAAANAHAQAV ABAAKwAyAAUAXwEBCYABACEAAABFOEM4Nzc1NDU1Q0UxRjRFOTk2QUVEQUNBMTY2REIwMgBtBwEE gAEADgAAAFhNTCBNZXNzYWdpbmcArwQBDYAEAAIAAAACAAIAAQOQBgCcCQAALQAAAAsAAgABAAAA QAA5ANAq7vNwZL8BHgBwAAEAAAAOAAAAWE1MIE1lc3NhZ2luZwAAAAIBcQABAAAAFgAAAAG/ZG6F RwuRP9UWiEy0qEG1li4UgNEAAB4AMUABAAAACQAAAERCVVJERVRUAAAAAAMAGkAAAAAAHgAwQAEA AAAJAAAAREJVUkRFVFQAAAAAAwAZQAAAAAACAQkQAQAAAAsFAAAHBQAAyAcAAExaRnX829MUAwAK AHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBjaArAc/BldDAgBxMCgwBQA9XvEXgOUALyEMcy BgAGwwKApn0KgAjIIDsJbzACgCUKgXYIkHdrC4BkNB0MYGMAUAsDC7UgSSBoanVzBUB3AHAFQHSI byBsETAgZXYEkIJ5AiBlIGtubwfgJnQQ8AVASScaICBz8HVibWkCQAmAGuEagIxmaREQBUBkcmEB gIAgb2YgYSAiFdA0cXUcgGUHgAIwcyI6IAqwcASQHGAFsVhNRkwF0AeQc2FnC4Bn+xmSHDJJAjAE kRnhHNMEINcJgBvQBbAuGNFnClAEEQsa8AQAICKBbGlrZdRseRmSYhqAcBugIuD2cxxAHBBzA3AR MAdxGgA3CsAjIRpweBkxCeBrLhcKogqECoBUHEFvYmrfBZAkkBthHTEfHGEEIBkgvxsQHAELgBwj HnQZoXADYLcXMAEAHVJnCfAGcWMdUPZwKjEA0Ggf5hXQIuABoP0Z0CwsUQCQIuAeESzgESDuYwhw LNEBkG0eki0CKMH5LXJhdRwxAjAN4CjjJVDvEOEPICdnBbFvHDEFwCMQzycRA2ADACtAZG8t0B4D zx0gGiEpIS22dW4sZhmQ6xzgAIBwCREgB4AwUgQA3m0eQCXbIGAiUm4XcShx/wbgL2AfDRjgL9AD oBEgG3H8aWcDABxwOPEFQCOAGnD/HHAFQCkxNPAi4AJAH7McQb808AWQObMkkAIgM/BwKSG/GaER IBohB0AcwAaQZgSQVx4RHmEAIHMhwFMZsGb/CsEY4BDwG2EqcS+hHHAcBp8G8AkAA/AfwSkxYWQh ca88YhmhHW87yzol6GQAAI5wIHElYBMiJ0I3DIKNApEqRMFEwWx2bAJgP0UgRNATMUTQF4EeETM2 fwHhRNElYAwwRXEUwAIAaTgtMjQBQCLgSRJzbHNJA0mwbXVGwAFADNA09jgRUAhQbQRgA6AfGBqA vkUZ0B4DJeREv0XBRDKF70wgMEYAcBwQVDTCANA8UvtMr0VYUjQ2H1dQf0VnBmBPLdJSn1OvTjlD aAWwZdZvCcAegGgjMEQ6YQMA/1AvRRxLBU5fWX9FWE+zNQP+UANgGaAI4QYAPKALUExa/wr0Sb9K wTZ1NvQa5BwyBGD/VRElkB5gWEBfsWPiOPIq4P8ZMQWwN0NBshxAESAcIyOA9xvhIbAl6kYLgAdA IyIidflCECoqHHNo4BzFT3IV0PkHQGl6ZjJjNFURaJUJAP9pQh0xIXAE8BkQAJA8cU9y8xrwCGBn aAVAHZUcERmw3wDAIwBPYR8NLuJkCxFqE/M2DBnAb29i8B7RGVBwQa8ZoWVGA/Aa8CAaUHVCAHdA oCXbUhBnCxFgKQqARF8/UCpwYDol+Qr0YxICMakRYGR2AHBjHAFUNWHzGrAJAGd5LOBLAgSQeMC2 TxpwJeQxR9ARUFInQPsIkUIQQRogLOBfgBvQGoBVAdAwLOBXB0BuN8FDBQnRa3mhQSA5NDXEOTYs 4FVTQSZFIxBIOiAreFAoOQ4wKeN9oXhQNDQyE0ERUDEiEX8CNjUwf3A2MjPtfEA4gXB4MjsK4wqB gCHObXgyC3BGwG86cCAqYdwuYghwAQACQEAFoHnkPRphLoQxgBKB4XhBV2UGYn7gbZB0cDovL/53 hoCE4oRrd1sC0WIlFNECAIlwAAMA3j+vbwAAAwABgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPAT AAAeAAKACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUACwADgAggBgAAAAAAwAAA AAAAAEYAAAAABoUAAAAAAAADAASACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsABYAIIAYA AAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAGgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAAD AAeACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABGF AAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAA RgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAA AAAAAB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAA6ACyAGAAAAAADA AAAAAAAARgAAAAAAiAAAAAAAAAsAD4ALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAwDxPwkE AAADAP0/5AQAAAMAJgAAAAAAAwA2AAAAAAADAIAQ/////wIBRwABAAAANgAAAGM9VVM7YT0gO3A9 Q29tbWVyY2UtT25lO2w9TkVQVFVORS0wMDAxMjIwMDM4MDhaLTcyOTQ5AAAAHgA4QAEAAAAJAAAA REJVUkRFVFQAAAAAHgA5QAEAAAAJAAAAREJVUkRFVFQAAAAAQAAHMNAq7vNwZL8BQAAIMPAby79x ZL8BHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAADgAAAFhNTCBNZXNzYWdpbmcAAAAeADUQAQAAADEA AAA8MTIzQjdFQjA1NTU5RDMxMUIwRDkwMEEwQzlFQTNENzZEQjY5ODRATkVQVFVORT4AAAAACwAp AAAAAAALACMAAAAAAAMABhBCOvzFAwAHEGkEAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAA SUpVU1RXQU5UVE9MRVRFVkVSWU9ORUtOT1dUSEFUSVZFU1VCTUlUVEVEVEhFRklSU1REUkFGVE9G QSJSRVFVSVJFTUVOVFMiUEFQRVJGT1JYTUxNRVNTQUdJTkdUT1RIRUlOVAAAAAACAX8AAQAAADEA AAA8MTIzQjdFQjA1NTU5RDMxMUIwRDkwMEEwQzlFQTNENzZEQjY5ODRATkVQVFVORT4AAAAAEk8= --Boundary_(ID_fbC2fYKDwhnRQJmuQYSxcw)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00101HNJLE@eListX.com>; Fri, 21 Jan 2000 17:11:43 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00101HNILD@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 21 Jan 2000 17:11:42 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00103HNHLB@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 21 Jan 2000 17:11:41 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOP00101HNFLA@eListX.com> for ietf-trade@filter.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 21 Jan 2000 17:11:39 -0500 (EST) Received: from smtp2.royalbank.com (smtp2.royalbank.com [198.96.131.29]) by eListX.com (PMDF V5.2-31 #39671) with SMTP id <0FOP00NFCHN93G@eListX.com> for ietf-trade@lists.eListX.com; Fri, 21 Jan 2000 17:11:39 -0500 (EST) Received: from wsecure4.royalbank.com by smtp2.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 21 Jan 2000 22:10:35 +0000 (UT) Received: from 10.224.0.66 by se001018.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 21 Jan 2000 17:10:25 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 21 Jan 2000 17:10:26 -0500 Date: Fri, 21 Jan 2000 17:10:27 -0500 From: "Smith, Chris " Subject: RE: IOTP Implementations - Who's on First? To: 'IOTP Group' Message-id: <2B30A9965635D311A29F002035297FFB1B2AE9@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_H81w9mPdS1wefsLhnYuiLQ)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 149606DB1258564-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_H81w9mPdS1wefsLhnYuiLQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Perhaps I wasn't clear enough. I've had a request to bundle up the responses I received and forward them to the list. I won't do that. I won't presume to know that what someone sends me individually can be repeated on the open list. The intent is that individuals will respond *on the list*. These is one point I will draw from viewing several items. IOTP uses the concept of Roles to define 'who does what' during a transaction. However, nothing limits these roles to being occupied only for a B2C transaction. B2B uses the same roles, so - IOTP could certainly be used as part of B2B commerce solution. Don't think that just because you are *not* doing B2C that we aren't interested in what you might have to say. In addition - if you wish to add your voice to that of the interested audience, that too is welcome. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com > -----Original Message----- > From: Smith, Chris > Sent: January 18, 2000 02:28 PM > To: IOTP Group > Subject: IOTP Implementations - Who's on First? > > At some point, those of working on IOTP will need to > consider testing interoperability. Right now, I know of only > 2 (or maybe 3) groups actively working on IOTP components. > > For those who are doing so in anything remotely resembling > a corporate environment, it helps immensely if we can say, > with some evidence, how many different groups are involved. > > I realize that some people will want to be circumspect about > their plans. However, we can all help each other if we can > speak up to indicate that some implementation work is > planned or underway. > > Longer term, if IOTP is to move towards an IETF standard, > we would have to demonstrate interoperability of the > independent implementations. We might as well get started > on thinking about this, too. > > To get this started - from my point of view: > > Royal Bank (of Canada) has a production IOTP implementation > of Withdrawal and Deposit of Mondex value. We built both an > IOTP server and a Windows client. It is in use, in > production, by customers of the bank. > > ------------------------------------------------------------ > Chris Smith +1.416.348.6090 > Royal Bank chris.smith@royalbank.com --Boundary_(ID_H81w9mPdS1wefsLhnYuiLQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: IOTP Implementations - Who's on First?

Perhaps I wasn't clear enough.

I've had a request to bundle up the responses I = received and forward them
to the list. I won't do that. I won't presume to = know that what someone
sends me individually can be repeated on the open = list.

The intent is that individuals will respond *on the = list*.

These is one point I will draw from viewing several = items. IOTP uses
the concept of Roles to define 'who does what' = during a transaction.
However, nothing limits these roles to being = occupied only for a
B2C transaction. B2B uses the same roles, so - IOTP = could certainly
be used as part of B2B commerce solution. Don't = think that just because
you are *not* doing B2C that we aren't interested in = what you might
have to say.

In addition - if you wish to add your voice to that = of the
interested audience, that too is welcome.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com

> -----Original Message-----
> From: Smith, Chris
> Sent: January 18, 2000 02:28 PM
> To: IOTP Group
> Subject: IOTP Implementations - Who's on = First?
>
> At some point, those of working on IOTP will = need to
> consider testing interoperability. Right now, I = know of only
> 2 (or maybe 3) groups actively working on IOTP = components.
>
> For those who are doing so in anything remotely = resembling
> a corporate environment, it helps immensely if = we can say,
> with some evidence, how many different groups = are involved.
>
> I realize that some people will want to be = circumspect about
> their plans. However, we can all help each = other if we can
> speak up to indicate that some implementation = work is
> planned or underway.
>
> Longer term, if IOTP is to move towards an IETF = standard,
> we would have to demonstrate interoperability = of the
> independent implementations. We might as well = get started
> on thinking about this, too.
>
> To get this started - from my point of = view:
>
> Royal Bank (of Canada) has a production IOTP = implementation
> of Withdrawal and Deposit of Mondex value. We = built both an
> IOTP server and a Windows client. It is in use, = in
> production, by customers of the bank.
>
> = ------------------------------------------------------------
> =A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
> =A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com

--Boundary_(ID_H81w9mPdS1wefsLhnYuiLQ)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOJ00A01Y53FE@eListX.com>; Tue, 18 Jan 2000 17:22:15 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOJ00A01Y52FD@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Tue, 18 Jan 2000 17:22:14 -0500 (EST) Received: from FILTER-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOJ00A03Y51FB@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 18 Jan 2000 17:22:13 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-31 #39671) id <0FOJ00901Q4GAD@eListX.com> for ietf-trade@filter.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 18 Jan 2000 14:29:04 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-31 #39671) with SMTP id <0FOJ005DFQ4FHX@eListX.com> for ietf-trade@lists.eListX.com; Tue, 18 Jan 2000 14:29:04 -0500 (EST) Received: from wsecure2.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Tue, 18 Jan 2000 19:27:47 +0000 (UT) Received: from 10.224.0.66 by se001020.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 18 Jan 2000 14:28:47 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Tue, 18 Jan 2000 14:27:57 -0500 Date: Tue, 18 Jan 2000 14:27:57 -0500 From: "Smith, Chris " Subject: IOTP Implementations - Who's on First? To: IOTP Group Message-id: <2B30A9965635D311A29F002035297FFB1B2AE1@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_6/Uws/N5PhGQ2SOZ2hT3Eg)" X-Server-Uuid: d237928a-6c98-11d3-985c-00a0c9ea509d X-WSS-ID: 149A6164984236-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_6/Uws/N5PhGQ2SOZ2hT3Eg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit At some point, those of working on IOTP will need to consider testing interoperability. Right now, I know of only 2 (or maybe 3) groups actively working on IOTP components. For those who are doing so in anything remotely resembling a corporate environment, it helps immensely if we can say, with some evidence, how many different groups are involved. I realize that some people will want to be circumspect about their plans. However, we can all help each other if we can speak up to indicate that some implementation work is planned or underway. Longer term, if IOTP is to move towards an IETF standard, we would have to demonstrate interoperability of the independent implementations. We might as well get started on thinking about this, too. To get this started - from my point of view: Royal Bank (of Canada) has a production IOTP implementation of Withdrawal and Deposit of Mondex value. We built both an IOTP server and a Windows client. It is in use, in production, by customers of the bank. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com --Boundary_(ID_6/Uws/N5PhGQ2SOZ2hT3Eg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable IOTP Implementations - Who's on First?

At some point, those of working on IOTP will need = to
consider testing interoperability. Right now, I know = of only
2 (or maybe 3) groups actively working on IOTP = components.

For those who are doing so in anything remotely = resembling
a corporate environment, it helps immensely if we = can say,
with some evidence, how many different groups are = involved.

I realize that some people will want to be = circumspect about
their plans. However, we can all help each other if = we can
speak up to indicate that some implementation work = is
planned or underway.

Longer term, if IOTP is to move towards an IETF = standard,
we would have to demonstrate interoperability of = the
independent implementations. We might as well get = started
on thinking about this, too.

To get this started - from my point of view:

Royal Bank (of Canada) has a production IOTP = implementation
of Withdrawal and Deposit of Mondex value. We built = both an
IOTP server and a Windows client. It is in use, = in
production, by customers of the bank.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com

--Boundary_(ID_6/Uws/N5PhGQ2SOZ2hT3Eg)-- Received: from one.eListX.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19210 for ; Thu, 13 Jan 2000 09:41:18 -0500 (EST) Received: from one.elistx.com by one.eListX.com id aa03805; 13 Jan 100 09:23 EST Received: from [209.94.126.195] by one.eListX.com id aa03793; 13 Jan 100 09:22 EST Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id JAA10447; Thu, 13 Jan 2000 09:24:31 -0500 (EST) Message-Id: <200001131424.JAA10447@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: Andre Chan cc: IOTP Group Subject: Re: Question about Error Code.. In-reply-to: Your message of "Thu, 13 Jan 2000 10:54:09 +0800." Date: Thu, 13 Jan 2000 09:24:31 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: ietf-trade-owner@lists.eListX.com Precedence: bulk X-elistx: ietf-trade Source-Info: From (or Sender) name not authenticated. Can you describe what the error condition is that you need a new code for? Thanks Donald From: Andre Chan To: IOTP Group Date: Thu, 13 Jan 2000 10:54:09 +0800 Message-ID: >Dear Sir, > I would like to know whether we should create new ErrorCode or we should >use unknown in the ErrorCode and provide description in ErrorDec. > >Thanks >Andre ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com Received: from one.eListX.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18564 for ; Thu, 13 Jan 2000 08:55:07 -0500 (EST) Received: from one.elistx.com by one.eListX.com id aa02465; 13 Jan 100 08:36 EST Received: from mailgw.ust.hk by one.eListX.com id aa00627; 12 Jan 100 21:49 EST Received: from imaila.ust.hk (imaila.ust.hk [143.89.14.173]) by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id KAA07531 for ; Thu, 13 Jan 2000 10:45:20 +0800 (HKT) Received: from imz133 (imz133.ust.hk [143.89.56.96]) by imaila.ust.hk (8.9.3/8.9.3) with SMTP id KAA06717 for ; Thu, 13 Jan 2000 10:49:19 +0800 (HKT) From: Andre Chan To: IOTP Group Subject: Question about Error Code.. Date: Thu, 13 Jan 2000 10:54:09 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Disposition-Notification-To: "Andre Chan" Sender: ietf-trade-owner@lists.eListX.com Precedence: bulk X-elistx: ietf-trade Source-Info: From (or Sender) name not authenticated. Dear Sir, I would like to know whether we should create new ErrorCode or we should use unknown in the ErrorCode and provide description in ErrorDec. Thanks Andre ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com Received: from one.eListX.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13316 for ; Thu, 6 Jan 2000 09:44:13 -0500 (EST) Received: from one.elistx.com by one.eListX.com id aa02064; 6 Jan 100 09:27 EST Received: from [209.94.126.195] by one.eListX.com id aa02052; 6 Jan 100 09:24 EST Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id JAA02054 for ietf-trade@elistx.com; Thu, 6 Jan 2000 09:26:05 -0500 (EST) Message-Id: <200001061426.JAA02054@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ietf-trade@elistx.com Subject: Chair Move Date: Thu, 06 Jan 2000 09:26:05 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: ietf-trade-owner@lists.eListX.com Precedence: bulk X-elistx: ietf-trade Source-Info: From (or Sender) name not authenticated. Working Group members should be aware that I am no longer with IBM and my IBM email address does not work. I expect to be starting next week with Motorola in Mansfield, Massahcusetts, and relocating to the Boston area shortly. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668 Carmel, NY 10512 USA ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com