Subject: Re: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo

From: Dave Birch <[email-masked]>
Date: Tue, 17 Nov 1998 19:12:48 +0000

David Burdett said

>1)	Packaged Content. There is a need for Packaged Content to contain
>multiple items of data e.g. in the Pay Receipt Component, to support
>encapsulation of SET messages. To support this propose the following
>amendment to the Packaged Content element (see section 3.7.1):

Wouldn't it greatly simplify IOTP and speed the time to market if we got 
rid of SET altogether? See for example

http://www.americanbanker.com/cgi-bin/print_tagstory?981117DIGI002

Regards,
Dave Birch.

=== mailto:[email-masked] ===== http://www.hyperion.co.uk/ ===

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

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 17 Nov 1998 15:32:59 -0500

IOTP is not dependent on SET but SET is an interesting test case for a
payment system to be carried within IOTP.  Whatever you think of SET,
other payment systems might have similar requirements.  And some IOTP
implementors specifically plan to include SET among the payment sytems
they are going to be using with IOTP which is why we have a specific
subgroup looking into that.

I think the right way to look at this is that some uses of IOTP will
need to send multiple items where there is currently a provision for a
single Packaged Content.  People designing those uses can, of course,
figure out their own way to include multiple items within a Packaged
Content.  And if they need to include dozens or hundreds of items,
they probably should figure out some technique that is suitable to the
data they are packaging.  But it seeme likely that it will be common
enough for their to be a few separate items to be packaged that a
standard technique will save people the trouble of re-inventing
combined packaging ever time such a requirement appears.  The fact
that the first couple of times the requirement has come up were with
regard to SET does not mean it won't come up elsewhere.

Thanks,
Donald

From:  Dave Birch <[email-masked]>
Date:  Tue, 17 Nov 1998 19:12:48 +0000
To:  David Burdett <[email-masked]>,
            "[email-masked]'" <[email-masked]>
Message-ID:  <[email-masked]>

---

From: Tom Arnold <[email-masked]>
Date: Sun, 22 Nov 1998 16:54:18 -0800

>rid of SET altogether? See for example

If time to market (IE., doing anything over the next 5 years) is important,
than moving ALL SET work to a later version is a must. Even VISA has backed
off of SET in a VERY big way.  

Millions of SSL protected transactions are being run each month with an
estimated 30% monthly growth rate. In the US, not a single SET transaction
has moved. SSL and SET are like VHS and Betamax. VHS won the day!

> [snip]

Tom Arnold
Vice President of Engineering
CyberSource Corporation
[email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 23 Nov 1998 10:06:32 -0500

Hi,

From:  Tom Arnold <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Sun, 22 Nov 1998 16:54:18 -0800
To:  Dave Birch <[email-masked]>
Cc:  "[email-masked]'" <[email-masked]>
In-Reply-To:  <[email-masked]>

>>rid of SET altogether? See for example

I don't know how many times I have to say it but IOTP does not depend
on SET or on any other particular payment protocol.  One way to view
SET is simply as a stress test for IOTP's payment system handling
facilities.  If a few relatively minor tweaks to IOTP such as the one
mentioned above enable IOTP to easily encapsulate a wider variety of
payment protocols, including SET, this seems like a good thing.

>off of SET in a VERY big way.  

I do not agree.  I expect the IOTP V1.0 specification to be ready for
WG last call within a few weeks.  I think the separate SET/IOTP
supplement is nearing completion, although it is not in IETF format
yet, but that is beside the point.  It is not on the critical path
for the specification document since IOTP does not depend on SET.

Hitcahi people indicated at the Tokyo meeting that it and Fujitsu and
NTT, along with a number of banks, cards, and merchants, will be
implementing a pilot system on the Internet with IOTP that includes
multiple payment systems one of which is SET.  It seems to me better
for this to be accomodated than for them to have to do something
proprietary.  And I would point out that it has been Hitachi personel
who have been doing the vast bulk of the work on the IOTP/SET
supplement.

>has moved. SSL and SET are like VHS and Betamax. VHS won the day!

I could discuss the above statements, but it would be pointless since
IOTP does not depend on SET.

>Vice President of Engineering

Since IOTP does not depend on SET, I suggest that arguements as to
exactly how alive or dead SET is in the US or other parts of the world
are not directly relevant to this working group.

The aim thus for for V1.0 has been a stand alone specification
document, a supplemental Architecture/API document, one or more
payment systems supplements (of which SET and SCCD (Secure Channel
Credit/Debit) have seen progress), and one or more transport
supplements (of which an HTTP draft exists).  If anyone wants to
suggest a different suite of documents, we can discuss that.  But as
long as there are volunteers within the working group to do a
supplement for a particular payment system or transport, it is not
clear to me why they shouldn't go ahead.

Thanks,
Donald