Subject: ISADS 2001 Call for Participation
From: [email-masked]
To: [email-masked]
Date: Tue, 30 Jan 2001 19:37:27 -0600 (CST)

(* our apologies if you receive multiple copies *)

                    ISADS 2001 CALL FOR PARTICIPATION

                  The Fifth International Symposium on
                    Autonomous Decentralized Systems

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

                     http://isads.utdallas.edu

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 four successful symposiums, the Fifth International Symposium on
Autonomous Decentralized Systems (ISADS)  will be held in Dallas, Texas,
USA during March 26-28, 2001. While ISADS 2001 will primarily focus on
advancements and innovation in the ADS concept, technologies and
applications related to the increasingly important topic of *Electronic
Commerce* are also included.

The symposium features 13 paper sessions and seven panel sessions, whose
titles are below.

In addition to the paper and panel sessions, the following events have
been organized.

   * Reception (March 26)
   * Banquet (March 27) 
   * A tour and dinner at the famous Southfork Ranch of Dallas (March 28). 
   * A plant tour of two telecommunication companies in the Dallas area, 
     Alcatel and Nortel (March 29).

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

                 http://isads.utdallas.edu

Important Deadlines:

   *March 1, 2001 - Deadline for early registration 
   *March 2, 2001, 5:00 p.m. central time - 
           Any reservation at the conference hotel 
           received after the cut-off date will be accepted based on 
           space availability 

Paper Sessions:

   *E-commerce Models and Protocols 
   *High Assurance Systems 
   *Fault Tolerance and Safety Critical Systems 
   *Architecture and Models for Distributed Systems 
   *E-commerce Technology and Architecture 
   *Distributed Object Management Systems 
   *Short Papers: Distributed Object Management and Control 
   *Multiagent systems 
   *Middleware Technologies 
   *Agent Technology for E-commerce 
   *Self Stabilizing Systems 
   *Secure Systems and Applications 
   *Modeling and Performance 

Panel Sessions:

   *XML and E-Business Frameworks 
   *Agent-Based Electronic Commerce: Opportunities and Challenges 
   *Embedded Systems 
   *Mobile Computing and Communication 
   *Robotics for Education and Entertainment 
   *Security for the Web and E-Commerce Systems 
   *Plenary closing panel: Future of Autonomous Decentralized Systems 

Date: Wed, 24 Jan 2001 16:10:26 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Working Group Last Call and naming fordraft-ietf-trade-drt-requirements-01.txt
To: Renato Iannella <[email-masked]>
Cc: [email-masked]

Thank you for your suggestions and links to the DRM resources.

Renato Iannella wrote:
> 
> Use of "rights" implies intellectual/legal/social behaviours, such
> as copyright, moral rights etc. The modelling, requirements, languages
> for this type of right is significant (see [1] to [11]).
> 

I think that "rights" are often used for "access rights" as well as "IP rights". 
Example of such usage are found in RFC2086, 2820, and draft-ietf-ldapext-acl-model-06.txt

I also think that most of "tickets" are a kind of "access rights" for a physical
resources, and those concept are similar. I, therefore, think that the usage of 
"rights" in the draft is common, too.
I believes that what this draft describes is nothing more than "trading aspect of rights".

> This leads me to the point in "Section 7. Q & A"
> 
> ----
>   - Is it possible to ensure digital "property" rights?
> 
>   Yes, since digital property rights can be considered as a kind of
>   electronic-right. RTS, however, would need to be extended by adding
>   some protected rendering system that would regenerate the original
>   digital contents securely.
> -----
> 
> I would say they answer is "No". You cannot _ensure_ this.
> (see the references below)

Right. I would like to change it to:

  - Is it possible to support "digital property right?"

  Digital property right can be considered as a kind of electronic-right and
  it can be traded using RTS.  However, some protected rendering system would 
  be required to regenerate the digital contents securely in order to support 
  digital property rights. These requirements are out of scope of RTS.

Regards,

Ko

Content-return: allowed
Date: Mon, 15 Jan 2001 13:19:12 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: FW: Comment & Q: ECML 1.1 Internet draft
To: "[email-masked]'" <[email-masked]>

This is a comment on the v1.1 draft but is relevant to v2 of ECML...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 24, 2000 12:48 PM
To: Donald.Eastlake
Subject: Comment & Q: ECML 1.1 Internet draft

...

I read through the ECML 1.1 internet draft and
noticed that it is prepared for mobile transactions 
by providing in the Ecom_Payment_Card_Protocol 
field the initial list tokens like 'simcard' and 'phoneid'. 

If I understand correctly, the explanation of
these tokens refer to the use of of some, probably 
operator-specific system, either for billing via phone
bill or by using some SIM toolkit-based solutions.
So, unlike other tokens, these tokens do not refer to a
specific protocol. 

IMHO, this could be problematic in cases where the merchant
and wallet user are not using the services of the same
operator for payments. The token 'simcard' for example 
may then mean different things on the wallet side and on
the merchant side. 

...

Best Regards,
Mia

Mia Lahteenmaki
[email-masked]
(Nokia Research Center)
mobile +358 40 7431965
fax +358 9 4376 6139 

Note: These comments and views are solely mine and not my employer's

Date: Mon, 15 Jan 2001 11:59:44 +0800
From: Xu WANG <[email-masked]>
Subject: A minor point on iotp spec.
To: [email-masked]
Organization: Dept. of Comp. Sci., Hong Kong Univ. of Sci.&Tech.
Full-name: Wang Xu

This is a multi-part message in MIME format.

--Boundary_(ID_uwKKhepg9cu+1y1gdM2VoA)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Hi, dear all

On page 149 of the iotp spec., it says,

