Subject: RE: Draft new TRADE WG Charter, two week comment period
From: David Burdett <[email-masked]>
To: "'Donald E. Eastlake 3rd'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Thu, 24 Aug 2000 12:03:22 -0700

Donald

I agree that IOTP should not include a messaging layer as was planned some
time ago. However, to achieve interoperability, IOTP will need to specify
what (which?) messaging layer to use and how to use it.

Regards

David

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 5:40 AM
To: David Burdett
Cc: [email-masked]'
Subject: Re: Draft new TRADE WG Charter, two week comment period

Hi David,

The working group has decided not to do an XML messaging layer itself.

Among the deliverables in the proposed new charter, the one most likely
to refer to this would be the IOTP v2 requirements which should say
something about requirements for the Messaging Layer.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Content-return:  allowed
Date:  Thu, 17 Aug 2000 10:20:44 -0700
To:  Eastlake Donald-LDE008 <[email-masked]>,
            "[email-masked]'" <[email-masked]>
Message-id:
<[email-masked]>

>Donald
>
>Apologies for not being able to make the last IETF meeting. However, I
think
>that work on version 2.0 of IOTP should consider use of ebXML Transport
>Routing and Packaging as meeting your first requirement for "Separation of
a
>content independent Messaging Layer".
>
>ebXML stands for electronic business XML and is a joint effort between
>UN/CEFACT who are owners of the EDIFACT standard and OASIS which is a
>non-profit organization with significant SGML & XML expertise. It includes
>the development of a content independent messaging layer.
>
>David
>
>-----Original Message-----
>From: Eastlake Donald-LDE008 [mailto:[email-masked]]
>Sent: Thursday, August 10, 2000 6:51 PM
>To: [email-masked]'
>Cc: Eastlake Donald-LDE008
>Subject: Draft new TRADE WG Charter, two week comment period
>
>
>Hi,
>
>Here is the draft charter that was presented in Pittsburgh with some minor
>edits.  I would like to send this in to our Area Director soon.  Please try
>to get any comments or suggestions to me or posted to the list within two
>weeks.
>
>Thanks,
>Donald
>
>
>Chair: Donald Eastlake 3rd <[email-masked]>
>Applications Area Advisor: Patrik Faltstrom
>
>Mailing Lists:
>	General Discussion:[email-masked] 
>	To Subscribe: [email-masked]
>	In Body: (un)subscribe
>	Archive: http://www.eListX.com/archives/ietf-trade 
>
>The Internet Open Trading Protocol is an interoperable framework
>for Internet commerce. It is optimized for the case where the
>buyer and the merchant do not have a prior acquaintance and is
>payment system independent. It can encapsulate and support payment
>systems such as SET, Mondex, secure channel card payment,
>GeldKarte, etc. IOTP is able to handle cases where such merchant
>roles as the shopping site, the payment handler, the deliverer of
>goods or services, and the provider of customer support are
>performed by different Internet sites.
>
>The working group will document interoperability experience with
>IOTP version 1 (which has been published as an Informational RFC)
>and develop the requirements for IOTP version 2. Selection of
>items for inclusion in version requirements 2 is to be from the
>following: 
> - Separation of a content independent Messaging Layer 
> - Dynamic Definition of Trading Sequences 
> - Offer Request Block 
> - Improved Problem Resolution (extend to cover presentation of
> 	signed receipt to customer support party, etc.)
> - Server to Server messages
> - Standardized XML Digital Signatures based on output from
> 	the XMLDSIG working group
> 
>The following is out of scope for IOTP version 2:
> - legal or regulatory issues surrounding the implementation of
> 	the protocol or information systems using it.
> - specification of an XML Messaging Layer
>
>The working group will specify requirements for Digital-Rights
>Trading.
>
>The working group will specify requirements for and then a syntax
>and processing model of ECML (Electronic Commerce Modeling
>Language) V2.
>
>Milestones
>
>00 Sep  Internet Draft publication
>	Secure Channel Credit/Debit
>
>00 Sep  Working Group Last Call
>	SET Supplement
>	Architecture and Payment API
>	
>00 Oct  Submit to IESG
>	SET Supplement (Informational)
>	Architecture and Payment API (Informational)
>
>00 Nov  Internet Draft publication
>	IOTP V2.0 Requirements
>	ECML V2.0 Requirements
>
>00 Nov  Submit to IESG
>	Secure Channel Credit/Debit (Proposed Standard?)
>	"Digital Rights" Trading Requirements (Informational)
>
>00 Dec  Internet Draft publication
>	IOTP V2.0 Specification
>	ECML V2.0 Specification
>
>00 Dec  Submit to IESG
>	ECML V2.0 Requirements (Informational)
>
>01 Jan  Submit to IESG
>	IOTP V2.0 Requirements (Informational)
>
>01 Feb  Submit to IESG
>	ECML V2.0 Specification (Proposed Standard)
>
>01 Mar  Submit to IESG
>	IOTP V2.0 Specification  (Proposed Standard)

Date: Thu, 24 Aug 2000 18:02:15 +0900 (JST)
From: Yoshiaki KAWATSURA <[email-masked]>
Subject: Re: Draft new TRADE WG Charter, two week comment period
To: [email-masked]
Cc: [email-masked]
Lines: 36

>>>>> Tue, 15 Aug 2000 20:34:01 +0900,
	Ko Fujimura <[email-masked]> said:

> Eastlake Donald-LDE008 wrote:
> ...
> > The working group will document interoperability experience with
> > IOTP version 1 (which has been published as an Informational RFC)
> > and develop the requirements for IOTP version 2. Selection of
> > items for inclusion in version requirements 2 is to be from the
> > following:
> >  - Separation of a content independent Messaging Layer
> >  - Dynamic Definition of Trading Sequences
> >  - Offer Request Block
> >  - Improved Problem Resolution (extend to cover presentation of
> >         signed receipt to customer support party, etc.)
> >  - Server to Server messages
> >  - Standardized XML Digital Signatures based on output from
> >         the XMLDSIG working group
> 
> Coordination between IOTP and ECML may be an item should be considered.
> I think that IOTP version 2 should specify the position of ECML version 2.
> How do you think? 

I agree with you. I think we can simplify the current specification by
collaborating with other related protocols such as ECML.

Additionally we should separate the specification document of IOTP
after it has reflected the implimentation result because the current
specification is too big and hard to progress IOTP.

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business Solution Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

Date: Wed, 23 Aug 2000 17:29:11 -0700
From: "Lewis, Tony" <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: [email-masked]

Visa would like to see the inclusion of the following additional items in
version 2 requirements:
- Customer Payment Handler
- on-going payments
- the ability to add both fields and attributes to trading blocks

An example of the use of a "Customer Payment Handler" is subtracting value
from a purse on a chip card (stored value card).

An example of on-going payments is the playing of a game where there is a
charge for each five minutes of game time.

Please let me know if you need additional information.

Tony Lewis

-----Original Message-----
From: Eastlake Donald-LDE008 [mailto:[email-masked]]
Sent: Thursday, August 10, 2000 6:51 PM
To: [email-masked]'
Cc: Eastlake Donald-LDE008
Subject: Draft new TRADE WG Charter, two week comment period

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

Date: Tue, 22 Aug 2000 08:39:42 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Draft new TRADE WG Charter, two week comment period
To: David Burdett <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Hi David,

The working group has decided not to do an XML messaging layer itself.

Among the deliverables in the proposed new charter, the one most likely
to refer to this would be the IOTP v2 requirements which should say
something about requirements for the Messaging Layer.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Content-return:  allowed
Date:  Thu, 17 Aug 2000 10:20:44 -0700
To:  Eastlake Donald-LDE008 <[email-masked]>,
            "[email-masked]'" <[email-masked]>
