NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Don Eastlake <dee3@torque.pothole.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Patrik Faltstrom <paf@swip.net>
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:
No Request For Comments
Minutes of IETF TRADE WG conference call meeting on 3 December 1998.
Attendance: Donald Eastlake, David Burdett, Steve Fabes, Michael
Harvey, Chris Smith, Jason Flick, Doug Taylor
(1) Document status
SCCD: Jonathan Sowler is expected to post a message to the list on when he will have a new version.
XML SIG: On general XML SIG, Donald Eastlake is talking with Richard Brown and Hiroshi Maruyama about making this a separate effort covering general XML canonicalization, hashing, and digital signatures.
IOTP v1.0 Protocol: Should be final soon. Donald Eastlake needs to recommend text on signatures and use of IANA Registration Facilities.
HTTP: Changes agreed in Tokyo will be reviewed in Orlando.
(2) draft-rfced-info-blinov-00.txt
Chris Smith had some comments and agreed to write them up and post them to the list. All we have been asked to do as a WG is see if there are any obvious problem with the document or conflicts with what we are doing.
(3) Version 2.0
Several people expressed a feeling that there should be some "still waters" after v1.0 for implementation and interoperability testing of v2.0. There was also continued agreement on the v2.0 document structure reviewed in Tokyo and already distributed on this list. Some of the proposed pieces of the v2.0 documentation might be extremely close to v1.0 because they cover parts that don't change much if at all. Would it be worth while publishing them as a v1.1 document or the like for ease of reference? There did not seem to be a clear consensus and this should be discussed on the list and/or in Orlando.
(4) HTML Form Field Names
The question was raised of whether this WG should consider standardizing or compiling information on common HTML Form Field Names for use in Internet commerce. These would be fields that might occur in forms during shopping and could include ship to address, name, etc. This information can also be transferred in IOTP via an Authentication transaction. The possibility of an field name that indicated the server spoke IOTP was raised. There are privacy implications as there are for Authenticate. In general, the reaction was favorable.
(5) Taxes....
Michael Harvey of the OECD was on the conference call but, as is the norm in IETF WG's, was representing himself, not making official statements on behalf of the OECD. The following are some summary exerpts of what he said in response to questions by others on the call.
The OECD is looking for the most efficient and unintrusive way it can to collect taxes on Internet commerce. The have started a two year study/planning effort and are tracking protocol development. But just popping out with "requirements" in two years and expecting them to suddenly be incorporated in protocols is not too likely to work. So some interaction with protocol development efforts during that time would be good.
Indirect taxes, such as income taxes, are not a problem until further into the future. Consumption taxes such as value added and sales taxes are a more near term problem.
To some extent it boils down to record keeping requirements and no system will be 100% effective.
The tax authorities tend to think about things in terms of three populations of transactions, consumer to business, large business to large business, and other business to business. There is generally little problem with transactions between large businesses as they are used to dealing with international taxation and record keeping requirements.
There doesn't seem to be any other protocol effort, besides IOTP, that has done any thinking about taxes except perhaps a little in the SET Consortium.
At one point someone suggested that there may be web sites in the future that give tax avoidance advice. The response was that there already are such sites.