"  ATTRIBUTE ELEMENT

   There must be one and only one Attribute Element that contains a Type

   attribute with a value of IOTP Signature Type and with content set to

   either: OfferResponse, PaymentResponse, DeliveryResponse,
   AuthenticationRequest, AuthenticationResponse, PingRequest or
   PingResponse; depending on the type of the signature.
"

I think we should also need add some other values(AuthenticationStatus,
InquiryRequest and InquiryResponse), and make corresponding change to
page 81 and 261.

What do you think, or is there anything I misunderstood the spec.

Regards,

WANG Xu

--Boundary_(ID_uwKKhepg9cu+1y1gdM2VoA)
Content-type: text/x-vcard; name=xuwang.vcf; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=xuwang.vcf
Content-description: Card for Xu WANG

begin:vcard 
n:WANG;Xu
tel;fax:+852-2358-1477
tel;work:+852-2358-6992
x-mozilla-html:FALSE
org:Dept. of Computer Science;Hong Kong Univ. of Science&Technoloy
version:2.1
email;internet:[email-masked]
title:Research Associate
adr;quoted-printable:;;Clear Water Bay Road 660, Kowloon=0D=0A;Hong Kong;;;
fn:Xu WANG
end:vcard

--Boundary_(ID_uwKKhepg9cu+1y1gdM2VoA)--

Date: Fri, 12 Jan 2001 16:22:55 +0100
From: "Silke Holtmanns (EED)" <[email-masked]>
Subject: RE: Another short comment on ECML
To: "[email-masked]'" <[email-masked]>

Hello,

from my personal experience I think 22 should be enough 
for most of the names.

Greetings Silke

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Friday, January 12, 2001 3:57 PM
To: Silke Holtmanns (EED)
Cc: [email-masked]'
Subject: Re: Another short comment on ECML

Hi,

Is there any particular length you would recommend as the minimum any
general ECML implementation should be able to handle?

Thanks,
Donald

From:  "Silke Holtmanns (EED)" <[email-masked]>
Date:  Fri, 12 Jan 2001 10:43:22 +0100
To:  "[email-masked]'" <[email-masked]>
Message-id:  
	     <[email-masked]>
Content-type:  text/plain

>Hello,
>
>maybe a comment on the length of the "last name fields".
>
>In Europe double names or long names are very common!
>So 15 characters is very short. 
>
>Greetings Silke

Date: Fri, 12 Jan 2001 09:56:40 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Another short comment on ECML
To: "Silke Holtmanns (EED)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Hi,

Is there any particular length you would recommend as the minimum any
general ECML implementation should be able to handle?

Thanks,
Donald

From:  "Silke Holtmanns (EED)" <[email-masked]>
Date:  Fri, 12 Jan 2001 10:43:22 +0100
To:  "[email-masked]'" <[email-masked]>
Message-id:  
	     <[email-masked]>
Content-type:  text/plain

>Hello,
>
>maybe a comment on the length of the "last name fields".
>
>In Europe double names or long names are very common!
>So 15 characters is very short. 
>
>Greetings Silke

Date: Fri, 12 Jan 2001 22:50:54 +0900
From: TERAMURA Takeshi <[email-masked]>
Subject: Re: IOTP Implementation
To: [email-masked]
Cc: [email-masked]

Hello,

> Since I read the news about the implementation a few questions
> turned up:
> What has Hitachi implemented? (only some components or some block)

Hitachi implemented the following modules:
- IOTP application core:
  - Consumer Client
  - Merchant Server
  - Payment Handler Server
  - Delivery Handler Server
- IOTP payment bridge:
  - SET bridge( for client / server )
  - SECE bridge( for client / server )
    * SECE(Secure Electronic Commerce Environment) is the specification
      including debit protocol.
  - Mondex bridge( for client / server )

> (If you can say)
> It would be good for the "wireless people" to know the problems that occur, maybe we
> can then avoid some of them ..... 

I think client size and performance will be issues when mobile phone 
is used as platform. Because the computer resources(CPU, memory) of 
the mobile phone may be less powerful than PC. 

Regards

---
Takeshi Teramura
5th department
Systems development laboratory
Hitachi, Ltd.

Date: Fri, 12 Jan 2001 10:43:22 +0100
From: "Silke Holtmanns (EED)" <[email-masked]>
Subject: Another short comment on ECML
To: "[email-masked]'" <[email-masked]>

Hello,

maybe a comment on the length of the "last name fields".

In Europe double names or long names are very common!
So 15 characters is very short. 

Greetings Silke

Date: Thu, 11 Jan 2001 16:19:07 +1000
From: Renato Iannella <[email-masked]>
Subject: Re: Working Group Last Call and naming for draft-ietf-trade-drt-requirements-01.txt
To: [email-masked]
Cc: "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]

--On 3/1/01 4:24 PM -0500 Donald E. Eastlake 3rd wrote:

> As far as I know, the only point
> in controversy is the name of the things for which trading
> requirements are given.  Suggestions have included digital rights,
> electronic rights, trading right, entitlement, coupon, and certificate
> as well as generic rights.  But most suggestions have some particular
> problem as well.  Unless there is a consensus to change, as show by
> discussion on this mailing list, we will stick with the current
> terminology.

I still believe that using "rights" is misleading for this document.
A more appropriate term would be "voucher". (In fact, you should be
able to do a string find/replace through-out the whole document.)

All the examples in the document are focussed on the value of
an "exchange ticket" for an *arbitrary* good or service.

Use of "rights" implies intellectual/legal/social behaviours, such
as copyright, moral rights etc. The modelling, requirements, languages
for this type of right is significant (see [1] to [11]).

This leads me to the point in "Section 7. Q & A"