Message-id:  <[email-masked]>

>Donald
>
>Apologies for not being able to make the last IETF meeting. However, I think
>that work on version 2.0 of IOTP should consider use of ebXML Transport
>Routing and Packaging as meeting your first requirement for "Separation of a
>content independent Messaging Layer".
>
>ebXML stands for electronic business XML and is a joint effort between
>UN/CEFACT who are owners of the EDIFACT standard and OASIS which is a
>non-profit organization with significant SGML & XML expertise. It includes
>the development of a content independent messaging layer.
>
>David
>
>-----Original Message-----
>From: Eastlake Donald-LDE008 [mailto:[email-masked]]
>Sent: Thursday, August 10, 2000 6:51 PM
>To: [email-masked]'
>Cc: Eastlake Donald-LDE008
>Subject: Draft new TRADE WG Charter, two week comment period
>
>
>Hi,
>
>Here is the draft charter that was presented in Pittsburgh with some minor
>edits.  I would like to send this in to our Area Director soon.  Please try
>to get any comments or suggestions to me or posted to the list within two
>weeks.
>
>Thanks,
>Donald
>
>
>Chair: Donald Eastlake 3rd <[email-masked]>
>Applications Area Advisor: Patrik Faltstrom
>
>Mailing Lists:
>	General Discussion:[email-masked] 
>	To Subscribe: [email-masked]
>	In Body: (un)subscribe
>	Archive: http://www.eListX.com/archives/ietf-trade 
>
>The Internet Open Trading Protocol is an interoperable framework
>for Internet commerce. It is optimized for the case where the
>buyer and the merchant do not have a prior acquaintance and is
>payment system independent. It can encapsulate and support payment
>systems such as SET, Mondex, secure channel card payment,
>GeldKarte, etc. IOTP is able to handle cases where such merchant
>roles as the shopping site, the payment handler, the deliverer of
>goods or services, and the provider of customer support are
>performed by different Internet sites.
>
>The working group will document interoperability experience with
>IOTP version 1 (which has been published as an Informational RFC)
>and develop the requirements for IOTP version 2. Selection of
>items for inclusion in version requirements 2 is to be from the
>following: 
> - Separation of a content independent Messaging Layer 
> - Dynamic Definition of Trading Sequences 
> - Offer Request Block 
> - Improved Problem Resolution (extend to cover presentation of
> 	signed receipt to customer support party, etc.)
> - Server to Server messages
> - Standardized XML Digital Signatures based on output from
> 	the XMLDSIG working group
> 
>The following is out of scope for IOTP version 2:
> - legal or regulatory issues surrounding the implementation of
> 	the protocol or information systems using it.
> - specification of an XML Messaging Layer
>
>The working group will specify requirements for Digital-Rights
>Trading.
>
>The working group will specify requirements for and then a syntax
>and processing model of ECML (Electronic Commerce Modeling
>Language) V2.
>
>Milestones
>
>00 Sep  Internet Draft publication
>	Secure Channel Credit/Debit
>
>00 Sep  Working Group Last Call
>	SET Supplement
>	Architecture and Payment API
>	
>00 Oct  Submit to IESG
>	SET Supplement (Informational)
>	Architecture and Payment API (Informational)
>
>00 Nov  Internet Draft publication
>	IOTP V2.0 Requirements
>	ECML V2.0 Requirements
>
>00 Nov  Submit to IESG
>	Secure Channel Credit/Debit (Proposed Standard?)
>	"Digital Rights" Trading Requirements (Informational)
>
>00 Dec  Internet Draft publication
>	IOTP V2.0 Specification
>	ECML V2.0 Specification
>
>00 Dec  Submit to IESG
>	ECML V2.0 Requirements (Informational)
>
>01 Jan  Submit to IESG
>	IOTP V2.0 Requirements (Informational)
>
>01 Feb  Submit to IESG
>	ECML V2.0 Specification (Proposed Standard)
>
>01 Mar  Submit to IESG
>	IOTP V2.0 Specification  (Proposed Standard)

Date: Sun, 20 Aug 2000 12:15:11 -0500 (CDT)
From: [email-masked]
Subject: ISADS 2001 deadline extended
To: [email-masked]

Dear Colleagues:

The submission deadline for the International Symposium on Autonomous
Decentralized Systems (ISADS) 2001 has been extended
to August 31st, 2000, to accommodate some late paper requests.

For information on how to submit papers,
please go to: http://isads.utdallas.edu

Please feel free to pass this information to your
colleagues.

Thank you very much

Jorge Cobb
The University of Texas at Dallas
publicity chair, ISADS 2001

Content-return: allowed
Date: Thu, 17 Aug 2000 10:20:44 -0700
From: David Burdett <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: Eastlake Donald-LDE008 <[email-masked]>, "[email-masked]'" <[email-masked]>

Donald

Apologies for not being able to make the last IETF meeting. However, I think
that work on version 2.0 of IOTP should consider use of ebXML Transport
Routing and Packaging as meeting your first requirement for "Separation of a
content independent Messaging Layer".

ebXML stands for electronic business XML and is a joint effort between
UN/CEFACT who are owners of the EDIFACT standard and OASIS which is a
non-profit organization with significant SGML & XML expertise. It includes
the development of a content independent messaging layer.

David

-----Original Message-----
From: Eastlake Donald-LDE008 [mailto:[email-masked]]
Sent: Thursday, August 10, 2000 6:51 PM
To: [email-masked]'
Cc: Eastlake Donald-LDE008
Subject: Draft new TRADE WG Charter, two week comment period

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

Date: Wed, 16 Aug 2000 17:48:29 +0200
From: Andras Varga <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: [email-masked]
Reply-to: [email-masked]
Importance: Normal

Donald Eastlake wrote:
[...]
> The working group will document interoperability experience with
> IOTP version 1 (which has been published as an Informational RFC)
> and develop the requirements for IOTP version 2. Selection of
> items for inclusion in version requirements 2 is to be from the
> following:
>  - Separation of a content independent Messaging Layer
>  - Dynamic Definition of Trading Sequences
>  - Offer Request Block
>  - Improved Problem Resolution (extend to cover presentation of
>  	signed receipt to customer support party, etc.)
>  - Server to Server messages
>  - Standardized XML Digital Signatures based on output from
>  	the XMLDSIG working group

I'd like to suggest two more items for inclusion:

1) issues concerning server-side IOTP wallets (or IOTP-enabled WalletServers).

When using server-side wallets which reside in a WalletServer,
a typical scenario is this:
 1. consumer browses in the Merchant's shop and decides to check out
 2. consumer clicks on the "Pay" link in the shop. The URL points
    to the WalletServer and contains additional parameters like
    e.g. merchant address and order number
 3. consumer logs into the WalletServer
 4. the WalletServer retrieves the Offer from the Merchant;
    data for this (e.g. OfferRequest URL) come from parameters
    from the URL used to invoke the WalletServer
 5. now payment & delivery goes on like the Consumer had
    a locally installed IOTP wallet

An item which would be worth standardizing is the URL used to
invoke the WalletServer. (Using such an URL to get to the
WalletServer has certain advantages over using e.g. a mime-type
sent down from the shop.)

This URL should include parameters which -at minimum- tell
the WalletServer where to send the OfferRequest.

2) mixing IOTP with other payment protocols.

Some existing payment protocols like SET or Geldkarte
are pretty difficult to tunnel through IOTP (bridges require
significant implementation effort). At the same time
it would be nice to be able to use IOTP e.g. for retrieving
offer or requesting delivery, which is not (properly) covered
by other protocols. Such a feature would probably increase
the usefulness and thus the acceptance of the IOTP standard.

