Current Meeting Report
Slides


2.1.5 Internet Open Trading Protocol (trade)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/30/2002

Chair(s):
Donald Eastlake 3rd <Donald.Eastlake@motorola.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
P. Faltstrom <paf@cisco.com>
Applications Area Advisor:
P. Faltstrom <paf@cisco.com>
Mailing Lists:
General Discussion: ietf-trade@lists.eListX.com
To Subscribe: ietf-trade-request@lists.eListX.com
In Body: (un)subscribe
Archive: http://lists.eListX.com/archives/ietf-trade
Description of Working Group:
The Internet Open Trading Protocol is 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 can encapsulate and support payment systems such as SET, Mondex, secure channel card payment, 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 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.

Goals and Milestones:
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)
Internet-Drafts:
  • - draft-ietf-trade-drt-requirements-03.txt
  • - draft-ietf-trade-iotp-v1.0-papi-05.txt
  • - draft-ietf-trade-iotp-v1.0-set-02.txt
  • - draft-ietf-trade-ecml2-req-05.txt
  • - draft-ietf-trade-voucher-lang-03.txt
  • - draft-ietf-trade-ecml2-spec-03.txt
  • - draft-ietf-trade-iotp2-req-02.txt
  • - draft-ietf-trade-iotp-v1-errata-01.txt
  • - draft-ietf-trade-voucher-vtsapi-02.txt
  • Request For Comments:
    RFCStatusTitle
    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

    Current Meeting Report

    54th IETF Yokohama, Japan
    July 15, 2002 13:00-15:00
    Internet Open Trading Protocol WG

    Minutes reported by Makoto Iguchi

    Acting Chair: Joel Halpern
    Chair: Donald Eastlake


    1. Agenda Bashing
    No changes.


    2. Document Status
    Joel Halpern reported the document status as follows:

    o The document currently in RFC editor queue is as follows:
    - Internet Open Trade Protocol Version 2 Requirement
    [draft-ietf-trade-iotp2-req-01.txt]

    o The document approved by IESG is as follows:
    - Requirements for Generic Voucher Trading
    [draft-ietf-trade-drt-requirements-03.txt]
    (The document is returned for wording improvement)

    o The documents with Area Director/IESG is as follows:
    - SET supplement for the v1.0 Internet Open Trading Protocol (IOTP)
    [draft-ietf-trade-iotp-v1.0-set-02.txt]
    - Payment API for v1.0 Internet Open Trading Protocol
    [draft-ietf-trade-iotp-v1.0-papi-05.txt]
    - Electronic Commerce Modeling Language (ECML) Version 2 Requirements
    [draft-ietf-trade-ecml2-req-05.txt]
    - Internet Open Trading Protocol (IOTP) Version 1 Errata
    [draft-ietf-trade-iotp-v1-errata-01.txt]


    3. XML Voucher Updates
    Ko Fujimura presented the updates made to the document "XML Voucher: Generic
    Voucher Language" [draft-ietf-trade-voucher-lang-03.txt]. The major updates were
    as follows:

    1) changed the targetNamespace format from "http://www.ietf.org/rfc/rfcXXXX" to
    "urn:ietf:params:xml:schema:vts-lang" so as to comply with the recent draft: The
    IETF XML Registry [draft-mealling-iana-xmlns-registry-03.txt]

    2) added IANA consideration section 7 for calling IANA to register the schema.

    One open issue, whether to add ID attribute to the <Voucher> element, was
    addressed. Ko proposed not to add the ID attribute, but to generate the ID on
    the fly instead. His proposal was put under the discussion and no objection was
    made; The ID attribute would not be included in the <Voucher> element if Donald
    accepts the idea.

    Ko also reported on recent discussions with related consortiums, namely IrFM
    (Infrared Financial Messaging) in IrDA, IXRetail (Retail Enterprise Data in XML
    Initiative) in ARTS (Association for Retail Technology Standards), WAP Forum
    (now Open Mobile Alliance), and MeT (Mobile electronic Transactions). He
    emphasized the consistency of the VTS specifications to other specifications
    developed by these consortiums (See Slides).


    4. VTS-API Updates
    Ko introduces the update made to the document "Voucher Trading System
    Application Programming Interface (VTS-API)"
    [draft-ietf-trade-voucher-vtsapi-02.txt].
    The only update made to the document was the addition of a new exception
    "FeatureNotAvailableException," which is to be returned when an unsupported
    method is invoked.
    There was no opposition to the update.


    5. Voucher Implementation Demo
    Makoto Iguchi presented how VTS-APIs are to be invoked by demonstrating the
    actual voucher issuing/collecting applications and voucher wallet application.
    In the demo, he showed that the same APIs can be used for handling vouchers
    regardless of whether the voucher storage is implemented with a smartcard or an
    account (i.e. a database on a server).


    6. Voucher Discussion
    A straw poll was taken as to whether the XML Voucher and the VTS-API proposals
    are ready to advance to Proposed Standard. The consensus was to proceed them to
    the Proposed Standard. They are to be in WG last call by August 2.


    7. ECML V2 Specification:
    Joel presented the updates made to the document "Electronic Commerce Modeling
    Language (ECML) Version 2 Specification"
    [draft-ietf-trade-ecml2-spec-03.txt]. The updates were as follows:

    1)Added several fields:
    - the merchant to processor field
    - Ecom_Wallet_Location field
    - Ecom_User_Certificate_URL fields
    - Ecom_Device fields
    - Ecom_Loyalty_Card fields
    - Ecom_UserData fields

    2)Added an attribute:
    - the "Mode" attribute

    Joel also addressed that there was an controversy in the format
    Ecom_UserData_Country in the mailing list. The options presented include:

    - use country code specified in ISO 3166
    - use country code specified in ISO 3166 with escape value and _Country_Other
    field
    - introduce a new registry

    No tentative decision was made at the meeting.


    8. Future Actions/Meetings:
    The author/editors volunteers for the document "SCCD using ECML Specification"
    and "IOTP version 2 Specification" were asked, and was agreed to be discussed in
    the mailing list.
    Joel proposed to have the next trade WG meeting at Atlanta.



    Slides

    Agenda
    XML Voucher and VTS-API