----
  - Is it possible to ensure digital "property" rights?

  Yes, since digital property rights can be considered as a kind of
  electronic-right. RTS, however, would need to be extended by adding
  some protected rendering system that would regenerate the original
  digital contents securely.
-----

I would say they answer is "No". You cannot _ensure_ this.
(see the references below)

Cheers...Renato                       <http://purl.net/net/renato>
Chief Scientist, IPR Systems Pty Ltd       <http://iprsystems.com>
W3C Workshop on Digital Rights <http://w3.org/2000/11/w3c-drm-cfp>

DRM Modelling
[1] http://www.indecs.org/
[2] http://www.propagate.net/
[3] http://www.openebook.org/framework/

DRM Background Papers
[4] http://www.oasis-open.org/cover/ericksonRT19990624.pdf
[5] http://www.iprsystems.com/whitepapers/Papers/Rights_Management.pdf
[6] http://www.cisp.org/imp/february_2000/02_00gladney.htm
[7] http://mjosa.stanford.edu/~roscheis/IMA/index.html

DRM Requirements
[8] http://www.publishers.org/home/drm.pdf
[9] http://www.cselt.it/leonardo/mpeg/public/mpeg-4_ipmp.zip

DRM Languages
[10] http:://odrl.net
[11] http://www.xrml.org

Content-return: allowed
Date: Wed, 10 Jan 2001 14:48:44 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: ECML Comments
To: "[email-masked]'" <[email-masked]>

Below were some comments on the ECML v1 spec forwarded with permission as
input on the ECML v2 requirements document.

Thanks,
Donald

FName:           Ruediger Jungbeck
Company:         RSJ Software GmbH
Telephone:       +49 89 894142-11
FAX:             +49 89 894142-80
Email:           [email-masked]
Date:            07 Dec 2000
Time:            05:46:19

Comments:

Your specification seems not to recognize international markets.

Your email addresses are too short.
Your phone numbers are too short.
No fields if customer is a company.
No provisions for handling of option lists (for country and province).

There is not much acceptance in the market for your standard.
It is easier to fill out your  Feedback form (which has fields like Company,
Name etc my browser (IE5.5) knows about from other sites) than your order
form.

Wouldn't it be better to have only a translation specification in the HTML
form (ie hidden fields telling the ECML aware browser (-extension) how to
fill out an form, than renaming the fields themself).

Regards

Ruediger Jungbeck
RSJ Software GmbH

Date: Tue, 09 Jan 2001 12:47:25 +0100
From: "Silke Holtmanns (EED)" <[email-masked]>
Subject: IOTP Implementation
To: "[email-masked]'" <[email-masked]>

Hello,

the Ecomeg group (Electronic expert group) in the 
WAP forum is in the moment developing a EFI Payment Class. 
This payment class shall take care of  the payment process as a whole.
It shall support a wide range of payment protocols.

This payment class has some strong similarities to IOTP.
It is structured differently, but on the other hand contains 
similar information (brand, payment protocol,..). I believe it
makes sense to make the EFI payment class very similar
to IOTP (or at least parts of it) to support the convergence between the 
"wireless wap world" and the internet.

Since I read the news about the implementation a few questions
turned up:
What has Hitachi implemented? (only some components or some block)
(If you can say)
It would be good for the "wireless people" to know the problems that occur, maybe we
can then avoid some of them ..... 

Greetings Silke 

Silke Holtmanns
Ericsson Eurolab Deutschland GmbH
Ericsson Allee 1
52134 Aachen
Tel. ++49 2407 575 7751
Fax ++49 2407 575 400
[email-masked]

Date: Fri, 05 Jan 2001 13:40:44 +0900
From: TERAMURA Takeshi <[email-masked]>
Subject: Hitachi's implementation of IOTP
To: [email-masked]

Dear Folks:

Don asked us who should be contacted when people have 
questions about Hitachi's implementations of IOTP including 
the SMILE project.

When you have questions about Hitachi's implementations, 
please contact me.

Best Regards

---
Takeshi Teramura  [email-masked]
Researcher
5th department, Systems Development Laboratory 
Hitachi, Ltd.

Date: Wed, 03 Jan 2001 16:24:52 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Working Group Last Call and naming for draft-ietf-trade-drt-requirements-01.txt
To: [email-masked]
Cc: [email-masked]

This is a working group last call announcement for the document
currently titled "Requirements for Generic Rights Trading".  The Last
Call is to run through January 22th.  As far as I know, the only point
in controversy is the name of the things for which trading
requirements are given.  Suggestions have included digital rights,
electronic rights, trading right, entitlement, coupon, and certificate
as well as generic rights.  But most suggestions have some particular
problem as well.  Unless there is a consensus to change, as show by
discussion on this mailing list, we will stick with the current
terminology.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Tue, 02 Jan 2001 08:57:53 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: FW: Draft minutes of trade IETF San Diego
To: Ko Fujimura <[email-masked]>
Cc: [email-masked]

Corrected minutes are available at
<ftp://ftp.pothole.com/pub/ietf-trade/IETF-SanDiego/minutes.txt> and
will be submitted, along with the slides, for the proceedings in the
next few days.

Thanks,
Donald

From:  Ko Fujimura <[email-masked]>
Date:  Wed, 20 Dec 2000 20:48:37 +0900
To:  [email-masked]
Cc:  [email-masked]
Message-id:  <[email-masked]>