The IOTP specification should explicitly allow for payment
protocols that are not tunnelled through IOTP. There should
be a way to specify protocols in the IOTP OfferResponse
that are to be used standalone with Merchant's Payment Handler
(ie. not tunnelled through IOTP).

Other modifications might also be necessary on the IOTP protocol
to accomodate such a feature, for example signed PayReceipt
is not possible if the payment was not done via IOTP.

Best regards,
  Andras Varga

----------------------------------------------------------
Andras Varga                    |  Brokat Ag.
E-mail: [email-masked] |  Commerce Division
Phone: +36-1 437-0413           |  Research & Development
Fax:   +36-1 387-3798           |  Kunigunda útja 58.
http://www.brokat.com           |  1037 Budapest, Hungary

Date: Tue, 15 Aug 2000 20:34:01 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Draft new TRADE WG Charter, two week comment period
To: [email-masked]

Eastlake Donald-LDE008 wrote:
...
> The working group will document interoperability experience with
> IOTP version 1 (which has been published as an Informational RFC)
> and develop the requirements for IOTP version 2. Selection of
> items for inclusion in version requirements 2 is to be from the
> following:
>  - Separation of a content independent Messaging Layer
>  - Dynamic Definition of Trading Sequences
>  - Offer Request Block
>  - Improved Problem Resolution (extend to cover presentation of
>         signed receipt to customer support party, etc.)
>  - Server to Server messages
>  - Standardized XML Digital Signatures based on output from
>         the XMLDSIG working group

Coordination between IOTP and ECML may be an item should be considered.
I think that IOTP version 2 should specify the position of ECML version 2.
How do you think? 

> 
> The following is out of scope for IOTP version 2:
>  - legal or regulatory issues surrounding the implementation of
>         the protocol or information systems using it.
>  - specification of an XML Messaging Layer
> 
> The working group will specify requirements for Digital-Rights
> Trading.

I'm sorry for not resolving the issue of the document title.
How about "Requirements for Generic Rights Trading"?

Regards,

Ko Fujimura

Content-return: allowed
Date: Thu, 10 Aug 2000 21:51:27 -0400
From: Eastlake Donald-LDE008 <[email-masked]>
Subject: Draft new TRADE WG Charter, two week comment period
To: "[email-masked]'" <[email-masked]>
Cc: Eastlake Donald-LDE008 <[email-masked]>

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

Content-return: allowed
Date: Wed, 09 Aug 2000 14:27:39 -0400
From: Eastlake Donald-LDE008 <[email-masked]>
Subject: Draft TRADE WG minutes from Pittsburgh IETF
To: "[email-masked]'" <[email-masked]>

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_wrul20i3iuoPtpi/swu/sA)
Content-type: text/plain; charset="iso-8859-1"

Corrections/Comments welcome...I'll be putting up the slides for anonymous
FTP and send out a separate notice when that is done.

 <<TradeMinutes.txt>> 
Donald

--Boundary_(ID_wrul20i3iuoPtpi/swu/sA)
Content-type: text/plain; name="TradeMinutes.txt"
Content-disposition: attachment; filename="TradeMinutes.txt"

TRADE WG Meeting, 1 August 2000, 13:00 hours

Minutes (Taken by Ed Simon of Entrust, edited by Donald Eastlake):

Donald Eastlake ran the meeting. (see slides)

There were no changes in the suggested Agenda.

There was an extensive review of Working Group document status
	including approved documents, un-approved Internet Drafts,
	and planned documents not yet out as Internet Drafts.
	
Status of ECML and the ECML Alliance (www.ecml.org) was
	discussed.  They are advocating an XML format for ECML
	v2.  It is still the plan that they will finish up ECML
	1.1 as an ECML Alliance document and hand ECML v2 to the
	working group.
	
Question: What about all the other XML business message format
	messages?
Answer: Rick Drummond, chair of EDIINT and of the sub-group
	of ebXML working in the XML transport area has had
	considerable communications with Donald Eastlake.  The
	WG consensus appears to be let some more transport
	oriented and less application oriented working group handle
	the XML messaging level.
Q Steve Hole: Should there be a new WG to handle XML
	Messaging and business headers?
A Donald Eastlake: Let's discuss this more after Ko Fujimura's
	presentation since it is relevant.
	
There was no new implementation news.
	Hitachi and Royal Bank of Canada, who both implemented
	IOTP v0.9, are definitely implementing IOTP 1.0.  About
	a half dozen other companies have also said they are
	implmeneting IOTP v1.

Ko Fujimura of NTT, speaking for himself as an individual,
	gave his presentation on ECML v2 and IOTP.  See his slides.

Donald Eastlake presented the suggested updated and modified
	charter. (see slides)  People interested were urged to
	subscribe to the WG mailing list.

[Q=Question, A=Answer, C=Comment]
Q Steve Hole: Where has XML messaging gone?
A Donald Eastlake: David Burdett, who wrote the current XML
	Messaging Requirements draft in the TRADE WG, and Rick
	Drummond of EDIINT and ebXML noticed the overlap in
	effort.  The WG consensus has been that XML Messaging
	need NOT be done in the TRADE WG.
C Dick Brooks: The World Wide Web Consortium (W3C) is looking
	into XML transport protocls.
Q Steve Hole: Isn't the W3C more appropriate for XML
	protocols?
Discusion continued on whether the W3C or IETF or other forums
	were best for this work.
Q Steve Hole: Should there be an EDI follow on working group?
C Dick Brooks: The current EDIINT is still in existence just
	because it was waiting on S/MIME to finalize a document it
	depends on.
C Donald Eastlake: Messaging is interesting but not
	specifically to just the TRADE working group.  We should
	presume that messaging will be done by someone else.  The
	charter needs to be changed.  I will send it out to the
	list for comments and then ask the IESG to adopt it.

Future Meetings
	There was no objection to the next meeting being in December
	2000 at the San Diego IETF meeting.

--Boundary_(ID_wrul20i3iuoPtpi/swu/sA)--

Date: Mon, 07 Aug 2000 11:10:37 +0900
From: Ko Fujimura <[email-masked]>
Subject: XML-Wallet
To: [email-masked]
Cc: [email-masked]

Hi all,

My slides presented at the trade WG meeting in Pittsburgh, are uploaded 
to the following URL:

http://info.isl.ntt.co.jp/flexticket/ietf/ietf48-trade-fujimura.ppt

The summary of my talk is as follows:

1. An XML-based wallet, which can handle diverse types of EC entities, 
   e.g., orders, bill, payment receipt, delivery notes, as well as 
   payment information, is required.
2. The XML-based wallet should provide a simple store/retrieve protocol 
   to transmit the EC entities (just like the HTTP cookie protocol).
3. The XML-based wallet should allow any vendors to provide plug-ins 
   that handle any sophisticated protocols. An example of such plug-ins 
   includes an IOTP wallet, digital-rights wallet, or other 
   payment-scheme-specific wallets.

I think such wallet architecture will bridge IOTP, ECML, and 
digital-right-trading model seamlessly.  I hope the trade WG will develop 
a new standard, which bring us a new type of killer client application, 
i.e., XML-Wallet.

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Thu, 03 Aug 2000 01:20:54 -0500 (CDT)
From: [email-masked]
Subject: Deadline approaching, Autonomous Decentralized Systems Symposium CFP
To: [email-masked]

* please forgive us if you receive multiple copies of this message
* feel free to distribute to your colleagues.

