Last Modified: 2003-01-20
The working group will document interoperability experience with IOTP version 1 (which has been published as an Informational RFC) and develop the requirements and specifications for IOTP version 2. Version 2 will make use of an independent Messaging Layer and utilize standard XML Digital Signatures. Selection of other items for inclusion in version requirements 2 is to be from the following:
- Dynamic Definition of Trading Sequences
- Offer Request Block
- Improved Problem Resolution (extend to cover presentation of signed receipt to customer support party, etc.) - Ability to indicate and handle a payment protocol not tunneled through IOTP
- Support for wallet servers
- Repeated/ongoing payments - Server to Server messages
- The ability to add both fields and attributes to trading blocks
- Collaboration with other protocols such as ECML.
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.
- design of an XML Messaging Layer
The working group will specify a Secure Channel Credit Debit syntax that can be used for financial card payments in connection with IOTP.
The working group will specify requirements and specifications for Generic Rights Trading.
The working group will specify requirements for and then a syntax and processing model of ECML (Electronic Commerce Modeling Language) V2.
|Done||Submit SET Supplement to IESG for publication as Informational|
|Done||Submit Architecture and Payment API to IESG forInformational|
|Done||Submit Generic Rights Trading Requirements for Informational|
|Done||Submit I-D on IOTP V2.0 Requirements|
|Done||Submit I-D on Generic Right Trading Specification|
|Done||Submit ECML V2.0 Requirements to IESG (Informational)|
|Done||Submit IOTP V2.0 Requirements (Informational)|
|MAR 02||Submit I-D on Secure Channel Credit/Debit ECML V2.0 Specification|
|MAY 02||Submit Generic Right Trading Specification (Proposed Standard)|
|JUL 02||Submit Secure Channel Credit/Debit ECML V2.0 Specification (Proposed Standard).|
|DEC 02||Submit I-D on IOTP V2.0 Specification|
|JUL 03||Submit IOTP V2.0 Specification (Proposed Standard)|
|RFC2803||I||Digest Values for DOM (DOMHASH)|
|RFC2802||I||Digital Signatures for the 1.0 Internet Open Trading Protocol (IOTP)|
|RFC2801||I||Internet Open Trading Protocol - IOTP Version 1.0|
|RFC2935||PS||Internet Open Trading Protocol (IOTP) HTTP Supplement|
|RFC2936||I||HTTP MIME Type Handler Detection|
|RFC3354||I||Internet Open Trading Protocol Version 2 Requirements|
Internet Open Trading Protocol (TRADE) Working Group Minutes for IETF Meeting 56, San Francsico, Califronia These minutes are reconstructed. There were no changes to the agenda as presented by Donald Eastlake, the chair. The three main areas of the WG are IOTP, ECML, and Voucher. Their status is as follows: In connection with the IOTP protocol, Version 1 and Requirements for Version 2 are out as Informational RFCs; however, a volunteer or volunteers are needed to start actual work on Version 2 drafts. A small document is needed to define IOTP tokens in connection with draft-ietf-trade-srv-higher-services-00.txt. If no one else volunteers, the chair will probably do it. ECML Version 2 requirements are out as RFC 3505. The specification has been submitted to the IESG for approval as a Proposed Standard. Voucher requirements are out as RFC 3506. The specification and an API have been submitted to the IESG for approval as Proposed Standard and Informational respectively. There was some discussion of the use of the SRV DNS resource record to locate IOTP services. Remaining work for the TRADE WG: - Complete work on draft-ietf-trade-srv-higher-services-00.txt and the to be produced companion IOTP draft. - Produce draft on SCCD (Secure Channel Credit Debit), a simple payment protocol that could be tunneled through IOTP and would probably be based on ECML syntax. - IOTP Version 2. Due to slower pace of work, it was agreed to generally request 1 hour slots for meetings at IETF meetings and to hold such a meeting at the next IETF meeting in Vienna, Austria.