>Hi Walter and Donald,
>
>Thank you very much for the minutes. I have a few comments:
>
>Eastlake III Donald-LDE008 wrote:
>> 
>> Minutes of the Internet Open Trading Protocol Working Group (trade)
>> 
>> Wednesday, December 13 at 1300-1500
>> =====================================
>> 
>> CHAIR: Donald Eastlake 3rd [email-masked]
>> Minutes: Walter Houser [email-masked]
>...
>> 7. Digital Rights Requirements - also known as Requirement for Generic
>> Payments Rights - presentation by Ko Fujimura.
>
>The title was "Requirements for Generic Rights Trading"
> 
>> RTS is an infrastructure to circulate diverse types of digitally
>> represented rights. RTS is enables digital versions of coupons and
>> tickets. We need to prevent copying.  RTS should allow sharing between
>> several issuers. There are five requirements:
>> 
>> -       Prevent alternation
>> -       Provide non-repudiation,
>> -       Provide idempotency (one and only one)
>> -       Prevent reproduction
>> -       Prevent duplicate redemption.
>> 
>> Fujimura presented a Chart for Positioning of RTS in trading area shows
>> the relationship of RTS with respect to IOTP. Hole observes that one needs
>> to trust the coupon. Fujimura replied that trust of the coupon is the
>> result of the issuer, which can be handed around by untrusted bodies. 
>
>Yes, but more correctly, I replied that:
>
>"trust of the coupon is the result of the issuer and the RTS. The issuer is
>responsible for the contents of the right and the RTS is responsible
>for preventing copy. In other words, if there is trust in the issuer and 
>the RTS, trust of the holder who transfers or redeems the coupon is not 
>required."
>
>> The RTS object is an XML object, which would be defined by the WG.
>
>I think it means that:
>
>"The objects transported by the RTS is an XML Components which would be defined 
>by the WG."
> 
>> Hole observed that the definition of the data representation is distinct from
>> the transport issues. The latter may be appropriate for the WG, but they
>> are nontrivial.
>>
>> The working group suggested several terms to use in lieu of digital rights
>> or electronic rights, such as trading right, entitlement, coupon, and
>> certificate. There was concern about confusion of the term rights with
>> access control rights. Entitlement was thought cumbersome. Coupon
>> communicates too much of a limitation. Certificate has a specific meaning
>> with respect to network security.
>...
>
>Please add:
>
>"It was agreed to decide the term using the mailing list."
>
>Thanks.
>
>Ko

Date: Tue, 02 Jan 2001 08:53:53 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Generic Right Trading (was Fw: FW: Draft minutes of trade IETF San Diego )
To: Raghuram Rajah <[email-masked]>
Cc: [email-masked]

Hi Raghu,

As an IETF Working Group, the mailing list is the primary forum for
discussion and agreement.  I'd welcome you posting material on what
your group has developed.

Since we plan to put through the Requirements for Generic Rights
Trading document
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-01.txt>
as a final informational document soon, it would be particularly
helpful to get your comments on that requirements document within the
next two or three weeks...

Thanks,
Donald

From:  Raghuram Rajah <[email-masked]>
Date:  Thu, 21 Dec 2000 11:06:52 -0500
To:  [email-masked]
Message-id:  <[email-masked]>

>Yes, I did intend to send it to the group and I thought I did too. I =
>am surprised it was sent only to you. Sorry about the confusion. Than=
>ks for getting me upto speed. =20
>
>Going forward, do we plan to use the mailing list at all, or would we=
> want to discuss in the f2f only?
>
>Will send a write-up on the thoughts that we had developed for repres=
>enting rights (we were calling it coupons, though I know it is a mis-=
>leading as well) soon to the group (atleast this time ;-) ).
>
>Raghu.

>Sent: Thursday, December 21, 2000 6:58 AM
>To: Raghuram Rajah
>Cc: Donald E. Eastlake 3rd; [email-masked]
>Subject: Re: FW: Draft minutes of trade IETF San Diego

>Hi Raghu,
>
>> Hi Ko / Walter / Donald / all,
>
>I think that your mail is intended to sent the mailing list but sent =
>only to me.
>Anyway, I would like to answer it.
>
>> I have been a part of this group for over a month now and haven't s=
>een any discussion on the rights requirements or the RTS in general. =
>Didn't find a whole lot in the archives either.
>> Is there a private group working on these requirements and the RTS =
>framework?
>
>There was. But, about one year ago I closed it, since it is not activ=
>e. So, any discussion
>should be done the trade mailing list or face-to-face meeting now. We=
> haven't actively
>discussed using the mailing list. But, we had 5 face-to-face meeting =
>since the 45th IETF Oslo meeting. I think it enough for discussing re=
>quirements.
>
>> The reason I ask is, I have been leading a development of a similar=
> system and have been battling the very same requirements in the cont=
>ext of embedded devices with limi=3D
>ted computing power. We have made some progress in addressing these r=
>equirements and have come up with a generic framework. Though the fra=
>mework and the model needs more work, I guess we are headed in the ri=
>ght direction.
>
>Thank you. But, I think the next work item is to develop draft for Ri=
>ghts Component, i.e., XML representation of rights. I'm not sure if f=
>ramework and the model should be specified.
>
>> We would want to present our model, for review by the WG to develop=
> the RTS I-D, potentially.
>
>Meeting agenda is chair's decision, but I think that Don will allow y=
>ou to present it.
>
>> Or if the development of the framework or model is already underway=
> by the WG, we would like to contribute to the same. Also, we could a=
>dopt the early releases and can=3D
>act as a test bed.
>
>Any contributions are welcome! I hope you actively join the discussio=
>n.
>
>> Please let me know if a private group is involved in developing the=
>se standards? And if so, how can I join that group? How does the work=
>ing group operate in developing these drafts?
>> Please advise.
>
>Send the trade mailing list what you are thinking. Do not hesitate to=
> do so.
>
>Regards,
>
>Ko
>
>P.S. My I ask your company? Just curious.