http://isads.utdallas.edu

                         ISADS 2001 CALL FOR PAPERS

                  The Fifth International Symposium on
                    Autonomous Decentralized Systems

		    with an emphasis on electronic commerce

                  Monday March 26 - Wednesday March 28, 2001
                         Dallas, Texas, USA

Paper deadline: August 15, 2000

Sponsored by:

                         IEEE Computer Society 
              Information Processing Society of Japan 
        The Society of Instrument and Control Engineers of Japan 
    The Institute of Electronics, Infor. and Communication Engineers, Japan 

In Cooperation with:

             International Federation for Information Processing 
             International Federation of Automatic Control 
                             OMG 
                            TINA-C 
          Manufacturing Science and Technology Center, Japan 

Scope: 

Driven by the continuous growth in the power, intelligence and openness of
computer, communication and control technologies, possibilities and
opportunities for realizing highly efficient and dependable business and
control systems have been steadily increasing.  Dynamically changing
social and economic situations demand next-generation systems based on
emerging technologies and applications. Such systems are expected to have
the characteristics of living systems composed of largely autonomous and
decentralized components. Such systems are called Autonomous Decentralized
Systems (ADS).

After the successful first, second, third, and fourth International
Symposium on Autonomous Decentralized Systems (ISADS) held in 1993 in
Japan, in 1995 in the USA , in 1997 in Germany, and in 1999 in Japan, the
fifth ISADS will be held in Dallas, Texas, USA during March 26-28, 2001.
While ISADS 2001 will primarily focus on advancements and innovation in
ADS concept, technologies, and applications related to the increasingly
important topic of *Electronic Commerce*, other themes such as
telecommunications and heterogeneous system and application integration
will also be included.

The ISADS 2001 committee invites papers and panel proposals on the topics
of the symposium that will foster interactions among researchers and
practitioners in computer, communication, management, control as applied
to electronic commerce and other related fields from academia, industry,
and government.

The scope of discussions on ADS shall include, but not be limited 
to: 

* Computer and communication architectures / intelligent network /Internet; 
* Heterogeneous distributed information / control systems; 
* Mobile agent /computer-supported cooperative works;
* Distributed software development and maintenance;
* Assurance, fault tolerance and on-line expansion; 
* Object management architecture /design pattern / application frameworks; 
* Emergent control and robotic systems; 
* Novel applications: electronic commerce, telecommunications, 
  information service systems, manufacturing systems, 
  real-time event management, office automation, traffic and 
  transportation control, logistics systems. 

Plant tour is scheduled on March 29, 2001. Delegates are encour-
aged to participate. 

Information for Authors 

Papers should describe original work (not submitted or published
elsewhere) and be 20 double-spaced pages (5,000 words) or less in length.
Papers should include: title, authors, affiliations, 150-word abstract and
list of keywords.

Identify the author responsible for correspondence, including the author's
name, position, mailing address, telephone and fax numbers, and email
address. One of the authors of each accepted paper must present the paper
at ISADS 2001.

Information for Panel Organizers 

Panel proposals should include: title, organizer's affiliations, position,
mailing address, telephone and fax numbers, email address, and 150-word
statement on the scope, proposed chair and panelists.

Submission Address 

Authors and panel organizers are requested to submit their manuscripts
electrically in the Microsoft WORD document file format, the PDF format,
or the Postscript format, and also email the abstract and the full
addresses of the author(s) to the following address:

[email-masked]

Note The program committee of ISADS2001 highly encourage electronic
submissions. Otherwise, papers should be sent to the program chair:

Dr. Bhavani Thuraisingham
Mail Stop A270
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
Phone: 781-271-8873
Fax: 781-271-8752
Email: [email-masked]

General Information 

For general information, see our World-Wide Web Page at: 

http://isads.utdallas.edu

The proceedings of the symposium will be published by IEEE Computer
Society Press.

Important Deadlines

August 15, 2000: All papers and panel proposals are due
November 15, 2000: Authors and panel organizers notified of acceptance. 
December 15, 2000: Camera-ready copies of accepted papers and 
panelists' position papers 

General Chair
William Osborne, U. of Texas, Dallas, USA

Program Committee

Chair: Bhavani Thuraisingham, The MITRE Corp., USA 

Co-Chair: Makoto Imase, NTT Labs, Japan
Co-Chair: Linda Strick, GMD Fokus, Berlin, Germany 
Co-Chair: Jeffrey Tsai, U. of Illinois, Chicago, USA 

Members
G. Agha, U. of IL, Urbana, USA
R. Arai, U. of Tokyo, Japan
D. Bae, KAIST, Korea  
F. Bastani, U. of TX, Dallas, USA
E. Bertino,  U. of Milano, Italy
M. Ceruti, SPAWAR, USA
I. Chen, Virginia, Tech, USA
Y. Chen, U. of the Witwatersrand, South Africa
R. Chow, U. of FL, USA
J. Chung, IBM T.J. Watson Research Center, USA
P. Chuang, Tamkang U., Taiwan
P. Ciancarini, U. of Bologna.
B. Cukic, West Virginia U., USA
K. Eckert, GMD FOKUS Germany
S. Eisenbach, Imperial College, UK
D. Ferrari, U. of Catoloca, Italy
M. Fisher, Manchester Metropolitan U., UK
M. Fujita, Sony, Japan
A. Fukuda, Nara Inst. of Science and Technology, Japan
V. Garg, Univ. of TX, Austin, USA
S. Ghosh, Arizona State U., USA       
A. Ghafoor,  Purdue U., USA
A. Ghose, U. of Wollongong, Australia
M. Gien, Sun, France
V. Gobel, U. of Oslo, Norway
T. Higashino Osaka U., Japan   
D. Hislop, ARO, USA
I.  Iida, Fujitsu, Japan
Y. Ishiguro, NEC, Japan
K. Ito, TITECH, Japan
Y. Kakuda, Hiroshima City U., Japan
K. Kim, U.C. Irvine, USA 
H. Kopetz, TU Wien, Austria
J. Kramer, Imperial College, UK
L. LeLann, INRIA, France
C. Liu, Chung Yuan Christian U., Taiwan
M. Lyu, The Chinese U. of Hong Kong, Hong Kong
Y. Masunaga, Ochanomizu U., Japan 
W. Meng , State U. of New York at Binghamton, USA
R. Montanari, U. of Bologna, Italy
W. Ng, Nanyang Technological U., Singapore
A. Prakash, U. of Michigan, USA
J. Putman, MITRE, USA
Q. Qingquan, Southwest Jiatong U., China
N. Raynal, INRIA, France
W. Ruh, Concept-V, USA
D. Serpanos, Inst. of Comuter Science, Technology-Hellas, Greece
S. Shekhar, U. of MN, Mpls, USA
L. Simoncini, CNUCE-CNR, Italy
R. Stroud, U. of  New Castle, UK
V. Subrahmanian, U. of MD, College Park, USA
K. Tsuchiya, Kyoto Uv, Japan
B. Wah, U. of  IL, Urbana, USA
Y. Wakahara, U. of Tokyo, Japan
F.  Wang, National Chao Tung U., Taiwan
M. Wooldridge, U. of Liverpool, UK
H. Yokota, TITECH, Japan  
M. Yano, Tohoku U., Japan
S. Yongqiang, Shanghai Jiao Tong U, China
P. Yu, IBM T.J. Watson Research Center
S. Zubairy, Quaid-e-Azam U., Pakistan

Steering Committee

Chair: Stephen S. Yau, Arizona State U., USA 
Hiroshi Kuwahara, Hitachi, Japan
Kinji Mori, Tokyo Inst. of Technology, Japan
Radu Popescu-Zeletin, GMD, Germany

Publicity Chair

Jorge Cobb, U. of Texas, Dallas, USA

