Draft Adelaide Minutes

["Donald E. Eastlake 3rd" <[e-mail]>]

47th IETF Meeting, Adelaide Australia
TRADE WG
Wednesday, March 29th, 2000
[Notes by Andrew Drapp, edited by Donald Eastlake.]
AGENDA:
Agenda Bashing
Status of Documents
Implementation News
Digital Rights Trading
Charter update
Future Meetings

AGENDA BASHING
Don presented the Agenda and asked if anyone had anything to add.
Nobody had anything to add.

STATUS OF DOCUMENTS
The 3 main documents have been in the RFC editor's queue since last
November.
 draft-ietf-trade-iotp-v1.0-protocol-07
 draft-ietf-trade-iotp-v1.0-dsig-05
 draft-ietf-trade--hiroshi-dom-hash-03
One problem is because the size of the largest is 276 pages.
Currently the editor is on page 207.

2 documents revised recently and will be moved to WG last call status
very soon after a further minor revision.
 draft-ietf-trade-iotp-http-04
 draft-ietf-trade-mime-detector-02

SET and Payment API documents recently posted as drafts by Yoshiaki
Kawatsura:
 draft-ietf-trade-iotp-v1.0-set-00
 draft-ietf-trade-iotp-v1.0-papi-00
Kawatsura reports that Werner Hans of SIZ is the author of Payment
API, and he will be revising the document within the next month.  The
current SET document (00) is based on IOTP v0.99, and a new version
will be released a month after the new Payment API is released.  The
new document will include input from SETCo and the SMILE project.

SCCD draft not yet posted.

Digital Rights Trading (new work by Ko Fujimura) to be presented today.
 draft-ietf-trade-dtr-requirements-00

XML messaging (new work see charter discussion):
 draft-ietf-trade-xmlmsg-requirements-00
XML messaging is a generic form of communicating between various
partners, in a dynamic order based on IOTP's request/exchange/response
format.  If this should be continued within the trade WG will be
discussed later during the charter discussion.

Future documents:
No documents yet.
 IOTP v2.0
 ECML v2.0

Someone asked for more information on ECML, and Don explained that
ECML is a standardized method for identifying fields in HTML.  In the
simplest case, an ECML wallet would help to fill out forms
automatically.  ECML v1.0 is out as an informational RFC.

Someone else asked how ECML relates to P3P.  Don explained that P3P is
just =a schema, and used as a way of imputing privacy preferences.
ECML has a smaller area of focus.

The ECML consortium is working on a version v1.1.  Currently v1.0 and
v1.1 are a one-way protocols, and do not allow for merchant to
consumer type communications.

HTTP/HTTP
HTTP Supplement specifies the Application/IOTP MIME type, with /X-IOTP
for backwards compatibility.  Discussion on the IETF-Types mail list
indicates that an optional charset parameter should be added, and Done
plans on adding that shortly if there are no objections it will be
added.  There was a lot of discussion on IETF-Types if the MIME type
should be changed to Application/IOTP-XML.  Eventually new XML encoded
type will probably be changed to end in "-xml", but as of now, no
change is expected from Application/IOTP.

IMPLEMENTATION NEWS
Hitachi, et al, SMILE
Royal Bank of Canada
SIZ
CyberSource
Differential
Xenosys Corporation
PayByCheck.com
Brokat

SMILE- to go into In house trials in June, with full trials later.
RBC - Implemented v0.9 in its teller system, will do v1.0
SIZ - Unknown
...(note taker fell behind, sorry)...

DIGITAL RIGHTS TRADING
Presented by Ko Fujimura ([e-mail])
[Expect to post slides to the list soon.]

Ko Fujimura explained how Digital Rights (DR), a sort of Digital Claim
Ticket, or Digital Bearer Instrument can be exchanged or traded.
Rights in this case do not refer to IP rights, but instead the right
to claim goods or services.  A requirements document has been
released, but there have been few comments on it yet.

The relationship to IOTP is that a DR could be used as a payment
method (gift certificate, coupon, etc) or it could be used as a
deliverable (ticket), or a different role of Loyalty Handler could be
created to issue or collect Loyalty points.

Ko Fujimura plans on publishing the requirements document as an
informational RFC.  He plans to clarify the relationship with IOTP and
include any relevant comments from others.

Afterwards, he would to start work on a specification, and he needs
volunteers to help work on it.

Q&A (I'm sorry I don't know anyone's names)
Q: The name is a bit confusing with IP rights.
A: Agreed

Q: Could the system be generalized as a type of e-Cash.
A: It may be possible in the strictest sense of gift certificates or
frequent flyer miles.  But could be difficult for other types,
(percentage off, tickets, etc.)

Q: Can you make a backup of DRs, as you can with Digicash?
A: Depends on the DR type, and DR Trading System (DRTS) that is
implemented.  Basically, Merchants can design their own DRs (with
their own rules) that can be incorporated in a more generic DRTS.

Q: Could it be split up into more specific roles.  So, involved
parties could focus on the only area they are interested.  For
example, coupons and frequent flyer miles are an inherently different
type of item, with different companies being involved, with little
overlap.
A: It could be split up, but Fujimura at this point has not noticed
anybody else offering to write such specs or systems, so as long as he
is basically working on it by himself, he would prefer to keep it as
one item.

Q: Could you link or change rights from one type to another?
A: Don explains that this is very similar to an exchange type
transaction already supported in IOTP.

Q: What is the difference of a DR versus a currency.
A: There is not too much difference but there is some, as in tickets
(with a seat number or specific show, after which it becomes
worthless).

Q: Is there a loyalty component in ECML, such as for a membership
number?
A: No, none in version 1.0 or 1.1, but it could be included in version
2.0.


CHARTER UPDATE
New Charter submitted to Area Director after last IETF meeting, but has not
yet been approved.

Review of changes to charter:
Notes completion of IOTP v1.0, adjusted milestones, split IOTP into
v2.0 into XML messaging layer, and trading specific portions, add EXML
2.0 and Digital Trading requirements.

Multiple interested venues for XML messaging
- -Trade WG, EDIINT WG, ebXML, BLOCKS BoF, B2BXML BoF
Should XML messaging be included in TRADE WG, or moved to a different
location?
Should we change the charter and drop the XML messaging?  Consensus
in favor of dropping XML messaging from the TRADE WG.

A copy of the new proposed charter will be posted shortly?

FUTURE MEETINGS
Next IETF Meeting
Pittsburgh, Pennsylvania, USA.
July 31 - August 4