Date: Tue, 30 Jan 2001 19:37:27 -0600 (CST)
From: [email-masked]
Subject: ISADS 2001 Call for Participation
To: [email-masked]

           (* our apologies if you receive multiple copies *)

                    ISADS 2001 CALL FOR PARTICIPATION

                  The Fifth International Symposium on
                    Autonomous Decentralized Systems

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

                     http://isads.utdallas.edu

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 four successful symposiums, the Fifth International Symposium on
Autonomous Decentralized Systems (ISADS)  will be held in Dallas, Texas,
USA during March 26-28, 2001. While ISADS 2001 will primarily focus on
advancements and innovation in the ADS concept, technologies and
applications related to the increasingly important topic of *Electronic
Commerce* are also included.

The symposium features 13 paper sessions and seven panel sessions, whose
titles are below.

In addition to the paper and panel sessions, the following events have
been organized.

   * Reception (March 26)
   * Banquet (March 27) 
   * A tour and dinner at the famous Southfork Ranch of Dallas (March 28). 
   * A plant tour of two telecommunication companies in the Dallas area, 
     Alcatel and Nortel (March 29).

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

                 http://isads.utdallas.edu

Important Deadlines:

   *March 1, 2001 - Deadline for early registration 
   *March 2, 2001, 5:00 p.m. central time - 
           Any reservation at the conference hotel 
           received after the cut-off date will be accepted based on 
           space availability 

Paper Sessions:

   *E-commerce Models and Protocols 
   *High Assurance Systems 
   *Fault Tolerance and Safety Critical Systems 
   *Architecture and Models for Distributed Systems 
   *E-commerce Technology and Architecture 
   *Distributed Object Management Systems 
   *Short Papers: Distributed Object Management and Control 
   *Multiagent systems 
   *Middleware Technologies 
   *Agent Technology for E-commerce 
   *Self Stabilizing Systems 
   *Secure Systems and Applications 
   *Modeling and Performance 

Panel Sessions:

   *XML and E-Business Frameworks 
   *Agent-Based Electronic Commerce: Opportunities and Challenges 
   *Embedded Systems 
   *Mobile Computing and Communication 
   *Robotics for Education and Entertainment 
   *Security for the Web and E-Commerce Systems 
   *Plenary closing panel: Future of Autonomous Decentralized Systems 

Date: Wed, 24 Jan 2001 16:10:26 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Working Group Last Call and naming fordraft-ietf-trade-drt-requirements-01.txt
To: Renato Iannella <[email-masked]>
Cc: [email-masked]

Thank you for your suggestions and links to the DRM resources.

Renato Iannella wrote:
> 
> Use of "rights" implies intellectual/legal/social behaviours, such
> as copyright, moral rights etc. The modelling, requirements, languages
> for this type of right is significant (see [1] to [11]).
> 

I think that "rights" are often used for "access rights" as well as "IP rights". 
Example of such usage are found in RFC2086, 2820, and draft-ietf-ldapext-acl-model-06.txt

I also think that most of "tickets" are a kind of "access rights" for a physical
resources, and those concept are similar. I, therefore, think that the usage of 
"rights" in the draft is common, too.
I believes that what this draft describes is nothing more than "trading aspect of rights".

> This leads me to the point in "Section 7. Q & A"
> 
> ----
>   - Is it possible to ensure digital "property" rights?
> 
>   Yes, since digital property rights can be considered as a kind of
>   electronic-right. RTS, however, would need to be extended by adding
>   some protected rendering system that would regenerate the original
>   digital contents securely.
> -----
> 
> I would say they answer is "No". You cannot _ensure_ this.
> (see the references below)

Right. I would like to change it to:

  - Is it possible to support "digital property right?"

  Digital property right can be considered as a kind of electronic-right and
  it can be traded using RTS.  However, some protected rendering system would 
  be required to regenerate the digital contents securely in order to support 
  digital property rights. These requirements are out of scope of RTS.

Regards,

Ko

Content-return: allowed
Date: Mon, 15 Jan 2001 13:19:12 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: FW: Comment & Q: ECML 1.1 Internet draft
To: "[email-masked]'" <[email-masked]>

This is a comment on the v1.1 draft but is relevant to v2 of ECML...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 24, 2000 12:48 PM
To: Donald.Eastlake
Subject: Comment & Q: ECML 1.1 Internet draft

...

I read through the ECML 1.1 internet draft and
noticed that it is prepared for mobile transactions 
by providing in the Ecom_Payment_Card_Protocol 
field the initial list tokens like 'simcard' and 'phoneid'. 

If I understand correctly, the explanation of
these tokens refer to the use of of some, probably 
operator-specific system, either for billing via phone
bill or by using some SIM toolkit-based solutions.
So, unlike other tokens, these tokens do not refer to a
specific protocol. 

IMHO, this could be problematic in cases where the merchant
and wallet user are not using the services of the same
operator for payments. The token 'simcard' for example 
may then mean different things on the wallet side and on
the merchant side. 

...

Best Regards,
Mia

Mia Lahteenmaki
[email-masked]
(Nokia Research Center)
mobile +358 40 7431965
fax +358 9 4376 6139 

Note: These comments and views are solely mine and not my employer's

Date: Mon, 15 Jan 2001 11:59:44 +0800
From: Xu WANG <[email-masked]>
Subject: A minor point on iotp spec.
To: [email-masked]
Organization: Dept. of Comp. Sci., Hong Kong Univ. of Sci.&Tech.
Full-name: Wang Xu

This is a multi-part message in MIME format.

--Boundary_(ID_uwKKhepg9cu+1y1gdM2VoA)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Hi, dear all

On page 149 of the iotp spec., it says,