Content-return: allowed
Date: Thu, 24 Aug 2000 12:03:22 -0700
From: David Burdett <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: "'Donald E. Eastlake 3rd'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Donald

I agree that IOTP should not include a messaging layer as was planned some
time ago. However, to achieve interoperability, IOTP will need to specify
what (which?) messaging layer to use and how to use it.

Regards

David

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 5:40 AM
To: David Burdett
Cc: [email-masked]'
Subject: Re: Draft new TRADE WG Charter, two week comment period

Hi David,

The working group has decided not to do an XML messaging layer itself.

Among the deliverables in the proposed new charter, the one most likely
to refer to this would be the IOTP v2 requirements which should say
something about requirements for the Messaging Layer.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Content-return:  allowed
Date:  Thu, 17 Aug 2000 10:20:44 -0700
To:  Eastlake Donald-LDE008 <[email-masked]>,
            "[email-masked]'" <[email-masked]>
Message-id:
<[email-masked]>

>Donald
>
>Apologies for not being able to make the last IETF meeting. However, I
think
>that work on version 2.0 of IOTP should consider use of ebXML Transport
>Routing and Packaging as meeting your first requirement for "Separation of
a
>content independent Messaging Layer".
>
>ebXML stands for electronic business XML and is a joint effort between
>UN/CEFACT who are owners of the EDIFACT standard and OASIS which is a
>non-profit organization with significant SGML & XML expertise. It includes
>the development of a content independent messaging layer.
>
>David
>
>-----Original Message-----
>From: Eastlake Donald-LDE008 [mailto:[email-masked]]
>Sent: Thursday, August 10, 2000 6:51 PM
>To: [email-masked]'
>Cc: Eastlake Donald-LDE008
>Subject: Draft new TRADE WG Charter, two week comment period
>
>
>Hi,
>
>Here is the draft charter that was presented in Pittsburgh with some minor
>edits.  I would like to send this in to our Area Director soon.  Please try
>to get any comments or suggestions to me or posted to the list within two
>weeks.
>
>Thanks,
>Donald
>
>
>Chair: Donald Eastlake 3rd <[email-masked]>
>Applications Area Advisor: Patrik Faltstrom
>
>Mailing Lists:
>	General Discussion:[email-masked] 
>	To Subscribe: [email-masked]
>	In Body: (un)subscribe
>	Archive: http://www.eListX.com/archives/ietf-trade 
>
>The Internet Open Trading Protocol is an interoperable framework
>for Internet commerce. It is optimized for the case where the
>buyer and the merchant do not have a prior acquaintance and is
>payment system independent. It can encapsulate and support payment
>systems such as SET, Mondex, secure channel card payment,
>GeldKarte, etc. IOTP is able to handle cases where such merchant
>roles as the shopping site, the payment handler, the deliverer of
>goods or services, and the provider of customer support are
>performed by different Internet sites.
>
>The working group will document interoperability experience with
>IOTP version 1 (which has been published as an Informational RFC)
>and develop the requirements for IOTP version 2. Selection of
>items for inclusion in version requirements 2 is to be from the
>following: 
> - Separation of a content independent Messaging Layer 
> - Dynamic Definition of Trading Sequences 
> - Offer Request Block 
> - Improved Problem Resolution (extend to cover presentation of
> 	signed receipt to customer support party, etc.)
> - Server to Server messages
> - Standardized XML Digital Signatures based on output from
> 	the XMLDSIG working group
> 
>The following is out of scope for IOTP version 2:
> - legal or regulatory issues surrounding the implementation of
> 	the protocol or information systems using it.
> - specification of an XML Messaging Layer
>
>The working group will specify requirements for Digital-Rights
>Trading.
>
>The working group will specify requirements for and then a syntax
>and processing model of ECML (Electronic Commerce Modeling
>Language) V2.
>
>Milestones
>
>00 Sep  Internet Draft publication
>	Secure Channel Credit/Debit
>
>00 Sep  Working Group Last Call
>	SET Supplement
>	Architecture and Payment API
>	
>00 Oct  Submit to IESG
>	SET Supplement (Informational)
>	Architecture and Payment API (Informational)
>
>00 Nov  Internet Draft publication
>	IOTP V2.0 Requirements
>	ECML V2.0 Requirements
>
>00 Nov  Submit to IESG
>	Secure Channel Credit/Debit (Proposed Standard?)
>	"Digital Rights" Trading Requirements (Informational)
>
>00 Dec  Internet Draft publication
>	IOTP V2.0 Specification
>	ECML V2.0 Specification
>
>00 Dec  Submit to IESG
>	ECML V2.0 Requirements (Informational)
>
>01 Jan  Submit to IESG
>	IOTP V2.0 Requirements (Informational)
>
>01 Feb  Submit to IESG
>	ECML V2.0 Specification (Proposed Standard)
>
>01 Mar  Submit to IESG
>	IOTP V2.0 Specification  (Proposed Standard)

Date: Thu, 24 Aug 2000 18:02:15 +0900 (JST)
From: Yoshiaki KAWATSURA <[email-masked]>
Subject: Re: Draft new TRADE WG Charter, two week comment period
To: [email-masked]
Cc: [email-masked]
Lines: 36

>>>>> Tue, 15 Aug 2000 20:34:01 +0900,
	Ko Fujimura <[email-masked]> said:

> Eastlake Donald-LDE008 wrote:
> ...
> > The working group will document interoperability experience with
> > IOTP version 1 (which has been published as an Informational RFC)
> > and develop the requirements for IOTP version 2. Selection of
> > items for inclusion in version requirements 2 is to be from the
> > following:
> >  - Separation of a content independent Messaging Layer
> >  - Dynamic Definition of Trading Sequences
> >  - Offer Request Block
> >  - Improved Problem Resolution (extend to cover presentation of
> >         signed receipt to customer support party, etc.)
> >  - Server to Server messages
> >  - Standardized XML Digital Signatures based on output from
> >         the XMLDSIG working group
> 
> Coordination between IOTP and ECML may be an item should be considered.
> I think that IOTP version 2 should specify the position of ECML version 2.
> How do you think? 

I agree with you. I think we can simplify the current specification by
collaborating with other related protocols such as ECML.

Additionally we should separate the specification document of IOTP
after it has reflected the implimentation result because the current
specification is too big and hard to progress IOTP.

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business Solution Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

Date: Wed, 23 Aug 2000 17:29:11 -0700
From: "Lewis, Tony" <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: [email-masked]

Visa would like to see the inclusion of the following additional items in
version 2 requirements:
- Customer Payment Handler
- on-going payments
- the ability to add both fields and attributes to trading blocks

An example of the use of a "Customer Payment Handler" is subtracting value
from a purse on a chip card (stored value card).

An example of on-going payments is the playing of a game where there is a
charge for each five minutes of game time.

Please let me know if you need additional information.

Tony Lewis

-----Original Message-----
From: Eastlake Donald-LDE008 [mailto:[email-masked]]
Sent: Thursday, August 10, 2000 6:51 PM
To: [email-masked]'
Cc: Eastlake Donald-LDE008
Subject: Draft new TRADE WG Charter, two week comment period

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

Date: Tue, 22 Aug 2000 08:39:42 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Draft new TRADE WG Charter, two week comment period
To: David Burdett <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Hi David,

The working group has decided not to do an XML messaging layer itself.

Among the deliverables in the proposed new charter, the one most likely
to refer to this would be the IOTP v2 requirements which should say
something about requirements for the Messaging Layer.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Content-return:  allowed
Date:  Thu, 17 Aug 2000 10:20:44 -0700
To:  Eastlake Donald-LDE008 <[email-masked]>,
            "[email-masked]'" <[email-masked]>
