NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Donald Eastlake 3rd <dee3@torque.pothole.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Editor(s):
Surendra Reddy <skreddy@us.oracle.com>
Mailing Lists:
General Discussion:ietf-trade@lists.eListX.com
To Subscribe: ietf-trade-request@lists.eListX.com
In Body: (un)subscribe
Archive: http://www.eListX.com/archives/ietf-trade
Description of Working Group:
The Internet Open Trading Protocol provides 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 will be able to encapsulate and support payment systems such as SET, Mondex, CyberCash's CyberCoin, DigiCash's e-cash, 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 Internet Open Trading Protocol (IOTP) working group will (1) determine requirements and document scenarios for IOTP message transport and for IOTP version 2 specification, (2) document interoperability experience with IOTP version 1 (which will have been published as Informational), and (3) develop the specification for IOTP transport and IOTP version 2.
Selection of items for inclusion in version 2 is expected to be from the following and others suggested by the Working Group:
- Dynamic Definition of Trading Sequences - Multiple Protocol Options - Offer Request Block - Public Key Signatures (v1.0 uses secret key signatures) - Signatures on the Delivery Response - Improved Problem Resolution (extend to cover presentation of signed receipt to customer support party, etc.) - Selection of Additional Options - OTP Architecture (informational development of standard interfaces to software components).
The following are out of scope for version 2:
- server to server messages (except as messages needed for client to server communications may also be useful for server to server communications) - legal or regulatory issues surrounding the implementation of the protocol or information systems using it.
Goals and Milestones:
Jul 98 |
|
Submit IOTP v1.0 to the IESG to consider publication as an Informational RFC. |
Oct 98 |
|
Submit Internet-Draft of Open Trading Protocol requirements and scenarios |
Oct 98 |
|
Submit IOTP transport requirements Internet Draft |
Dec 98 |
|
Submit Internet-Draft on IOTP v1.0 interoperability experience |
Jan 99 |
|
Submit Internet-Draft on IOTP transport requirements to IESG for publication as an Informational RFC. |
Jan 99 |
|
Submit Internet-Draft on IOTP v1.0 interoperability experience to IESG for publication as an Informational RFC. |
Feb 99 |
|
Submit Internet-Draft of IOTP v2.0 specification |
Feb 99 |
|
Submit Internet-Draft of IOTP transport specification |
May 99 |
|
Submit IOTP transport specification I-D to IESG for consideration as a Proposed Standard. |
Jun 99 |
|
Submit IOTP v2.0 specification I-D to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Internet Open Trading Protocol (IOTP) HTTP Supplement
· HTTP MIME Type Handler Detection
· Requirements for XML Messaging Version 1.0 Release 00
· Requirements for Digital-Right Trading
· Architecture and Payment API for Internet Open Trading Protocol (IOTP)
· SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP)
Request For Comments:
RFC |
Status |
Title |
RFC2803 |
Digest Values for DOM (DOMHASH) | |
RFC2801 |
Internet Open Trading Protocol - IOTP Version 1.0 | |
RFC2802 |
Digital Signatures for the 1.0 Internet Open Trading Protocol (IOTP) | |
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 forumswere 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.
None received.