"  ATTRIBUTE ELEMENT

   There must be one and only one Attribute Element that contains a Type

   attribute with a value of IOTP Signature Type and with content set to

   either: OfferResponse, PaymentResponse, DeliveryResponse,
   AuthenticationRequest, AuthenticationResponse, PingRequest or
   PingResponse; depending on the type of the signature.
"

I think we should also need add some other values(AuthenticationStatus,
InquiryRequest and InquiryResponse), and make corresponding change to
page 81 and 261.

What do you think, or is there anything I misunderstood the spec.

Regards,

WANG Xu

--Boundary_(ID_uwKKhepg9cu+1y1gdM2VoA)
Content-type: text/x-vcard; name=xuwang.vcf; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=xuwang.vcf
Content-description: Card for Xu WANG

begin:vcard 
n:WANG;Xu
tel;fax:+852-2358-1477
tel;work:+852-2358-6992
x-mozilla-html:FALSE
org:Dept. of Computer Science;Hong Kong Univ. of Science&Technoloy
version:2.1
email;internet:[email-masked]
title:Research Associate
adr;quoted-printable:;;Clear Water Bay Road 660, Kowloon=0D=0A;Hong Kong;;;
fn:Xu WANG
end:vcard

--Boundary_(ID_uwKKhepg9cu+1y1gdM2VoA)--

Date: Fri, 12 Jan 2001 16:22:55 +0100
From: "Silke Holtmanns (EED)" <[email-masked]>
Subject: RE: Another short comment on ECML
To: "[email-masked]'" <[email-masked]>

Hello,

from my personal experience I think 22 should be enough 
for most of the names.

Greetings Silke

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Friday, January 12, 2001 3:57 PM
To: Silke Holtmanns (EED)
Cc: [email-masked]'
Subject: Re: Another short comment on ECML

Hi,

Is there any particular length you would recommend as the minimum any
general ECML implementation should be able to handle?

Thanks,
Donald

From:  "Silke Holtmanns (EED)" <[email-masked]>
Date:  Fri, 12 Jan 2001 10:43:22 +0100
To:  "[email-masked]'" <[email-masked]>
Message-id:  
	     <[email-masked]>
Content-type:  text/plain

>Hello,
>
>maybe a comment on the length of the "last name fields".
>
>In Europe double names or long names are very common!
>So 15 characters is very short. 
>
>Greetings Silke

Date: Fri, 12 Jan 2001 09:56:40 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Another short comment on ECML
To: "Silke Holtmanns (EED)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Hi,

Is there any particular length you would recommend as the minimum any
general ECML implementation should be able to handle?

Thanks,
Donald

From:  "Silke Holtmanns (EED)" <[email-masked]>
Date:  Fri, 12 Jan 2001 10:43:22 +0100
To:  "[email-masked]'" <[email-masked]>
Message-id:  
	     <[email-masked]>
Content-type:  text/plain

>Hello,
>
>maybe a comment on the length of the "last name fields".
>
>In Europe double names or long names are very common!
>So 15 characters is very short. 
>
>Greetings Silke

Date: Fri, 12 Jan 2001 22:50:54 +0900
From: TERAMURA Takeshi <[email-masked]>
Subject: Re: IOTP Implementation
To: [email-masked]
Cc: [email-masked]

Hello,

> Since I read the news about the implementation a few questions
> turned up:
> What has Hitachi implemented? (only some components or some block)

Hitachi implemented the following modules:
- IOTP application core:
  - Consumer Client
  - Merchant Server
  - Payment Handler Server
  - Delivery Handler Server
- IOTP payment bridge:
  - SET bridge( for client / server )
  - SECE bridge( for client / server )
    * SECE(Secure Electronic Commerce Environment) is the specification
      including debit protocol.
  - Mondex bridge( for client / server )

> (If you can say)
> It would be good for the "wireless people" to know the problems that occur, maybe we
> can then avoid some of them ..... 

I think client size and performance will be issues when mobile phone 
is used as platform. Because the computer resources(CPU, memory) of 
the mobile phone may be less powerful than PC. 

Regards

---
Takeshi Teramura
5th department
Systems development laboratory
Hitachi, Ltd.

Date: Fri, 12 Jan 2001 10:43:22 +0100
From: "Silke Holtmanns (EED)" <[email-masked]>
Subject: Another short comment on ECML
To: "[email-masked]'" <[email-masked]>

Hello,

maybe a comment on the length of the "last name fields".

In Europe double names or long names are very common!
So 15 characters is very short. 

Greetings Silke

Date: Thu, 11 Jan 2001 16:19:07 +1000
From: Renato Iannella <[email-masked]>
Subject: Re: Working Group Last Call and naming for draft-ietf-trade-drt-requirements-01.txt
To: [email-masked]
Cc: "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]

--On 3/1/01 4:24 PM -0500 Donald E. Eastlake 3rd wrote:

> As far as I know, the only point
> in controversy is the name of the things for which trading
> requirements are given.  Suggestions have included digital rights,
> electronic rights, trading right, entitlement, coupon, and certificate
> as well as generic rights.  But most suggestions have some particular
> problem as well.  Unless there is a consensus to change, as show by
> discussion on this mailing list, we will stick with the current
> terminology.

I still believe that using "rights" is misleading for this document.
A more appropriate term would be "voucher". (In fact, you should be
able to do a string find/replace through-out the whole document.)

All the examples in the document are focussed on the value of
an "exchange ticket" for an *arbitrary* good or service.

Use of "rights" implies intellectual/legal/social behaviours, such
as copyright, moral rights etc. The modelling, requirements, languages
for this type of right is significant (see [1] to [11]).

This leads me to the point in "Section 7. Q & A"