Message-id:  <[email-masked]>

>Donald
>
>Apologies for not being able to make the last IETF meeting. However, I think
>that work on version 2.0 of IOTP should consider use of ebXML Transport
>Routing and Packaging as meeting your first requirement for "Separation of a
>content independent Messaging Layer".
>
>ebXML stands for electronic business XML and is a joint effort between
>UN/CEFACT who are owners of the EDIFACT standard and OASIS which is a
>non-profit organization with significant SGML & XML expertise. It includes
>the development of a content independent messaging layer.
>
>David
>
>-----Original Message-----
>From: Eastlake Donald-LDE008 [mailto:[email-masked]]
>Sent: Thursday, August 10, 2000 6:51 PM
>To: [email-masked]'
>Cc: Eastlake Donald-LDE008
>Subject: Draft new TRADE WG Charter, two week comment period
>
>
>Hi,
>
>Here is the draft charter that was presented in Pittsburgh with some minor
>edits.  I would like to send this in to our Area Director soon.  Please try
>to get any comments or suggestions to me or posted to the list within two
>weeks.
>
>Thanks,
>Donald
>
>
>Chair: Donald Eastlake 3rd <[email-masked]>
>Applications Area Advisor: Patrik Faltstrom
>
>Mailing Lists:
>	General Discussion:[email-masked] 
>	To Subscribe: [email-masked]
>	In Body: (un)subscribe
>	Archive: http://www.eListX.com/archives/ietf-trade 
>
>The Internet Open Trading Protocol is an interoperable framework
>for Internet commerce. It is optimized for the case where the
>buyer and the merchant do not have a prior acquaintance and is
>payment system independent. It can encapsulate and support payment
>systems such as SET, Mondex, secure channel card payment,
>GeldKarte, etc. IOTP is able to handle cases where such merchant
>roles as the shopping site, the payment handler, the deliverer of
>goods or services, and the provider of customer support are
>performed by different Internet sites.
>
>The working group will document interoperability experience with
>IOTP version 1 (which has been published as an Informational RFC)
>and develop the requirements for IOTP version 2. Selection of
>items for inclusion in version requirements 2 is to be from the
>following: 
> - Separation of a content independent Messaging Layer 
> - Dynamic Definition of Trading Sequences 
> - Offer Request Block 
> - Improved Problem Resolution (extend to cover presentation of
> 	signed receipt to customer support party, etc.)
> - Server to Server messages
> - Standardized XML Digital Signatures based on output from
> 	the XMLDSIG working group
> 
>The following is out of scope for IOTP version 2:
> - legal or regulatory issues surrounding the implementation of
> 	the protocol or information systems using it.
> - specification of an XML Messaging Layer
>
>The working group will specify requirements for Digital-Rights
>Trading.
>
>The working group will specify requirements for and then a syntax
>and processing model of ECML (Electronic Commerce Modeling
>Language) V2.
>
>Milestones
>
>00 Sep  Internet Draft publication
>	Secure Channel Credit/Debit
>
>00 Sep  Working Group Last Call
>	SET Supplement
>	Architecture and Payment API
>	
>00 Oct  Submit to IESG
>	SET Supplement (Informational)
>	Architecture and Payment API (Informational)
>
>00 Nov  Internet Draft publication
>	IOTP V2.0 Requirements
>	ECML V2.0 Requirements
>
>00 Nov  Submit to IESG
>	Secure Channel Credit/Debit (Proposed Standard?)
>	"Digital Rights" Trading Requirements (Informational)
>
>00 Dec  Internet Draft publication
>	IOTP V2.0 Specification
>	ECML V2.0 Specification
>
>00 Dec  Submit to IESG
>	ECML V2.0 Requirements (Informational)
>
>01 Jan  Submit to IESG
>	IOTP V2.0 Requirements (Informational)
>
>01 Feb  Submit to IESG
>	ECML V2.0 Specification (Proposed Standard)
>
>01 Mar  Submit to IESG
>	IOTP V2.0 Specification  (Proposed Standard)

Date: Sun, 20 Aug 2000 12:15:11 -0500 (CDT)
From: [email-masked]
Subject: ISADS 2001 deadline extended
To: [email-masked]

Dear Colleagues:

The submission deadline for the International Symposium on Autonomous
Decentralized Systems (ISADS) 2001 has been extended
to August 31st, 2000, to accommodate some late paper requests.

For information on how to submit papers,
please go to: http://isads.utdallas.edu

Please feel free to pass this information to your
colleagues.

Thank you very much

Jorge Cobb
The University of Texas at Dallas
publicity chair, ISADS 2001

Content-return: allowed
Date: Thu, 17 Aug 2000 10:20:44 -0700
From: David Burdett <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: Eastlake Donald-LDE008 <[email-masked]>, "[email-masked]'" <[email-masked]>

Donald

Apologies for not being able to make the last IETF meeting. However, I think
that work on version 2.0 of IOTP should consider use of ebXML Transport
Routing and Packaging as meeting your first requirement for "Separation of a
content independent Messaging Layer".

ebXML stands for electronic business XML and is a joint effort between
UN/CEFACT who are owners of the EDIFACT standard and OASIS which is a
non-profit organization with significant SGML & XML expertise. It includes
the development of a content independent messaging layer.

David

-----Original Message-----
From: Eastlake Donald-LDE008 [mailto:[email-masked]]
Sent: Thursday, August 10, 2000 6:51 PM
To: [email-masked]'
Cc: Eastlake Donald-LDE008
Subject: Draft new TRADE WG Charter, two week comment period

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

Date: Wed, 16 Aug 2000 17:48:29 +0200
From: Andras Varga <[email-masked]>
Subject: RE: Draft new TRADE WG Charter, two week comment period
To: [email-masked]
Reply-to: [email-masked]
Importance: Normal

Donald Eastlake wrote:
[...]
> The working group will document interoperability experience with
> IOTP version 1 (which has been published as an Informational RFC)
> and develop the requirements for IOTP version 2. Selection of
> items for inclusion in version requirements 2 is to be from the
> following:
>  - Separation of a content independent Messaging Layer
>  - Dynamic Definition of Trading Sequences
>  - Offer Request Block
>  - Improved Problem Resolution (extend to cover presentation of
>  	signed receipt to customer support party, etc.)
>  - Server to Server messages
>  - Standardized XML Digital Signatures based on output from
>  	the XMLDSIG working group

I'd like to suggest two more items for inclusion:

1) issues concerning server-side IOTP wallets (or IOTP-enabled WalletServers).

When using server-side wallets which reside in a WalletServer,
a typical scenario is this:
 1. consumer browses in the Merchant's shop and decides to check out
 2. consumer clicks on the "Pay" link in the shop. The URL points
    to the WalletServer and contains additional parameters like
    e.g. merchant address and order number
 3. consumer logs into the WalletServer
 4. the WalletServer retrieves the Offer from the Merchant;
    data for this (e.g. OfferRequest URL) come from parameters
    from the URL used to invoke the WalletServer
 5. now payment & delivery goes on like the Consumer had
    a locally installed IOTP wallet

An item which would be worth standardizing is the URL used to
invoke the WalletServer. (Using such an URL to get to the
WalletServer has certain advantages over using e.g. a mime-type
sent down from the shop.)

This URL should include parameters which -at minimum- tell
the WalletServer where to send the OfferRequest.

2) mixing IOTP with other payment protocols.

Some existing payment protocols like SET or Geldkarte
are pretty difficult to tunnel through IOTP (bridges require
significant implementation effort). At the same time
it would be nice to be able to use IOTP e.g. for retrieving
offer or requesting delivery, which is not (properly) covered
by other protocols. Such a feature would probably increase
the usefulness and thus the acceptance of the IOTP standard.

The IOTP specification should explicitly allow for payment
protocols that are not tunnelled through IOTP. There should
be a way to specify protocols in the IOTP OfferResponse
that are to be used standalone with Merchant's Payment Handler
(ie. not tunnelled through IOTP).

Other modifications might also be necessary on the IOTP protocol
to accomodate such a feature, for example signed PayReceipt
is not possible if the payment was not done via IOTP.

Best regards,
  Andras Varga

----------------------------------------------------------
Andras Varga                    |  Brokat Ag.
E-mail: [email-masked] |  Commerce Division
Phone: +36-1 437-0413           |  Research & Development
Fax:   +36-1 387-3798           |  Kunigunda útja 58.
http://www.brokat.com           |  1037 Budapest, Hungary

Date: Tue, 15 Aug 2000 20:34:01 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Draft new TRADE WG Charter, two week comment period
To: [email-masked]

Eastlake Donald-LDE008 wrote:
...
> The working group will document interoperability experience with
> IOTP version 1 (which has been published as an Informational RFC)
> and develop the requirements for IOTP version 2. Selection of
> items for inclusion in version requirements 2 is to be from the
> following:
>  - Separation of a content independent Messaging Layer
>  - Dynamic Definition of Trading Sequences
>  - Offer Request Block
>  - Improved Problem Resolution (extend to cover presentation of
>         signed receipt to customer support party, etc.)
>  - Server to Server messages
>  - Standardized XML Digital Signatures based on output from
>         the XMLDSIG working group

Coordination between IOTP and ECML may be an item should be considered.
I think that IOTP version 2 should specify the position of ECML version 2.
How do you think? 

> 
> The following is out of scope for IOTP version 2:
>  - legal or regulatory issues surrounding the implementation of
>         the protocol or information systems using it.
>  - specification of an XML Messaging Layer
> 
> The working group will specify requirements for Digital-Rights
> Trading.

I'm sorry for not resolving the issue of the document title.
How about "Requirements for Generic Rights Trading"?

Regards,

Ko Fujimura

Content-return: allowed
Date: Thu, 10 Aug 2000 21:51:27 -0400
From: Eastlake Donald-LDE008 <[email-masked]>
Subject: Draft new TRADE WG Charter, two week comment period
To: "[email-masked]'" <[email-masked]>
Cc: Eastlake Donald-LDE008 <[email-masked]>

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

Content-return: allowed
Date: Wed, 09 Aug 2000 14:27:39 -0400
From: Eastlake Donald-LDE008 <[email-masked]>
Subject: Draft TRADE WG minutes from Pittsburgh IETF
To: "[email-masked]'" <[email-masked]>

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_wrul20i3iuoPtpi/swu/sA)
Content-type: text/plain; charset="iso-8859-1"

Corrections/Comments welcome...I'll be putting up the slides for anonymous
FTP and send out a separate notice when that is done.

 <<TradeMinutes.txt>> 
Donald

--Boundary_(ID_wrul20i3iuoPtpi/swu/sA)
Content-type: text/plain; name="TradeMinutes.txt"
Content-disposition: attachment; filename="TradeMinutes.txt"

TRADE WG Meeting, 1 August 2000, 13:00 hours

Minutes (Taken by Ed Simon of Entrust, edited by Donald Eastlake):

Donald Eastlake ran the meeting. (see slides)

There were no changes in the suggested Agenda.

There was an extensive review of Working Group document status
	including approved documents, un-approved Internet Drafts,
	and planned documents not yet out as Internet Drafts.
	
Status of ECML and the ECML Alliance (www.ecml.org) was
	discussed.  They are advocating an XML format for ECML
	v2.  It is still the plan that they will finish up ECML
	1.1 as an ECML Alliance document and hand ECML v2 to the
	working group.
	
Question: What about all the other XML business message format
	messages?
Answer: Rick Drummond, chair of EDIINT and of the sub-group
	of ebXML working in the XML transport area has had
	considerable communications with Donald Eastlake.  The
	WG consensus appears to be let some more transport
	oriented and less application oriented working group handle
	the XML messaging level.
Q Steve Hole: Should there be a new WG to handle XML
	Messaging and business headers?
A Donald Eastlake: Let's discuss this more after Ko Fujimura's
	presentation since it is relevant.
	
There was no new implementation news.
	Hitachi and Royal Bank of Canada, who both implemented
	IOTP v0.9, are definitely implementing IOTP 1.0.  About
	a half dozen other companies have also said they are
	implmeneting IOTP v1.

Ko Fujimura of NTT, speaking for himself as an individual,
	gave his presentation on ECML v2 and IOTP.  See his slides.

Donald Eastlake presented the suggested updated and modified
	charter. (see slides)  People interested were urged to
	subscribe to the WG mailing list.

[Q=Question, A=Answer, C=Comment]
Q Steve Hole: Where has XML messaging gone?
A Donald Eastlake: David Burdett, who wrote the current XML
	Messaging Requirements draft in the TRADE WG, and Rick
	Drummond of EDIINT and ebXML noticed the overlap in
	effort.  The WG consensus has been that XML Messaging
	need NOT be done in the TRADE WG.
C Dick Brooks: The World Wide Web Consortium (W3C) is looking
	into XML transport protocls.
Q Steve Hole: Isn't the W3C more appropriate for XML
	protocols?
Discusion continued on whether the W3C or IETF or other forums
	were best for this work.
Q Steve Hole: Should there be an EDI follow on working group?
C Dick Brooks: The current EDIINT is still in existence just
	because it was waiting on S/MIME to finalize a document it
	depends on.
C Donald Eastlake: Messaging is interesting but not
	specifically to just the TRADE working group.  We should
	presume that messaging will be done by someone else.  The
	charter needs to be changed.  I will send it out to the
	list for comments and then ask the IESG to adopt it.

Future Meetings
	There was no objection to the next meeting being in December
	2000 at the San Diego IETF meeting.

--Boundary_(ID_wrul20i3iuoPtpi/swu/sA)--

Date: Mon, 07 Aug 2000 11:10:37 +0900
From: Ko Fujimura <[email-masked]>
Subject: XML-Wallet
To: [email-masked]
Cc: [email-masked]

Hi all,

My slides presented at the trade WG meeting in Pittsburgh, are uploaded 
to the following URL:

http://info.isl.ntt.co.jp/flexticket/ietf/ietf48-trade-fujimura.ppt

The summary of my talk is as follows:

1. An XML-based wallet, which can handle diverse types of EC entities, 
   e.g., orders, bill, payment receipt, delivery notes, as well as 
   payment information, is required.
2. The XML-based wallet should provide a simple store/retrieve protocol 
   to transmit the EC entities (just like the HTTP cookie protocol).
3. The XML-based wallet should allow any vendors to provide plug-ins 
   that handle any sophisticated protocols. An example of such plug-ins 
   includes an IOTP wallet, digital-rights wallet, or other 
   payment-scheme-specific wallets.

I think such wallet architecture will bridge IOTP, ECML, and 
digital-right-trading model seamlessly.  I hope the trade WG will develop 
a new standard, which bring us a new type of killer client application, 
i.e., XML-Wallet.

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Thu, 03 Aug 2000 01:20:54 -0500 (CDT)
From: [email-masked]
Subject: Deadline approaching, Autonomous Decentralized Systems Symposium CFP
To: [email-masked]

* please forgive us if you receive multiple copies of this message
* feel free to distribute to your colleagues.