----
  - Is it possible to ensure digital "property" rights?

  Yes, since digital property rights can be considered as a kind of
  electronic-right. RTS, however, would need to be extended by adding
  some protected rendering system that would regenerate the original
  digital contents securely.
-----

I would say they answer is "No". You cannot _ensure_ this.
(see the references below)

Cheers...Renato                       <http://purl.net/net/renato>
Chief Scientist, IPR Systems Pty Ltd       <http://iprsystems.com>
W3C Workshop on Digital Rights <http://w3.org/2000/11/w3c-drm-cfp>

DRM Modelling
[1] http://www.indecs.org/
[2] http://www.propagate.net/
[3] http://www.openebook.org/framework/

DRM Background Papers
[4] http://www.oasis-open.org/cover/ericksonRT19990624.pdf
[5] http://www.iprsystems.com/whitepapers/Papers/Rights_Management.pdf
[6] http://www.cisp.org/imp/february_2000/02_00gladney.htm
[7] http://mjosa.stanford.edu/~roscheis/IMA/index.html

DRM Requirements
[8] http://www.publishers.org/home/drm.pdf
[9] http://www.cselt.it/leonardo/mpeg/public/mpeg-4_ipmp.zip

DRM Languages
[10] http:://odrl.net
[11] http://www.xrml.org

Content-return: allowed
Date: Wed, 10 Jan 2001 14:48:44 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: ECML Comments
To: "[email-masked]'" <[email-masked]>

Below were some comments on the ECML v1 spec forwarded with permission as
input on the ECML v2 requirements document.

Thanks,
Donald

FName:           Ruediger Jungbeck
Company:         RSJ Software GmbH
Telephone:       +49 89 894142-11
FAX:             +49 89 894142-80
Email:           [email-masked]
Date:            07 Dec 2000
Time:            05:46:19

Comments:

Your specification seems not to recognize international markets.

Your email addresses are too short.
Your phone numbers are too short.
No fields if customer is a company.
No provisions for handling of option lists (for country and province).

There is not much acceptance in the market for your standard.
It is easier to fill out your  Feedback form (which has fields like Company,
Name etc my browser (IE5.5) knows about from other sites) than your order
form.

Wouldn't it be better to have only a translation specification in the HTML
form (ie hidden fields telling the ECML aware browser (-extension) how to
fill out an form, than renaming the fields themself).

Regards

Ruediger Jungbeck
RSJ Software GmbH

Date: Tue, 09 Jan 2001 12:47:25 +0100
From: "Silke Holtmanns (EED)" <[email-masked]>
Subject: IOTP Implementation
To: "[email-masked]'" <[email-masked]>

Hello,

the Ecomeg group (Electronic expert group) in the 
WAP forum is in the moment developing a EFI Payment Class. 
This payment class shall take care of  the payment process as a whole.
It shall support a wide range of payment protocols.

This payment class has some strong similarities to IOTP.
It is structured differently, but on the other hand contains 
similar information (brand, payment protocol,..). I believe it
makes sense to make the EFI payment class very similar
to IOTP (or at least parts of it) to support the convergence between the 
"wireless wap world" and the internet.

Since I read the news about the implementation a few questions
turned up:
What has Hitachi implemented? (only some components or some block)
(If you can say)
It would be good for the "wireless people" to know the problems that occur, maybe we
can then avoid some of them ..... 

Greetings Silke 

Silke Holtmanns
Ericsson Eurolab Deutschland GmbH
Ericsson Allee 1
52134 Aachen
Tel. ++49 2407 575 7751
Fax ++49 2407 575 400
[email-masked]

Date: Fri, 05 Jan 2001 13:40:44 +0900
From: TERAMURA Takeshi <[email-masked]>
Subject: Hitachi's implementation of IOTP
To: [email-masked]

Dear Folks:

Don asked us who should be contacted when people have 
questions about Hitachi's implementations of IOTP including 
the SMILE project.

When you have questions about Hitachi's implementations, 
please contact me.

Best Regards

---
Takeshi Teramura  [email-masked]
Researcher
5th department, Systems Development Laboratory 
Hitachi, Ltd.

Date: Wed, 03 Jan 2001 16:24:52 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Working Group Last Call and naming for draft-ietf-trade-drt-requirements-01.txt
To: [email-masked]
Cc: [email-masked]

This is a working group last call announcement for the document
currently titled "Requirements for Generic Rights Trading".  The Last
Call is to run through January 22th.  As far as I know, the only point
in controversy is the name of the things for which trading
requirements are given.  Suggestions have included digital rights,
electronic rights, trading right, entitlement, coupon, and certificate
as well as generic rights.  But most suggestions have some particular
problem as well.  Unless there is a consensus to change, as show by
discussion on this mailing list, we will stick with the current
terminology.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Tue, 02 Jan 2001 08:57:53 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: FW: Draft minutes of trade IETF San Diego
To: Ko Fujimura <[email-masked]>
Cc: [email-masked]

Corrected minutes are available at
<ftp://ftp.pothole.com/pub/ietf-trade/IETF-SanDiego/minutes.txt> and
will be submitted, along with the slides, for the proceedings in the
next few days.

Thanks,
Donald

From:  Ko Fujimura <[email-masked]>
Date:  Wed, 20 Dec 2000 20:48:37 +0900
To:  [email-masked]
Cc:  [email-masked]
Message-id:  <[email-masked]>