http://isads.utdallas.edu

                         ISADS 2001 CALL FOR PAPERS

                  The Fifth International Symposium on
                    Autonomous Decentralized Systems

		    with an emphasis on electronic commerce

                  Monday March 26 - Wednesday March 28, 2001
                         Dallas, Texas, USA

Paper deadline: August 15, 2000

Sponsored by:

                         IEEE Computer Society 
              Information Processing Society of Japan 
        The Society of Instrument and Control Engineers of Japan 
    The Institute of Electronics, Infor. and Communication Engineers, Japan 

In Cooperation with:

             International Federation for Information Processing 
             International Federation of Automatic Control 
                             OMG 
                            TINA-C 
          Manufacturing Science and Technology Center, Japan 

Scope: 

Driven by the continuous growth in the power, intelligence and openness of
computer, communication and control technologies, possibilities and
opportunities for realizing highly efficient and dependable business and
control systems have been steadily increasing.  Dynamically changing
social and economic situations demand next-generation systems based on
emerging technologies and applications. Such systems are expected to have
the characteristics of living systems composed of largely autonomous and
decentralized components. Such systems are called Autonomous Decentralized
Systems (ADS).

After the successful first, second, third, and fourth International
Symposium on Autonomous Decentralized Systems (ISADS) held in 1993 in
Japan, in 1995 in the USA , in 1997 in Germany, and in 1999 in Japan, the
fifth ISADS will be held in Dallas, Texas, USA during March 26-28, 2001.
While ISADS 2001 will primarily focus on advancements and innovation in
ADS concept, technologies, and applications related to the increasingly
important topic of *Electronic Commerce*, other themes such as
telecommunications and heterogeneous system and application integration
will also be included.

The ISADS 2001 committee invites papers and panel proposals on the topics
of the symposium that will foster interactions among researchers and
practitioners in computer, communication, management, control as applied
to electronic commerce and other related fields from academia, industry,
and government.

The scope of discussions on ADS shall include, but not be limited 
to: 

* Computer and communication architectures / intelligent network /Internet; 
* Heterogeneous distributed information / control systems; 
* Mobile agent /computer-supported cooperative works;
* Distributed software development and maintenance;
* Assurance, fault tolerance and on-line expansion; 
* Object management architecture /design pattern / application frameworks; 
* Emergent control and robotic systems; 
* Novel applications: electronic commerce, telecommunications, 
  information service systems, manufacturing systems, 
  real-time event management, office automation, traffic and 
  transportation control, logistics systems. 

Plant tour is scheduled on March 29, 2001. Delegates are encour-
aged to participate. 

Information for Authors 

Papers should describe original work (not submitted or published
elsewhere) and be 20 double-spaced pages (5,000 words) or less in length.
Papers should include: title, authors, affiliations, 150-word abstract and
list of keywords.

Identify the author responsible for correspondence, including the author's
name, position, mailing address, telephone and fax numbers, and email
address. One of the authors of each accepted paper must present the paper
at ISADS 2001.

Information for Panel Organizers 

Panel proposals should include: title, organizer's affiliations, position,
mailing address, telephone and fax numbers, email address, and 150-word
statement on the scope, proposed chair and panelists.

Submission Address 

Authors and panel organizers are requested to submit their manuscripts
electrically in the Microsoft WORD document file format, the PDF format,
or the Postscript format, and also email the abstract and the full
addresses of the author(s) to the following address:

[email-masked]

Note The program committee of ISADS2001 highly encourage electronic
submissions. Otherwise, papers should be sent to the program chair:

Dr. Bhavani Thuraisingham
Mail Stop A270
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
Phone: 781-271-8873
Fax: 781-271-8752
Email: [email-masked]

General Information 

For general information, see our World-Wide Web Page at: 

http://isads.utdallas.edu

The proceedings of the symposium will be published by IEEE Computer
Society Press.

Important Deadlines

August 15, 2000: All papers and panel proposals are due
November 15, 2000: Authors and panel organizers notified of acceptance. 
December 15, 2000: Camera-ready copies of accepted papers and 
panelists' position papers 

General Chair
William Osborne, U. of Texas, Dallas, USA

Program Committee

Chair: Bhavani Thuraisingham, The MITRE Corp., USA 

Co-Chair: Makoto Imase, NTT Labs, Japan
Co-Chair: Linda Strick, GMD Fokus, Berlin, Germany 
Co-Chair: Jeffrey Tsai, U. of Illinois, Chicago, USA 

Members
G. Agha, U. of IL, Urbana, USA
R. Arai, U. of Tokyo, Japan
D. Bae, KAIST, Korea  
F. Bastani, U. of TX, Dallas, USA
E. Bertino,  U. of Milano, Italy
M. Ceruti, SPAWAR, USA
I. Chen, Virginia, Tech, USA
Y. Chen, U. of the Witwatersrand, South Africa
R. Chow, U. of FL, USA
J. Chung, IBM T.J. Watson Research Center, USA
P. Chuang, Tamkang U., Taiwan
P. Ciancarini, U. of Bologna.
B. Cukic, West Virginia U., USA
K. Eckert, GMD FOKUS Germany
S. Eisenbach, Imperial College, UK
D. Ferrari, U. of Catoloca, Italy
M. Fisher, Manchester Metropolitan U., UK
M. Fujita, Sony, Japan
A. Fukuda, Nara Inst. of Science and Technology, Japan
V. Garg, Univ. of TX, Austin, USA
S. Ghosh, Arizona State U., USA       
A. Ghafoor,  Purdue U., USA
A. Ghose, U. of Wollongong, Australia
M. Gien, Sun, France
V. Gobel, U. of Oslo, Norway
T. Higashino Osaka U., Japan   
D. Hislop, ARO, USA
I.  Iida, Fujitsu, Japan
Y. Ishiguro, NEC, Japan
K. Ito, TITECH, Japan
Y. Kakuda, Hiroshima City U., Japan
K. Kim, U.C. Irvine, USA 
H. Kopetz, TU Wien, Austria
J. Kramer, Imperial College, UK
L. LeLann, INRIA, France
C. Liu, Chung Yuan Christian U., Taiwan
M. Lyu, The Chinese U. of Hong Kong, Hong Kong
Y. Masunaga, Ochanomizu U., Japan 
W. Meng , State U. of New York at Binghamton, USA
R. Montanari, U. of Bologna, Italy
W. Ng, Nanyang Technological U., Singapore
A. Prakash, U. of Michigan, USA
J. Putman, MITRE, USA
Q. Qingquan, Southwest Jiatong U., China
N. Raynal, INRIA, France
W. Ruh, Concept-V, USA
D. Serpanos, Inst. of Comuter Science, Technology-Hellas, Greece
S. Shekhar, U. of MN, Mpls, USA
L. Simoncini, CNUCE-CNR, Italy
R. Stroud, U. of  New Castle, UK
V. Subrahmanian, U. of MD, College Park, USA
K. Tsuchiya, Kyoto Uv, Japan
B. Wah, U. of  IL, Urbana, USA
Y. Wakahara, U. of Tokyo, Japan
F.  Wang, National Chao Tung U., Taiwan
M. Wooldridge, U. of Liverpool, UK
H. Yokota, TITECH, Japan  
M. Yano, Tohoku U., Japan
S. Yongqiang, Shanghai Jiao Tong U, China
P. Yu, IBM T.J. Watson Research Center
S. Zubairy, Quaid-e-Azam U., Pakistan

Steering Committee

Chair: Stephen S. Yau, Arizona State U., USA 
Hiroshi Kuwahara, Hitachi, Japan
Kinji Mori, Tokyo Inst. of Technology, Japan
Radu Popescu-Zeletin, GMD, Germany

Publicity Chair

Jorge Cobb, U. of Texas, Dallas, USA