>Hi Walter and Donald,
>
>Thank you very much for the minutes. I have a few comments:
>
>Eastlake III Donald-LDE008 wrote:
>> 
>> Minutes of the Internet Open Trading Protocol Working Group (trade)
>> 
>> Wednesday, December 13 at 1300-1500
>> =====================================
>> 
>> CHAIR: Donald Eastlake 3rd [email-masked]
>> Minutes: Walter Houser [email-masked]
>...
>> 7. Digital Rights Requirements - also known as Requirement for Generic
>> Payments Rights - presentation by Ko Fujimura.
>
>The title was "Requirements for Generic Rights Trading"
> 
>> RTS is an infrastructure to circulate diverse types of digitally
>> represented rights. RTS is enables digital versions of coupons and
>> tickets. We need to prevent copying.  RTS should allow sharing between
>> several issuers. There are five requirements:
>> 
>> -       Prevent alternation
>> -       Provide non-repudiation,
>> -       Provide idempotency (one and only one)
>> -       Prevent reproduction
>> -       Prevent duplicate redemption.
>> 
>> Fujimura presented a Chart for Positioning of RTS in trading area shows
>> the relationship of RTS with respect to IOTP. Hole observes that one needs
>> to trust the coupon. Fujimura replied that trust of the coupon is the
>> result of the issuer, which can be handed around by untrusted bodies. 
>
>Yes, but more correctly, I replied that:
>
>"trust of the coupon is the result of the issuer and the RTS. The issuer is
>responsible for the contents of the right and the RTS is responsible
>for preventing copy. In other words, if there is trust in the issuer and 
>the RTS, trust of the holder who transfers or redeems the coupon is not 
>required."
>
>> The RTS object is an XML object, which would be defined by the WG.
>
>I think it means that:
>
>"The objects transported by the RTS is an XML Components which would be defined 
>by the WG."
> 
>> Hole observed that the definition of the data representation is distinct from
>> the transport issues. The latter may be appropriate for the WG, but they
>> are nontrivial.
>>
>> The working group suggested several terms to use in lieu of digital rights
>> or electronic rights, such as trading right, entitlement, coupon, and
>> certificate. There was concern about confusion of the term rights with
>> access control rights. Entitlement was thought cumbersome. Coupon
>> communicates too much of a limitation. Certificate has a specific meaning
>> with respect to network security.
>...
>
>Please add:
>
>"It was agreed to decide the term using the mailing list."
>
>Thanks.
>
>Ko

Date: Tue, 02 Jan 2001 08:53:53 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Generic Right Trading (was Fw: FW: Draft minutes of trade IETF San Diego )
To: Raghuram Rajah <[email-masked]>
Cc: [email-masked]

Hi Raghu,

As an IETF Working Group, the mailing list is the primary forum for
discussion and agreement.  I'd welcome you posting material on what
your group has developed.

Since we plan to put through the Requirements for Generic Rights
Trading document
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-01.txt>
as a final informational document soon, it would be particularly
helpful to get your comments on that requirements document within the
next two or three weeks...

Thanks,
Donald

From:  Raghuram Rajah <[email-masked]>
Date:  Thu, 21 Dec 2000 11:06:52 -0500
To:  [email-masked]
Message-id:  <[email-masked]>

>Yes, I did intend to send it to the group and I thought I did too. I =
>am surprised it was sent only to you. Sorry about the confusion. Than=
>ks for getting me upto speed. =20
>
>Going forward, do we plan to use the mailing list at all, or would we=
> want to discuss in the f2f only?
>
>Will send a write-up on the thoughts that we had developed for repres=
>enting rights (we were calling it coupons, though I know it is a mis-=
>leading as well) soon to the group (atleast this time ;-) ).
>
>Raghu.

>Sent: Thursday, December 21, 2000 6:58 AM
>To: Raghuram Rajah
>Cc: Donald E. Eastlake 3rd; [email-masked]
>Subject: Re: FW: Draft minutes of trade IETF San Diego

>Hi Raghu,
>
>> Hi Ko / Walter / Donald / all,
>
>I think that your mail is intended to sent the mailing list but sent =
>only to me.
>Anyway, I would like to answer it.
>
>> I have been a part of this group for over a month now and haven't s=
>een any discussion on the rights requirements or the RTS in general. =
>Didn't find a whole lot in the archives either.
>> Is there a private group working on these requirements and the RTS =
>framework?
>
>There was. But, about one year ago I closed it, since it is not activ=
>e. So, any discussion
>should be done the trade mailing list or face-to-face meeting now. We=
> haven't actively
>discussed using the mailing list. But, we had 5 face-to-face meeting =
>since the 45th IETF Oslo meeting. I think it enough for discussing re=
>quirements.
>
>> The reason I ask is, I have been leading a development of a similar=
> system and have been battling the very same requirements in the cont=
>ext of embedded devices with limi=3D
>ted computing power. We have made some progress in addressing these r=
>equirements and have come up with a generic framework. Though the fra=
>mework and the model needs more work, I guess we are headed in the ri=
>ght direction.
>
>Thank you. But, I think the next work item is to develop draft for Ri=
>ghts Component, i.e., XML representation of rights. I'm not sure if f=
>ramework and the model should be specified.
>
>> We would want to present our model, for review by the WG to develop=
> the RTS I-D, potentially.
>
>Meeting agenda is chair's decision, but I think that Don will allow y=
>ou to present it.
>
>> Or if the development of the framework or model is already underway=
> by the WG, we would like to contribute to the same. Also, we could a=
>dopt the early releases and can=3D
>act as a test bed.
>
>Any contributions are welcome! I hope you actively join the discussio=
>n.
>
>> Please let me know if a private group is involved in developing the=
>se standards? And if so, how can I join that group? How does the work=
>ing group operate in developing these drafts?
>> Please advise.
>
>Send the trade mailing list what you are thinking. Do not hesitate to=
> do so.
>
>Regards,
>
>Ko
>
>P.S. My I ask your company? Just curious.