Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01G09JS@eListX.com>; Thu, 30 Mar 2000 06:31:21 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01G08JR@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 30 Mar 2000 06:31:21 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L03G08JP@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:31:20 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01G08JO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:31:20 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS800L0LG069O@eListX.com> for ietf-trade@lists.eListX.com; Thu, 30 Mar 2000 06:31:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id GAA10718; Thu, 30 Mar 2000 06:28:07 -0500 (EST) Date: Thu, 30 Mar 2000 06:28:07 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: Document changes Oct 99 - March 2000 In-reply-to: "Your message of Wed, 29 Mar 2000 09:11:59 +0100." <38E1BACF.D1EE84C9@hplb.hpl.hp.com> To: Russell Perry Cc: ietf-trade@lists.eListX.com Message-id: <200003301128.GAA10718@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp The draft-ietf-trade-iotp-v1.0-protocol-07.txt draft is the final draft for the V1.0 of IOTP and will be out as an RFC soon. The -papi- draft is a little out of date but is expected to be updated within a month. After than happens, the SET Supplement will be updated. Donald From: Russell Perry Date: Wed, 29 Mar 2000 09:11:59 +0100 To: ietf-trade@lists.eListX.com Message-id: <38E1BACF.D1EE84C9@hplb.hpl.hp.com> >Hi, > >I'm looking for some help to clarify some of the apparent discrepancies >between the following documents: >draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and >draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000). For example, >several element tags are not specified in the latter document. Is this >because both documents should be read together, or does it reflect the >evolution of the protocol? > >Also, am I right in assuming that the running footer of "*papi-00.txt" >(SET supplement...) is a typo, or is there a more sinister explanation >:) Thanks. > > >Regards, > >Russ. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01FP4IS@eListX.com>; Thu, 30 Mar 2000 06:24:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01FP4IR@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 30 Mar 2000 06:24:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L03FP3IP@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:24:39 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01FP3IO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:24:39 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS800L0IFP19O@eListX.com> for ietf-trade@lists.eListX.com; Thu, 30 Mar 2000 06:24:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id GAA10606; Thu, 30 Mar 2000 06:22:37 -0500 (EST) Date: Thu, 30 Mar 2000 06:22:37 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: IOTP meeting in 47th IETF In-reply-to: "Your message of Thu, 30 Mar 2000 19:00:24 +0930." <38E31EB0.C87CF77A@spri.levels.unisa.edu.au> To: Chun OUYANG Cc: ietf-trade@lists.eListX.com Message-id: <200003301122.GAA10606@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp Thanks for your note. The draft of the official minutes will be posted shortly. Actually, it's the IOTP HTTP Supplement and the MIME Handler Detector drafts that I plan to working group Last Call soon, after one more revision. It the working group is satisfied, they would then be forwarded to the IESG. It will be a while before IOTP v2.0. B2BXML was a BoF also held at this IETF meeting. Donald From: Chun OUYANG Date: Thu, 30 Mar 2000 19:00:24 +0930 Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38E31EB0.C87CF77A@spri.levels.unisa.edu.au> Organization: ITR >FYI, > >... > >PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon. > 2. xml dsig and b2b xml were also discussed in this IETF meeting. > >Thanks, > >Chun > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0198L49@eListX.com>; Thu, 30 Mar 2000 04:05:09 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0198K48@eListX.com> (original mail from ouyang@SPRI.Levels.UniSA.Edu.Au); Thu, 30 Mar 2000 04:05:08 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0398K46@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 04:05:08 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0198J45@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 04:05:07 -0500 (EST) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS800HFZ98C05@eListX.com> for ietf-trade@lists.eListX.com; Thu, 30 Mar 2000 04:05:07 -0500 (EST) Received: from spri.levels.unisa.edu.au (ouyang@brezhnev [172.17.0.22]) by server1.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id SAA03374 for ; Thu, 30 Mar 2000 18:32:01 +0930 (CST) Date: Thu, 30 Mar 2000 19:00:24 +0930 From: Chun OUYANG Subject: IOTP meeting in 47th IETF Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38E31EB0.C87CF77A@spri.levels.unisa.edu.au> Organization: ITR MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , FYI, Trade WG held its meeting in 47th IETF (http://www.ietf.org/meetings/IETF-47.html) yesterday afternoon. IOTP and its related protocols have been discussed. The Chair, Sir Donald Eastlake, organized the meeting and gave an overview of IOTPs, the history and future. An presentation on DRT was given by Mr. Ko Fujimura from NTT. Here is both the good news and bad news for IOTP. The good news is it will soon become an informational RFC; the bad news is, then it will be the longest RFC document in IETF, according to Patrik, one of the ADs in Applications Area. Could I said boldly that as there isnt any standardized interoperable framework for EC on Internet except IOTP, I do hope that it can be a robust architecure for EC with world-wide popularity in the future. Thanks a lot to Yoshiaki and Andrew from Hitachi for the very nice talk with them on IOTP. Hopefully to have more discussion with the people interested in IOTP, EC or related issues in the future. Furthermore, it couldnt be better if some gurus can give their advice to me, in my future work on IOTP. PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon. 2. xml dsig and b2b xml were also discussed in this IETF meeting. Thanks, Chun Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G01C9KR6@eListX.com>; Wed, 29 Mar 2000 03:15:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G01C9JR5@eListX.com> (original mail from rp@hplb.hpl.hp.com); Wed, 29 Mar 2000 03:15:19 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G03C9JR3@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 29 Mar 2000 03:15:19 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G01C9IR2@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 29 Mar 2000 03:15:18 -0500 (EST) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS600CF3C9IPC@eListX.com> for ietf-trade@lists.eListX.com; Wed, 29 Mar 2000 03:15:18 -0500 (EST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 68EB71A70 for ; Wed, 29 Mar 2000 03:12:28 -0500 (EST) Received: from hplb.hpl.hp.com (perry-r-1.hpl.hp.com [15.144.90.85]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id JAA28487 for ; Wed, 29 Mar 2000 09:12:26 +0100 (BST) Date: Wed, 29 Mar 2000 09:11:59 +0100 From: Russell Perry Subject: Document changes Oct 99 - March 2000 To: ietf-trade@lists.eListX.com Message-id: <38E1BACF.D1EE84C9@hplb.hpl.hp.com> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Hi, I'm looking for some help to clarify some of the apparent discrepancies between the following documents: draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000). For example, several element tags are not specified in the latter document. Is this because both documents should be read together, or does it reflect the evolution of the protocol? Also, am I right in assuming that the running footer of "*papi-00.txt" (SET supplement...) is a typo, or is there a more sinister explanation :) Thanks. Regards, Russ. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F01SD0DY@eListX.com>; Tue, 28 Mar 2000 20:05:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F01SCZDX@eListX.com> (original mail from david.burdett@commerceone.com); Tue, 28 Mar 2000 20:05:23 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F03SCZDV@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 28 Mar 2000 20:05:23 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F01SCYDU@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 28 Mar 2000 20:05:22 -0500 (EST) Received: from c1plenaexi02.commerceone.com ([12.22.60.1]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS500CA4SCXPC@eListX.com> for ietf-trade@lists.eListX.com; Tue, 28 Mar 2000 20:05:22 -0500 (EST) Received: by c1plenaexi02.commerceone.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 16:59:02 -0800 Content-return: allowed Date: Tue, 28 Mar 2000 17:02:30 -0800 From: David Burdett Subject: RE: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.tx t" To: 'Shinji Kikuchi' , ietf-trade@lists.eListX.com Message-id: <80CB4C7E7DE1D311950600508BA5831F5C6DA6@neptune.commerceone.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-2022-jp" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Comments inline marked with ## ... David -----Original Message----- From: Shinji Kikuchi [mailto:s-kikuti@ccs.mt.nec.co.jp] Sent: Thursday, March 23, 2000 3:33 AM To: ietf-trade@lists.eListX.com Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt" Dear Sirs I'm just a new commer to this mailing list. Actually, I have several questions on the document of "draft-ietf-trade-xmlmsg-requirements-00.txt" . Could anyone let me know the right ideas to below items, please ? 1)First, according to the description in the document, around "2.2.4 Document Choreography", we MUST(?) set some descriptions regarding controling sequence or selection, inside of Messages, in particular, in the case of "Explicit". The most suitable part for it or associated with it inside messages seems to be "Message Routing Information" part , I guess. However, according to the description around "2.1.7 Message Routing Information", I feel a little bits difference due to below . By the only description with " Each 'hop' results in another entry.." seems to result in eventually "Peer to Peer" in each interaction in "Hub" way. Therefore, still hard to get idea regarding relationship between Routing matter and Document Choreography clearly, unfortunetely. If there were more details of it, it would be more clear, I think. Anyway, is it right idea, or misunderstanding absolutely ? ##In my view, choreography, is one of the hardest areas to do. Also by using implicit choreography, then typcially these days the choreography is hard coded into the applications that send/receive the messages.## 2)Next, please suggest the future plan or current status regarding other parts of this series. According to this specification document, Other 7 parts have been planned. Actually, I am interesting in Secure Messaging Part [XMLMSG-SM]. I am minding that status, now. So, please let me know it, if possible. ##Much of the work on XML messaging is currently being done within the auspices of ebXML. See http://www.ebxml.org/project_teams/transport.htm for more details.## Thanks, S.Kikuchi. Regards ---------------------------------------------------------- Shinji Kikuchi @ NEC Corp. Client-Server Software Labs. Development Environment Lab. Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN) Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K723Q@eListX.com>; Thu, 23 Mar 2000 07:33:02 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K713P@eListX.com> (original mail from services@eListX.com); Thu, 23 Mar 2000 07:33:01 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E03K713N@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 23 Mar 2000 07:33:01 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K713M@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 23 Mar 2000 07:33:01 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K703L@eListX.com> for ietf-trade@lists.eListX.com; Thu, 23 Mar 2000 07:33:00 -0500 (EST) Received: from TYO203.gate.nec.co.jp (TYO203.gate.nec.co.jp [202.32.8.211]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRV00ABBI9U4F@eListX.com> for ietf-trade@lists.eListX.com; Thu, 23 Mar 2000 06:51:32 -0500 (EST) Received: from mailsv.nec.co.jp (mailsv-le1 [192.168.1.90]) by TYO203.gate.nec.co.jp (8.9.3/3.7W00031314) with ESMTP id UAA17918 for ; Thu, 23 Mar 2000 20:48:49 +0900 (JST) Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.4.2]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id UAA07704 for ; Thu, 23 Mar 2000 20:48:48 +0900 (JST) Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.9.3/3.7W-GW_CCS) with ESMTP id UAA04360 for ; Thu, 23 Mar 2000 20:48:48 +0900 (JST) Received: from splpe851.ccs.mt.nec.co.jp (splpe851.ccs.mt.nec.co.jp [172.16.14.20]) by mail.ccs.mt.nec.co.jp (8.9.1a/3.6W-CCS_Master) with ESMTP id UAA17843 for ; Thu, 23 Mar 2000 20:48:47 +0900 (JST) Received: from splpe948 (splpe948.ccs.mt.nec.co.jp [172.16.14.191]) by splpe851.ccs.mt.nec.co.jp (8.9.3/3.7W-CSSL-99030622) with SMTP id UAA19396 for ; Thu, 23 Mar 2000 20:48:47 +0900 (JST) Resent-date: Thu, 23 Mar 2000 07:33:00 -0500 (EST) Date: Thu, 23 Mar 2000 20:33:03 +0900 From: Shinji Kikuchi Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt" Sender: services@eListX.com To: ietf-trade@lists.eListX.com Resent-message-id: <0FRV00E02K713M@eListX.com> Message-id: <022701bf94bb$8d64ec60$bf0e10ac@ccs.mt.nec.co.jp> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Dear Sirs I'm just a new commer to this mailing list. Actually, I have several questions on the document of "draft-ietf-trade-xmlmsg-requirements-00.txt" . Could anyone let me know the right ideas to below items, please ? 1)First, according to the description in the document, around "2.2.4 Document Choreography", we MUST(?) set some descriptions regarding controling sequence or selection, inside of Messages, in particular, in the case of "Explicit". The most suitable part for it or associated with it inside messages seems to be "Message Routing Information" part , I guess. However, according to the description around "2.1.7 Message Routing Information", I feel a little bits difference due to below . By the only description with " Each 'hop' results in another entry.." seems to result in eventually "Peer to Peer" in each interaction in "Hub" way. Therefore, still hard to get idea regarding relationship between Routing matter and Document Choreography clearly, unfortunetely. If there were more details of it, it would be more clear, I think. Anyway, is it right idea, or misunderstanding absolutely ? 2)Next, please suggest the future plan or current status regarding other parts of this series. According to this specification document, Other 7 parts have been planned. Actually, I am interesting in Secure Messaging Part [XMLMSG-SM]. I am minding that status, now. So, please let me know it, if possible. Thanks, S.Kikuchi. Regards ---------------------------------------------------------- Shinji Kikuchi @ NEC Corp. Client-Server Software Labs. Development Environment Lab. Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN) Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00501COCT5@eListX.com>; Tue, 21 Mar 2000 13:57:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00501COCT4@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Tue, 21 Mar 2000 13:57:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00503COBT2@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 21 Mar 2000 13:57:47 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00501COBT1@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 21 Mar 2000 13:57:47 -0500 (EST) Received: from smtp2.royalbank.com (smtp2.royalbank.com [198.96.131.29]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FRS0051ZCOA9H@eListX.com> for ietf-trade@lists.eListX.com; Tue, 21 Mar 2000 13:57:47 -0500 (EST) Received: from wsecure4.royalbank.com by smtp2.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Tue, 21 Mar 2000 18:55:20 +0000 (UT) Received: from 10.224.0.66 by se001018.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 21 Mar 2000 13:55:06 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2650.21) id ; Tue, 21 Mar 2000 13:55:06 -0500 Date: Tue, 21 Mar 2000 13:55:04 -0500 From: "Smith, Chris " Subject: RE: Yet more on APPLICATION/IOTP To: "'Donald E. Eastlake 3rd'" , ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B47@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 14C91A00829551-01-01 List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Call me conservative on this one - since there was not yet a formal decision on the matter, we have continued to use APPLICATION/X-IOTP even for IOTP 1.0 (which also is not returned from the editor's desk with an RFC number). I realize that I should probably join the ietf-types mailing list to find this out, but ... is there any ideas on an alternate way besides modifying the actual MIME type to indicate that XML is in use? If there were, I would prefer... APPLICATION/IOTP ...with a charset parameter ...with an encoding or markup parameter The other alternative - a really big one, at that - would be to use: XML/IOTP ...with a charset parameter ..to my mind, this better captures the actual idea of what is happening here. This is much the same as using IMAGE/ or TEXT/ where the /xxx "sub-describes" the higher level item. ------------------------------------------------------------=20 =A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090=20 =A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com=20 =20 > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: March 21, 2000 09:34 AM > To: ietf-trade@lists.eListX.com > Subject: Yet more on APPLICATION/IOTP >=20 >=20 >=20 > There continues to be an incredible blizzard of messages on the > ietf-types mailing list about whether "-xml" suffixes or the like on > MIME types is good or bad, etc. In general, the weight of the > argument seems to be in favor of this... So the question is would > changing to application/iotp-xml be a hardship on current > implementations and implementation efforts? (Early efforts used > APPLICATION/X-IOTP.) >=20 > Also, it turns out that Section F of the XML spec has been changed. > External charset indications, such as an optional charset = Content-Type > parameter, if present, over-ride and internal indication of character > encoding in XML, as specified in Informational RFC 2376. So if there > is an optional charset option, which is probably a good idea, then > when present, it should over-riode any encoding specification > appearing before the XML document unless we wnat to be = non-standard... >=20 > Donald >=20 >=20 > ------- Forwarded Message >=20 > Date: Thu, 09 Mar 2000 23:49:47 -0500 > From: "Donald E. Eastlake 3rd" > Subject: More on APPLICATION/IOTP > To: ietf-trade@lists.eListX.com > Message-id: <200003100449.XAA27249@torque.pothole.com> >=20 > The MIME type registartion template I posted to the ietf-types list > has caused a lot of comment. None of it is really about IOTP, it > is all about two issues: > (1) should it really be APPLICATION/IOTP-XML > and > (2) should it allow/require a charset parameter >=20 > That is, people are arguing about whether all new XML content MIME > types should have a subtype with a "-xml" on the end. I would > assume we don't want to change due to existing implementations. >=20 > On the charset paramter issue, I think I should add it as an > optional parameter. Section F of the XML 1.0 specification makes > it clear that the charset as indicated by the actual data > including any byte order mark and encoding declaration and that > any "external" charset, as the charset parameter would be, is > "solely for error recovery." >=20 > Thanks, > donald > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd dee3@torque.pothole.com > 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) > Carmel, NY 10512 USA +1 508-261-5434(w) >=20 > ------- End of Forwarded Message >=20 >=20 > --JAA02481.953649127/torque.pothole.com-- >=20 >=20 > ------- End of Forwarded Message >=20 >=20 --Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: Yet more on APPLICATION/IOTP

Call me conservative on this one - since there was = not yet a formal
decision on the matter, we have continued to use = APPLICATION/X-IOTP
even for IOTP 1.0 (which also is not returned from = the editor's desk
with an RFC number).

I realize that I should probably join the ietf-types = mailing list
to find this out, but ... is there any ideas on an = alternate way
besides modifying the actual MIME type to indicate = that XML is in
use?

If there were, I would prefer...

   APPLICATION/IOTP
   ...with a charset parameter
   ...with an encoding or markup = parameter

The other alternative - a really big one, at that - = would be
to use:

   XML/IOTP
   ...with a charset parameter

..to my mind, this better captures the actual idea of = what is
happening here. This is much the same as using = IMAGE/ or TEXT/
where the /xxx "sub-describes" the higher = level item.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com


  


> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
> Sent: March 21, 2000 09:34 AM
> To: ietf-trade@lists.eListX.com
> Subject: Yet more on APPLICATION/IOTP
>
>
>
> There continues to be an incredible blizzard of = messages on the
> ietf-types mailing list about whether = "-xml" suffixes or the like on
> MIME types is good or bad, etc.  In = general, the weight of the
> argument seems to be in favor of this...  = So the question is would
> changing to application/iotp-xml be a hardship = on current
> implementations and implementation = efforts?  (Early efforts used
> APPLICATION/X-IOTP.)
>
> Also, it turns out that Section F of the XML = spec has been changed.
> External charset indications, such as an = optional charset Content-Type
> parameter, if present, over-ride and internal = indication of character
> encoding in XML, as specified in Informational = RFC 2376.  So if there
> is an optional charset option, which is = probably a good idea, then
> when present, it should over-riode any encoding = specification
> appearing before the XML document unless we = wnat to be non-standard...
>
> Donald
>
>
> ------- Forwarded Message
>
> Date:  Thu, 09 Mar 2000 23:49:47 = -0500
> From:  "Donald E. Eastlake 3rd" = <dee3@torque.pothole.com>
> Subject:  More on APPLICATION/IOTP
> To:  ietf-trade@lists.eListX.com
> Message-id:  = <200003100449.XAA27249@torque.pothole.com>
>
> The MIME type registartion template I posted to = the ietf-types list
> has caused a lot of comment.  None of it = is really about IOTP, it
> is all about two issues:
> (1) should it really be = APPLICATION/IOTP-XML
> and
> (2) should it allow/require a charset = parameter
>
> That is, people are arguing about whether all = new XML content MIME
> types should have a subtype with a = "-xml" on the end.  I would
> assume we don't want to change due to existing = implementations.
>
> On the charset paramter issue, I think I should = add it as an
> optional parameter.  Section F of the XML = 1.0 specification makes
> it clear that the charset as indicated by the = actual data
> including any byte order mark and encoding = declaration and that
> any "external" charset, as the = charset parameter would be, is
> "solely for error recovery."
>
> Thanks,
> donald
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  Donald E. Eastlake = 3rd           &nb= sp;          = dee3@torque.pothole.com
>  65 Shindegan Hill Road, = RR#1           &n= bsp;         +1 = 914-276-2668(h)
>  Carmel, NY 10512 = USA           &nb= sp;           &nb= sp;     +1 508-261-5434(w)
>
> ------- End of Forwarded Message
>
>
> = --JAA02481.953649127/torque.pothole.com--
>
>
> ------- End of Forwarded Message
>
>

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004010K3SM@eListX.com>; Tue, 21 Mar 2000 09:36:03 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004010K2SL@eListX.com> (original mail from dee3@torque.pothole.com) ; Tue, 21 Mar 2000 09:36:02 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004030K2SJ@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Tue, 21 Mar 2000 09:36:02 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004010K1SI@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Tue, 21 Mar 2000 09:36:01 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRS000FU0JY12@eListX.com> for ietf-trade@lists.eListX.com; Tue, 21 Mar 2000 09:36:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id JAA02507 for ietf-trade@lists.elistx.com; Tue, 21 Mar 2000 09:34:15 -0500 (EST) Date: Tue, 21 Mar 2000 09:34:15 -0500 From: "Donald E. Eastlake 3rd" Subject: Yet more on APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003211434.JAA02507@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp There continues to be an incredible blizzard of messages on the ietf-types mailing list about whether "-xml" suffixes or the like on MIME types is good or bad, etc. In general, the weight of the argument seems to be in favor of this... So the question is would changing to application/iotp-xml be a hardship on current implementations and implementation efforts? (Early efforts used APPLICATION/X-IOTP.) Also, it turns out that Section F of the XML spec has been changed. External charset indications, such as an optional charset Content-Type parameter, if present, over-ride and internal indication of character encoding in XML, as specified in Informational RFC 2376. So if there is an optional charset option, which is probably a good idea, then when present, it should over-riode any encoding specification appearing before the XML document unless we wnat to be non-standard... Donald ------- Forwarded Message Date: Thu, 09 Mar 2000 23:49:47 -0500 From: "Donald E. Eastlake 3rd" Subject: More on APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003100449.XAA27249@torque.pothole.com> The MIME type registartion template I posted to the ietf-types list has caused a lot of comment. None of it is really about IOTP, it is all about two issues: (1) should it really be APPLICATION/IOTP-XML and (2) should it allow/require a charset parameter That is, people are arguing about whether all new XML content MIME types should have a subtype with a "-xml" on the end. I would assume we don't want to change due to existing implementations. On the charset paramter issue, I think I should add it as an optional parameter. Section F of the XML 1.0 specification makes it clear that the charset as indicated by the actual data including any byte order mark and encoding declaration and that any "external" charset, as the charset parameter would be, is "solely for error recovery." Thanks, donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) Carmel, NY 10512 USA +1 508-261-5434(w) ------- End of Forwarded Message --JAA02481.953649127/torque.pothole.com-- ------- End of Forwarded Message Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9YXN@eListX.com>; Mon, 13 Mar 2000 06:22:46 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9XXM@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Mon, 13 Mar 2000 06:22:46 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00703Y9XXK@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:45 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9WXJ@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:44 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRC0027VY9VE7@eListX.com> for ietf-trade@lists.eListX.com; Mon, 13 Mar 2000 06:22:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15659; Mon, 13 Mar 2000 06:20:19 -0500 (EST) Date: Mon, 13 Mar 2000 06:20:18 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-set-00.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003131120.GAA15659@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)" --Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Author(s) : Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-set-00.txt Pages : 58 Date : 10-Mar-00 This document describes detailed Input/Output parameter for the IOTP Payment API and a procedure in the Payment Bridge for use SET as the payment protocol within Version 1.0 of the Internet Open Trading Protocol (IOTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-set-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg) Content-type: multipart/alternative; boundary="Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)" --Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310140405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt --Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA) Content-type: Message/External-body; name="draft-ietf-trade-iotp-v1.0-set-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310140405.I-D@ietf.org> --Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)-- --Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9SXE@eListX.com>; Mon, 13 Mar 2000 06:22:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9RXD@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Mon, 13 Mar 2000 06:22:39 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00703Y9RXB@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:39 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9QXA@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:38 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRC0027SY9PE7@eListX.com> for ietf-trade@lists.eListX.com; Mon, 13 Mar 2000 06:22:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15633; Mon, 13 Mar 2000 06:20:13 -0500 (EST) Date: Mon, 13 Mar 2000 06:20:13 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-papi-00.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003131120.GAA15633@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)" --Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Architecture and Payment API for Internet Open Trading Protocol (IOTP) Author(s) : W. Hans, H. Beykirch, M. Hiroya, Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-papi-00.txt Pages : 143 Date : 10-Mar-00 The Trading Architecture proposes an abstract layered model of the IOTP based trading environment. Its description sketches the essential functional and data modules and their interfaces at each trading role's installation. This abstract view deals as a guideline for the modules' mapping to actual software modules. The second part of this document focuses on the Payment API that improves the essential interface that relates to payment transactions. Such interface exists at the Consumers', the Merchants' and the Payment Handlers' installations connecting the actual payment software components/legacy systems and the generic IOTP aware front end application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-papi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q) Content-type: multipart/alternative; boundary="Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)" --Boundary_(ID_DrNEC/duxiY9uA42MMTqGA) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310140353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt --Boundary_(ID_DrNEC/duxiY9uA42MMTqGA) Content-type: Message/External-body; name="draft-ietf-trade-iotp-v1.0-papi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310140353.I-D@ietf.org> --Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)-- --Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00501LKHKY@eListX.com>; Mon, 13 Mar 2000 01:48:17 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00501LKGKX@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Mon, 13 Mar 2000 01:48:16 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00503LKGKV@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 01:48:16 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00501LKFKU@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 01:48:16 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRC00267LKDE7@eListX.com> for ietf-trade@lists.eListX.com; Mon, 13 Mar 2000 01:48:15 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id PAA07897; Mon, 13 Mar 2000 15:45:37 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/09/00) with ESMTP id PAA02622; Mon, 13 Mar 2000 15:45:29 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by renoir.isl.ntt.co.jp (8.8.8/isl-2.0) id PAA02463; Mon, 13 Mar 2000 15:45:27 +0900 (JST) Date: Mon, 13 Mar 2000 15:45:27 +0900 From: Ko Fujimura Subject: Re: IOTP and Coupons (was RE: future OTP transactions) In-reply-to: "In your message of Fri, 10 Mar 2000 14:35:34 -0500" <2B30A9965635D311A29F002035297FFB1B2B33@se001010.rbc1.royalbank.com> To: CHRIS.SMITH@ROYALBANK.COM Cc: ietf-trade@lists.eListX.com Message-id: MIME-version: 1.0 (generated by REMI 1.14.0 - "Uragawara") Content-type: text/plain; charset=US-ASCII User-Agent: Wanderlust/2.2.18 (Please Forgive Me) REMI/1.14.0 (Uragawara) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) APEL/10.1 MULE XEmacs/21.2 (beta31) (Iris) (sparc-sun-solaris2.6) References: <2B30A9965635D311A29F002035297FFB1B2B33@se001010.rbc1.royalbank.com> Hi, At Fri, 10 Mar 2000 14:35:34 -0500, Smith, Chris wrote: > > [1 ] > Because the blocks in a PaymentRequest (the included > payment system data) have names, it would be possible > to add additional out-ot-payment-protocol blocks that > contained the needed information. > > This would be fine for IOTP, but some payment systems > might consider these additional blocks to be non-standard. > > In a more general case, you could take advantage of a > couple of other features: > > 1) IOTP allows Authentication transactions prior to > any other transaction. Also, the final version > provided a way to send several Authentication > types in the same request. > > A coupon is a form of authorization/authentication, > so a special Authentication Supplement could be > created to handle them. > > Thus a single Auth up front could be the equivalent > of the merchant asking "Do you have AirMiles", "Do > you have coupons", "Are you a club member" - all in > one step. > > Since the AUth precedes the OfferResponse generation, > any information returned on the Auth can be used to > make changes in pricing. > > 2) IOTP does allow for brand-dependent offers as well, > where the payment brand selection precedes the final > generation of the OfferResponse. Yes, the current IOTP spec allows several ways to process coupons, gift certificates, or loyality points. Redemption of a coupon, for example, can be implemented as the Offer, Payment, and/or Authentication Exchanges depending on the Merchant decision as Chris pointed out. Issuance of a coupon can also be implemented as the Delivery Exchanges. I would like to mention my understanding of the relationship between the Digital-Right Trading (DRT) and IOTP model. In short, I think that DRT is a component which can be commonly used within the IOTP Exchanges. In other words, I think that the DRT is layered under the IOTP Exchanges. > > -----Original Message----- > > From: David Bourget [mailto:dbourget@videotron.ca] > > Sent: January 6, 1998 09:15 AM > > To: ietf-trade@lists.eListX.com > > Subject: future OTP transactions > > > > > > Hi, > > > > First question: > > I'd like to know if there is plans for future OTP transactions > > supporting negociation of promotional offers and prices. > > Example : I've > > got a gift certificate, which is only a reference number, and I'd like > > to know its real value. This kind of interaction would allow current > > web-based promotional offers to be used in an OTP context. Since one of the goals of the Digital-Right Trading is to provide a common language to exchange such a promotional offer information needed in the IOTP exchanges, such kind of gift certificates should/can be covered in the DRT model and language. Using the language, it might be roughly defined as below, although the protocols might be left vendor-specific. Thanks, Ko ---------------------------------------------------------- Ko Fujimura, NTT Information Sharing Platform Laboratories 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-8329 Email: fujimura@isl.ntt.co.jp Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0117CNZ@eListX.com>; Fri, 10 Mar 2000 14:38:00 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0117CNY@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 10 Mar 2000 14:38:00 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0317BNW@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:37:59 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0117BNV@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:37:59 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR8006FE17AIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 14:37:59 -0500 (EST) Received: from wsecure3.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 10 Mar 2000 19:34:58 +0000 (UT) Received: from 10.224.0.66 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 10 Mar 2000 14:35:16 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 10 Mar 2000 14:35:38 -0500 Date: Fri, 10 Mar 2000 14:35:34 -0500 From: "Smith, Chris " Subject: IOTP and Coupons (was RE: future OTP transactions) To: ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B33@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 14D791FE412069-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Because the blocks in a PaymentRequest (the included payment system data) have names, it would be possible to add additional out-ot-payment-protocol blocks that contained the needed information. This would be fine for IOTP, but some payment systems might consider these additional blocks to be non-standard. In a more general case, you could take advantage of a couple of other features: 1) IOTP allows Authentication transactions prior to any other transaction. Also, the final version provided a way to send several Authentication types in the same request. A coupon is a form of authorization/authentication, so a special Authentication Supplement could be created to handle them. Thus a single Auth up front could be the equivalent of the merchant asking "Do you have AirMiles", "Do you have coupons", "Are you a club member" - all in one step. Since the AUth precedes the OfferResponse generation, any information returned on the Auth can be used to make changes in pricing. 2) IOTP does allow for brand-dependent offers as well, where the payment brand selection precedes the final generation of the OfferResponse. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com P.S. Unless you have some psychic ability that allowed you to phrase such coherent questions over two years ago, you need to reset the clock on your system -- see the Sent: line below. > -----Original Message----- > From: David Bourget [mailto:dbourget@videotron.ca] > Sent: January 6, 1998 09:15 AM > To: ietf-trade@lists.eListX.com > Subject: future OTP transactions > > > Hi, > > First question: > I'd like to know if there is plans for future OTP transactions > supporting negociation of promotional offers and prices. > Example : I've > got a gift certificate, which is only a reference number, and I'd like > to know its real value. This kind of interaction would allow current > web-based promotional offers to be used in an OTP context. > > Second question: > Where can I find information about the current work related > to SCCD ? I > can't find anything on the web or the working group site. > > > > > > > --Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable IOTP and Coupons (was RE: future OTP transactions)

Because the blocks in a PaymentRequest (the = included
payment system data) have names, it would be = possible
to add additional out-ot-payment-protocol blocks = that
contained the needed information.

This would be fine for IOTP, but some payment = systems
might consider these additional blocks to be = non-standard.

In a more general case, you could take advantage of = a
couple of other features:

1) IOTP allows Authentication transactions prior = to
   any other transaction. Also, the final = version
   provided a way to send several = Authentication
   types in the same request.

   A coupon is a form of = authorization/authentication,
   so a special Authentication Supplement = could be
   created to handle them.

   Thus a single Auth up front could be the = equivalent
   of the merchant asking "Do you = have AirMiles", "Do
   you have coupons", "Are you a = club member" - all in
   one step.

   Since the AUth precedes the = OfferResponse generation,
   any information returned on the Auth = can be used to
   make changes in pricing.

2) IOTP does allow for brand-dependent offers as = well,
   where the payment brand selection = precedes the final
   generation of the OfferResponse.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com


P.S. Unless you have some psychic ability that = allowed you
to phrase such coherent questions over two years = ago, you
need to reset the clock on your system -- see the = Sent:
line below.

> -----Original Message-----
> From: David Bourget [mailto:dbourget@videotron.ca]<= /FONT>
> Sent: January 6, 1998 09:15 AM
> To: ietf-trade@lists.eListX.com
> Subject: future OTP transactions
>
>
> Hi,
>
> First question:
> I'd like to know if there is plans for future = OTP transactions
> supporting negociation of promotional offers = and prices.
> Example : I've
> got a gift certificate, which is only a = reference number, and I'd like
> to know its real value. This kind of = interaction would allow current
> web-based promotional offers to be used in an = OTP context.
>
> Second question:
> Where can I find information about the current = work related
> to SCCD ? I
> can't find anything on the web or the working = group site.
>
>
>
>
>
>
>

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A010N0LR@eListX.com>; Fri, 10 Mar 2000 14:25:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A010MZLQ@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 10 Mar 2000 14:25:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A030MZLO@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:25:47 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A010MZLN@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:25:47 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR8006EV0MYIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 14:25:46 -0500 (EST) Received: from wsecure3.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 10 Mar 2000 19:22:45 +0000 (UT) Received: from 10.224.0.67 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 10 Mar 2000 14:23:04 -0500 Received: by se001017.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 10 Mar 2000 14:23:25 -0500 Date: Fri, 10 Mar 2000 14:23:26 -0500 From: "Smith, Chris " Subject: Adopting IOTP (was RE: future OTP transactions) To: ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B31@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 14D79412410716-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit One question at a time... In my opinion, Version 1 of IOTP satisfies the requirements of the vast majority of e-retailing sites, as far as the customer side is concerned. Adoption is subject to the chicken-and-egg problem. Merchants won't jump in large numbers to a protocol (or even a full standard) unless their customers are using it. Customers won't jump in huge numbers unless they see merchants offering it. That said - IOTP is structured to make it's adoption relatively easy. For the simplest setup, the merchant will simply issue an OfferResponse, and then be prepared to accept a DeliveryRequest. The working idea is that the PaymentHandler is operated by one (or more - competition) agencies, much the way credit card processors operate today. The merchant's task is made considerably simpler if they don't have to handle the payment steps, just deliver when notified of successful payments. In a dedicated implementation, even if SCCD is used (which is roughly equivalent to SSL today) the merchant no longer carries the credit card info with its attendant risks. The risks are now transferred to the PaymentHandler - however, ensuring that relatively few PaymentHandlers are properly secured and defended is easier than ensuring that a relatively large number of Merchants are secured and defended. Interestingly, IOTP, if adopted, makes the addition of additional payment systems much easier. The merchant simply updates their offer to indicate the acceptance of the added payment system and the details of the PaymentHandler for that system. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com > -----Original Message----- > From: David Bourget [mailto:dbourget@videotron.ca] > Subject: Re: future OTP transactions > - Second, the real one: What are the expectations of the WG > about merchants > adoption of the protocol ? I'm talking about e-retailing > sites like Amazon, Cdnow > etc. Do you consider "baseline" OTP to fullfil most of their > requirements, i.e will > they have to wait until v2 ? --Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Adopting IOTP (was RE: future OTP transactions)

One question at a time...

In my opinion, Version 1 of IOTP satisfies the = requirements
of the vast majority of e-retailing sites, as far as = the
customer side is concerned.

Adoption is subject to the chicken-and-egg = problem.
Merchants won't jump in large numbers to a protocol = (or
even a full standard) unless their customers are = using
it. Customers won't jump in huge numbers unless they =
see merchants offering it.

That said - IOTP is structured to make it's adoption =
relatively easy. For the simplest setup, the = merchant will
simply issue an OfferResponse, and then be prepared = to
accept a DeliveryRequest. The working idea is that = the
PaymentHandler is operated by one (or more - = competition)
agencies, much the way credit card processors = operate today.
The merchant's task is made considerably simpler if = they
don't have to handle the payment steps, just deliver = when
notified of successful payments. In a dedicated =
implementation, even if SCCD is used (which is = roughly
equivalent to SSL today) the merchant no longer = carries the
credit card info with its attendant risks. The risks = are
now transferred to the PaymentHandler - however, = ensuring
that relatively few PaymentHandlers are properly = secured
and defended is easier than ensuring that a = relatively
large number of Merchants are secured and = defended.

Interestingly, IOTP, if adopted, makes the addition = of
additional payment systems much easier. The merchant = simply
updates their offer to indicate the acceptance of = the added
payment system and the details of the PaymentHandler = for
that system.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com



> -----Original Message-----
> From: David Bourget [mailto:dbourget@videotron.ca]<= /FONT>
> Subject: Re: future OTP transactions

> - Second, the real one: What are the = expectations of the WG
> about merchants
> adoption of the protocol ? I'm talking about = e-retailing
> sites like Amazon, Cdnow
> etc. Do you consider "baseline" OTP = to fullfil most of their
> requirements, i.e will
> they have to wait until v2 ?

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A01ZXCJS@eListX.com>; Fri, 10 Mar 2000 14:10:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A01ZXCJR@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 10 Mar 2000 14:10:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A03ZXBJP@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:10:23 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A01ZXBJO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:10:23 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR7006EPZXAIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 14:10:23 -0500 (EST) Received: from wsecure2.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 10 Mar 2000 19:07:22 +0000 (UT) Received: from 10.224.0.66 by se001020.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 10 Mar 2000 14:09:10 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 10 Mar 2000 14:08:02 -0500 Date: Fri, 10 Mar 2000 14:08:02 -0500 From: "Smith, Chris " Subject: RE: error handling To: ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B30@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)" X-Server-Uuid: d237928a-6c98-11d3-985c-00a0c9ea509d X-WSS-ID: 14D797DC4616006-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_zth3wilshPvLHxAEHc2xoQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit At some point, the client will determine that there is a problem, either because some evidence of an unacceptable reply exists, or because a timeout expires. In both cases, the client is permitted to resubmit the original request. (Keep in mind that the client does not know whether or not the original was even received by the server.) At the server side, the receipt of identical requests is supposed to result in the return of the original corresponding reply. Thus, even if the server has processed the request once already, the response can be retrieved a second time without difficulty. (A corollary to this is that the server is expected to check all inbound requests to see if they are duplicates of previous requests.) Over the most common transport, HTTP, there are no sessions held open. As a result, the client can even become disconnected from the network, but if the client has done a proper job of retaining state on its end, the final request can be re-sent, and the transaction completed, once the network reconnects. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com > -----Original Message----- > From: David Bourget [mailto:dbourget@videotron.ca] > Subject: error handling > What happen if there is an error in the last message of a transaction > happing over HTTP ? The last message, maybe a delivery note, > is supposed > to close the transaction so the server will not be waiting for a > confirmation before commiting the changes made in the > transaction. This > mean that at this point the transaction cannot be rolled back. But if > the last message is all garbage, then our customer is in trouble. What > is the solution provided by the OTP to this problem ? --Boundary_(ID_zth3wilshPvLHxAEHc2xoQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: error handling

At some point, the client will determine that there = is a problem,
either because some evidence of an unacceptable = reply exists, or
because a timeout expires.

In both cases, the client is permitted to resubmit = the original
request. (Keep in mind that the client does not know = whether or
not the original was even received by the = server.)

At the server side, the receipt of identical requests = is supposed
to result in the return of the original = corresponding reply. Thus,
even if the server has processed the request once = already, the
response can be retrieved a second time without = difficulty. (A
corollary to this is that the server is expected to = check all
inbound requests to see if they are duplicates of = previous requests.)

Over the most common transport, HTTP, there are no = sessions held open.
As a result, the client can even become disconnected = from the network,
but if the client has done a proper job of retaining = state on its
end, the final request can be re-sent, and the = transaction completed,
once the network reconnects.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com

> -----Original Message-----
> From: David Bourget [mailto:dbourget@videotron.ca]<= /FONT>
> Subject: error handling

> What happen if there is an error in the last = message of a transaction
> happing over HTTP ? The last message, maybe a = delivery note,
> is supposed
> to close the transaction so the server will not = be waiting for a
> confirmation before commiting the changes made = in the
> transaction. This
> mean that at this point the transaction cannot = be rolled back. But if
> the last message is all garbage, then our = customer is in trouble. What
> is the solution provided by the OTP to this = problem ?

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M94GH@eListX.com>; Fri, 10 Mar 2000 09:15:04 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M94GG@eListX.com> (original mail from services@eListX.com); Fri, 10 Mar 2000 09:15:04 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700903M93GE@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:15:03 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M93GD@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:15:03 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M93GC@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 09:15:03 -0500 (EST) Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR70066U6OZIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:39:00 -0500 (EST) Received: from videotron.ca ([24.200.182.123]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FR7008GC6L2X1@field.videotron.net> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:36:39 -0500 (EST) Resent-date: Fri, 10 Mar 2000 09:15:03 -0500 (EST) Date: Tue, 03 Mar 1998 17:48:35 -0500 From: David Bourget Subject: error handling Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR700902M93GD@eListX.com> Message-id: <34FC88C3.8A086D35@videotron.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [fr] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr Hi, I'm almost flooding this mailing list these days, but I've got a puzzling question : What happen if there is an error in the last message of a transaction happing over HTTP ? The last message, maybe a delivery note, is supposed to close the transaction so the server will not be waiting for a confirmation before commiting the changes made in the transaction. This mean that at this point the transaction cannot be rolled back. But if the last message is all garbage, then our customer is in trouble. What is the solution provided by the OTP to this problem ? thank you, David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7MG9@eListX.com>; Fri, 10 Mar 2000 09:14:10 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7MG8@eListX.com> (original mail from services@eListX.com); Fri, 10 Mar 2000 09:14:10 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700903M7LG6@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:14:09 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7LG5@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:14:09 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7LG4@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 09:14:09 -0500 (EST) Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR70066K52OIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:04:01 -0500 (EST) Received: from videotron.ca ([24.200.182.123]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FR7005MR4YRGO@field.videotron.net> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:01:39 -0500 (EST) Resent-date: Fri, 10 Mar 2000 09:14:09 -0500 (EST) Date: Wed, 07 Jan 1998 17:13:50 -0500 From: David Bourget Subject: Re: future OTP transactions Sender: services@eListX.com To: "Donald E. Eastlake 3rd" Cc: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR700902M7LG5@eListX.com> Message-id: <34B3FE1E.CDFAC109@videotron.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [fr] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr References: <200003100406.XAA17543@torque.pothole.com> Hi, Thank you for the information Donald. I'm presently studying the specification and two other questions arises that you or other people on this mailing list might be able to answer : - First, trivial question: is there a version of the 1.0 draft in word, html or any kind of browsable format that would make the experience more enjoyable than scrolling in a 200 pages ASCII file ? I can't find any. That is, can I have the source ? (I have found the version on otp.org to be not enaught current) - Second, the real one: What are the expectations of the WG about merchants adoption of the protocol ? I'm talking about e-retailing sites like Amazon, Cdnow etc. Do you consider "baseline" OTP to fullfil most of their requirements, i.e will they have to wait until v2 ? - Finaly, a third question : I'm trying to fit the baseline purchase transaction on current .com merchants purchase transaction model and the following questions arise : - Can a baseline purchase transaction happen as follow : [ client ] [ merchant ] shop select shipping --- I wanna buy--> start transaction here <-----order,brandslist etc---- prepare order select payment -------( very simple payment process payment, generate delivery note protocol, that is : here's my card number )-----> happy customer <---------delivery note-------- In fact, I'm trying to figure out what is the simplest form of a purchase transaction supported by an OTP agent. It seems to me that being able to do such simples transactions is a priority for online merchants who wants to save bandwidth and streamline the buying process. regards, David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701W5OVL@eListX.com>; Thu, 9 Mar 2000 23:51:25 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701W5OVK@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 09 Mar 2000 23:51:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600703W5OVI@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 23:51:24 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701W5NVH@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 23:51:23 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR60065KW5LIS@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 23:51:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA27249 for ietf-trade@lists.elistx.com; Thu, 09 Mar 2000 23:49:47 -0500 (EST) Date: Thu, 09 Mar 2000 23:49:47 -0500 From: "Donald E. Eastlake 3rd" Subject: More on APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003100449.XAA27249@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp The MIME type registartion template I posted to the ietf-types list has caused a lot of comment. None of it is really about IOTP, it is all about two issues: (1) should it really be APPLICATION/IOTP-XML and (2) should it allow/require a charset parameter That is, people are arguing about whether all new XML content MIME types should have a subtype with a "-xml" on the end. I would assume we don't want to change due to existing implementations. On the charset paramter issue, I think I should add it as an optional parameter. Section F of the XML 1.0 specification makes it clear that the charset as indicated by the actual data including any byte order mark and encoding declaration and that any "external" charset, as the charset parameter would be, is "solely for error recovery." Thanks, donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) Carmel, NY 10512 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701UHHS8@eListX.com>; Thu, 9 Mar 2000 23:15:17 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701UHGS7@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 09 Mar 2000 23:15:16 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600703UHGS5@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:15:16 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701UHFS4@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:15:15 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR60064TUHDIS@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 23:15:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA17664; Thu, 09 Mar 2000 23:13:33 -0500 (EST) Date: Thu, 09 Mar 2000 23:13:33 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: question about IotpSignature..! In-reply-to: "Your message of Thu, 09 Mar 2000 14:44:17 +0800." To: Andre Chan Cc: IOTP Group Message-id: <200003100413.XAA17664@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp It's just the declaration of three algorithms. Each is identified by an ID. All of them but algorithm A2 take as an explicit parameter or argument another algorithm identified by an ID. I don't know what you mean by "using sha1 first". It is dom-hash which produces a serialization of the DOM which is fed to sha1. Donald From: Andre Chan Date: Thu, 09 Mar 2000 14:44:17 +0800 To: IOTP Group Resent-message-id: <0FR500402OWE42@eListX.com> Message-id: > I would like to ask what is the meaning of the Element "Parameter". From >the example below (which I copy for the doc >"draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the >signature are generated by the following sequence A2, A1, A3. That means I >will use sha1 first, then dom-hash and finally use the rsa to sign it. But, >the right sequence should be A1, A2, A3. How do I interpret the meaning of >the below example? > > > A2 > > > > > A1 > > >Thanks > >Andre > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701U52PT@eListX.com>; Thu, 9 Mar 2000 23:07:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701U52PS@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 09 Mar 2000 23:07:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600703U51PQ@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:07:49 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701U51PP@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:07:49 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR60064NU4ZIS@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 23:07:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA17543; Thu, 09 Mar 2000 23:06:06 -0500 (EST) Date: Thu, 09 Mar 2000 23:06:06 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: future OTP transactions In-reply-to: "Your message of Tue, 06 Jan 1998 09:15:22 EST." <34B23C7A.68969715@videotron.ca> To: dbourget@videotron.ca Cc: ietf-trade@lists.eListX.com Message-id: <200003100406.XAA17543@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp Truly different structured transactions will probably wait until IOTP v2. Digital Right such as promotional offers are also being a topic which has been discussed at TRADE WG meetings. See . I post an additonal response on SCCD shortly. Donald From: David Bourget Resent-From: ietf-trade-errors@lists.eListX.com Resent-date: Thu, 09 Mar 2000 08:15:40 -0500 (EST) Date: Tue, 06 Jan 1998 09:15:22 -0500 Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR500402OU53S@eListX.com> Message-id: <34B23C7A.68969715@videotron.ca> >Hi, > >First question: >I'd like to know if there is plans for future OTP transactions >supporting negociation of promotional offers and prices. Example : I've >got a gift certificate, which is only a reference number, and I'd like >to know its real value. This kind of interaction would allow current >web-based promotional offers to be used in an OTP context. > >Second question: >Where can I find information about the current work related to SCCD ? I >can't find anything on the web or the working group site. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWG46@eListX.com>; Thu, 9 Mar 2000 08:17:04 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWF45@eListX.com> (original mail from services@eListX.com); Thu, 09 Mar 2000 08:17:03 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500403OWF43@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:17:03 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWE42@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:17:02 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWE41@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 08:17:02 -0500 (EST) Received: from mailgw.ust.hk (mailgw.ust.hk [143.89.14.35]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR5000956JL7A@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 01:40:35 -0500 (EST) Received: from imaila.ust.hk (imaila.ust.hk [143.89.14.173]) by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id OAA18437 for ; Thu, 09 Mar 2000 14:30:33 +0800 (HKT) Received: from imz133 (imz133.ust.hk [143.89.56.96]) by imaila.ust.hk (8.9.3/8.9.3) with SMTP id OAA13104 for ; Thu, 09 Mar 2000 14:35:23 +0800 (HKT) Resent-date: Thu, 09 Mar 2000 08:17:02 -0500 (EST) Date: Thu, 09 Mar 2000 14:44:17 +0800 From: Andre Chan Subject: question about IotpSignature..! Sender: services@eListX.com To: IOTP Group Resent-message-id: <0FR500402OWE42@eListX.com> Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal I would like to ask what is the meaning of the Element "Parameter". From the example below (which I copy for the doc "draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the signature are generated by the following sequence A2, A1, A3. That means I will use sha1 first, then dom-hash and finally use the rsa to sign it. But, the right sequence should be A1, A2, A3. How do I interpret the meaning of the below example? A2 A1 Thanks Andre Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU63W@eListX.com>; Thu, 9 Mar 2000 08:15:42 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU53V@eListX.com> (original mail from services@eListX.com); Thu, 09 Mar 2000 08:15:42 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500403OU53T@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:15:41 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU53S@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:15:41 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU43R@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 08:15:40 -0500 (EST) Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR40004XOXL7A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 19:20:09 -0500 (EST) Received: from videotron.ca ([24.200.182.123]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FR4005I5OTDH0@falla.videotron.net> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 19:17:38 -0500 (EST) Resent-date: Thu, 09 Mar 2000 08:15:40 -0500 (EST) Date: Tue, 06 Jan 1998 09:15:22 -0500 From: David Bourget Subject: future OTP transactions Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR500402OU53S@eListX.com> Message-id: <34B23C7A.68969715@videotron.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [fr] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr Hi, First question: I'd like to know if there is plans for future OTP transactions supporting negociation of promotional offers and prices. Example : I've got a gift certificate, which is only a reference number, and I'd like to know its real value. This kind of interaction would allow current web-based promotional offers to be used in an OTP context. Second question: Where can I find information about the current work related to SCCD ? I can't find anything on the web or the working group site. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301K14QB@eListX.com>; Thu, 9 Mar 2000 06:31:52 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301K13QA@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Thu, 09 Mar 2000 06:31:52 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500303K13Q8@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 06:31:51 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301K13Q7@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 06:31:51 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR5000COK127A@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 06:31:50 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24973; Thu, 09 Mar 2000 06:29:32 -0500 (EST) Date: Thu, 09 Mar 2000 06:29:31 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-mime-detector-02.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003091129.GAA24973@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)" --Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : HTTP MIME Type Handler Detection Author(s) : D. Eastlake 3rd, C. Smith, D. Soroka Filename : draft-ietf-trade-mime-detector-02.txt Pages : 13 Date : 08-Mar-00 Entities composing web pages to provide services over HTTP frequently have the problem of not knowing what MIME types have handlers installed at a user's browser. For example, whether an IOTP or VRML or SET or some streaming media handler is available. In many cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes a reasonable technique to solve this problem for most of the browsers actually deployed on the Internet as of August 1999. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-mime-detector-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-mime-detector-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ) Content-type: multipart/alternative; boundary="Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)" --Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000308131848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt --Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg) Content-type: Message/External-body; name="draft-ietf-trade-mime-detector-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131848.I-D@ietf.org> --Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)-- --Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301BRJ8Q@eListX.com>; Thu, 9 Mar 2000 03:33:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301BRJ8P@eListX.com> (original mail from rudolf@metechnology.com) ; Thu, 09 Mar 2000 03:33:19 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500303BRJ8N@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 03:33:19 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301BRI8M@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 03:33:18 -0500 (EST) Received: from matavnet.hu (matavnet.hu [145.236.224.246]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR5000ATBRH7A@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 03:33:18 -0500 (EST) Received: (qmail 88 invoked from network); Thu, 09 Mar 2000 09:30:51 +0100 Received: from line-208-38.dial.matav.net (HELO apps) (145.236.208.38) by mail.matav.hu with SMTP; Thu, 09 Mar 2000 09:30:51 +0100 Received: from 10.0.0.10 by apps ([10.0.0.1] running VPOP3) with SMTP; Thu, 09 Mar 2000 09:22:17 +0100 Date: Thu, 09 Mar 2000 09:22:16 +0100 From: Rudolf Hornig Subject: RE: IOTP implementations In-reply-to: <200003090030.TAA13544@torque.pothole.com> To: "'Donald E. Eastlake 3rd'" Cc: ietf-trade@lists.eListX.com Reply-to: rudolf@metechnology.com Message-id: <000401bf89a0$95205500$0a00000a@MeTechnology.hu> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Server: VPOP3 V1.3.0b - Registered to: Me Technology This is a multi-part message in MIME format. --Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit > As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal > Bank of Canada. > > The following have said they are implementing IOTP 1.0: > Hitachi (SMILE Project) > Royal Bank of Canada > SIZ > CyberSource > Differential > Xenosys Corporation > > Donald We have also an 1.0 implementation here at Brokat... Rudolf -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rudolf Hornig (Rudolf@MeTechnology.com), Project Leader MeTechnology Ltd. Hungary - a Brokat Company -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg) Content-type: text/x-vcard; name="Rudolf Hornig (E-mail).vcf" Content-disposition: attachment; filename="Rudolf Hornig (E-mail).vcf" Content-transfer-encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Hornig;Rudolf FN:Rudolf Hornig (E-mail) ORG:MeTechnology Ltd. (Hungary) - a Brokat Company;Research&Development TITLE:Project Manager TEL;WORK;VOICE:+36 (1) 437 04 13 TEL;WORK;FAX:+36 (1) 387 37 98 ADR;WORK:;;Kunigunda utca 58.;Budapest;;H1037;Hungary LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Kunigunda utca 58.=0D=0ABudapest H1037=0D=0AHungary KEY;X509;ENCODING=BASE64: MIICjDCCAfWgAwIBAgIDAUf1MA0GCSqGSIb3DQEBBAUAMIG5MQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3 OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4 LjkuMTYwHhcNOTkwODI0MDg0MDA3WhcNMDAwODIzMDg0MDA3WjBJMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdydWRvbGZATWVUZWNobm9sb2d5 LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDH8coNT3BGTG4HGqz08KaFHSjONYQ6BLta HwjWmfH0j+M/hQp86tPpLB73RQjDt5lsbb/EkzGA6QShkabMQyBLAgMBAAGjVTBTMCIGA1Ud EQQbMBmBF3J1ZG9sZkBNZVRlY2hub2xvZ3kuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEACHlsv89kEhISAVFs 1TdW9KKW8kluUJDjC7DDnAEgiCLw6mlm2kvHW3NzYONaefEsCBOsYVOIOBg4RW15HCR4+eay dEuGJXi510jSc2DN/uyYjNB4okvGKYl/zEbgTqJFEUEjwHtSFDIspCbufD1bj4I0/GQc1+fP Vv/VePfpVqo= EMAIL;PREF;INTERNET:rudolf@MeTechnology.com REV:19990830T133416Z END:VCARD --Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400201VB836@eListX.com>; Wed, 8 Mar 2000 21:37:56 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400201VB635@eListX.com> (original mail from ron@paybycheck.com); Wed, 08 Mar 2000 21:37:55 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400203VB632@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 21:37:54 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400201VB531@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 21:37:53 -0500 (EST) Received: from paybycheck.com ([208.49.29.160]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR40006ZVB37A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 21:37:52 -0500 (EST) Received: from zort [10.10.10.133] by paybycheck.com (SMTPD32-6.00) id ADF53860050; Wed, 08 Mar 2000 18:35:33 -0800 Date: Wed, 08 Mar 2000 18:37:16 -0800 From: Ron Ehli Subject: RE: IOTP implementations In-reply-to: <200003090030.TAA13544@torque.pothole.com> To: ietf-trade@lists.eListX.com Message-id: <003501bf8970$624b55b0$850a0a0a@zort.itinternet.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal PayByCheck.com is also implementing IOTP 1.0 for select services. > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: Wednesday, March 08, 2000 4:31 PM > To: dbourget@videotron.ca > Cc: ietf-trade@lists.eListX.com > Subject: Re: IOTP implementations > > > > As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal > Bank of Canada. > > The following have said they are implementing IOTP 1.0: > Hitachi (SMILE Project) > Royal Bank of Canada > SIZ > CyberSource > Differential > Xenosys Corporation > > Donald > > From: David Bourget > Resent-From: ietf-trade-errors@lists.eListX.com > Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST) > Date: Wed, 08 Mar 2000 15:44:07 -0500 > Sender: services@eListX.com > To: ietf-trade@lists.eListX.com > Reply-to: dbourget@videotron.ca > Resent-message-id: <0FR400002GEDQG@eListX.com> > Message-id: <20000308154407.B1997@davidspirit.brg> > > >Hi, > > > >Could someone give me some pointers on early IOTP > implementations ? Is there any ? > > > >/David > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400101PIFNB@eListX.com>; Wed, 8 Mar 2000 19:32:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400101PIFNA@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 08 Mar 2000 19:32:39 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400103PIFN8@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 19:32:39 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400101PIEN7@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 19:32:38 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR400056PIC7A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 19:32:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id TAA13544; Wed, 08 Mar 2000 19:30:59 -0500 (EST) Date: Wed, 08 Mar 2000 19:30:59 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: IOTP implementations In-reply-to: "Your message of Wed, 08 Mar 2000 15:44:07 EST." <20000308154407.B1997@davidspirit.brg> To: dbourget@videotron.ca Cc: ietf-trade@lists.eListX.com Message-id: <200003090030.TAA13544@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal Bank of Canada. The following have said they are implementing IOTP 1.0: Hitachi (SMILE Project) Royal Bank of Canada SIZ CyberSource Differential Xenosys Corporation Donald From: David Bourget Resent-From: ietf-trade-errors@lists.eListX.com Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST) Date: Wed, 08 Mar 2000 15:44:07 -0500 Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR400002GEDQG@eListX.com> Message-id: <20000308154407.B1997@davidspirit.brg> >Hi, > >Could someone give me some pointers on early IOTP implementations ? Is there any ? > >/David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEEQK@eListX.com>; Wed, 8 Mar 2000 16:15:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEEQJ@eListX.com> (original mail from services@eListX.com); Wed, 08 Mar 2000 16:15:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400003GEDQH@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 16:15:49 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEDQG@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 16:15:49 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEDQF@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 16:15:49 -0500 (EST) Received: from davidspirit.brg (modemcable123.182-200-24.que.mc.videotron.net [24.200.182.123]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR40001JF0Z7A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 15:46:15 -0500 (EST) Received: (qmail 2021 invoked by uid 500); Wed, 08 Mar 2000 20:44:07 +0000 Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST) Date: Wed, 08 Mar 2000 15:44:07 -0500 From: David Bourget Subject: IOTP implementations Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR400002GEDQG@eListX.com> Message-id: <20000308154407.B1997@davidspirit.brg> MIME-version: 1.0 X-Mailer: Mutt 1.0pre2i Content-type: text/plain; charset=us-ascii Hi, Could someone give me some pointers on early IOTP implementations ? Is there any ? /David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001DZ8HQ@eListX.com>; Wed, 8 Mar 2000 15:23:32 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001DZ7HP@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 08 Mar 2000 15:23:31 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400003DZ7HN@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 15:23:31 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001DZ6HM@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 15:23:31 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR40001ADZ47A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 15:23:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id PAA12759 for ietf-trade@lists.elistx.com; Wed, 08 Mar 2000 15:21:45 -0500 (EST) Date: Wed, 08 Mar 2000 15:21:45 -0500 From: "Donald E. Eastlake 3rd" Subject: APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003082021.PAA12759@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp I went ahead and sent APPLICATION/IOTP to the IETF-Types list, like you are supposed to for new MIME types, and Ned Freed, who is the type czar, thinks its OK. draft-ietf-trade-iotp-http-04.txt still needs to be approved by the IESG. Donald ------- Forwarded Message From: ned.freed@innosoft.com Date: Wed, 08 Mar 2000 12:09:27 -0800 (PST) Subject: Re: Registration of MIME media type APPLICATION/IOTP In-reply-to: "Your message dated Wed, 08 Mar 2000 14:59:59 -0500" <200003081959.OAA12922@torque.pothole.com> To: "Donald E. Eastlake 3rd" Cc: ietf-types@uninett.no, dee3@torque.pothole.com Message-id: <01JMSFWMB7CG000O8C@MAUVE.INNOSOFT.COM> This registration looks fine to me. Ned > [See also draft-ietf-trade-iotp-http-04.txt] > MIME media type name: APPLICATION > MIME subtype name: IOTP > Required parameters: (none) > Optional parameters: (none) > Encoding considerations: Content is XML and may in some cases > require quoted printable or base64 encoding. However, no encoding > is required for HTTP transport which is expected to be common. > Security considerations: IOTP includes provisions for digital > authentication but for confidentiality, other mechanisms such as > TLS should be used. See Security Consideration section of > draft-ietf-trade-iotp-v1.0-protocol-07.txt in RFC Editor's queue. > Interoperability considerations: See draft-ietf-trade-iotp-v1.0- > protocol-07.txt in RFC Editor's queue. > Published specification: See draft-ietf-trade-iotp-v1.0-protocol- > 07.txt in RFC Editor's queue. > Applications which use this media type: Internet Open Trading > Protocol applications. > Additional information: (none) > Person & email address to contact for further information: > Name: Donald E. Eastlake 3rd > Email: Donald.Eastlake@motorola.com > Intended usage: COMMON > Author/Change controller: IETF > ===================================================================== > Donald E. Eastlake 3rd dee3@torque.pothole.com > 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) > Carmel, NY 10512 USA +1 508-261-5434(w) ------- End of Forwarded Message Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100101UP6OW@eListX.com>; Tue, 7 Mar 2000 06:31:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100101UP5OV@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Tue, 07 Mar 2000 06:31:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100103UP5OT@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 07 Mar 2000 06:31:53 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100101UP5OS@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 07 Mar 2000 06:31:53 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR100M7GUP41I@eListX.com> for ietf-trade@lists.eListX.com; Tue, 07 Mar 2000 06:31:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29267; Tue, 07 Mar 2000 06:29:36 -0500 (EST) Date: Tue, 07 Mar 2000 06:29:35 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-http-04.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003071129.GAA29267@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)" --Boundary_(ID_QkGemhOeIA11z+6ONPAmBw) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Internet Open Trading Protocol (IOTP) HTTP Supplement Author(s) : D. Eastlake 3rd, C. Smith Filename : draft-ietf-trade-iotp-http-04.txt Pages : 9 Date : 06-Mar-00 Internet Open Trading Protocol (IOTP [draft-ietf-trade-iotp-v1.0- protocol-*.txt]) messages will be carried as XML documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This documents describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-http-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-http-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_QkGemhOeIA11z+6ONPAmBw) Content-type: multipart/alternative; boundary="Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)" --Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt --Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w) Content-type: Message/External-body; name="draft-ietf-trade-iotp-http-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120547.I-D@ietf.org> --Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)-- --Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00401YKPGC@eListX.com>; Fri, 3 Mar 2000 00:14:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00401YKPGB@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Fri, 03 Mar 2000 00:14:49 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00403YKPG9@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 03 Mar 2000 00:14:49 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00401YKOG8@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 03 Mar 2000 00:14:48 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQT001CAYKL49@eListX.com> for ietf-trade@lists.eListX.com; Fri, 03 Mar 2000 00:14:48 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id OAA27454; Fri, 03 Mar 2000 14:12:31 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/13/00) with ESMTP id OAA05785; Fri, 03 Mar 2000 14:12:22 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by renoir.isl.ntt.co.jp (8.8.8/isl-2.0) id OAA01005; Fri, 03 Mar 2000 14:12:08 +0900 (JST) Date: Fri, 03 Mar 2000 14:12:08 +0900 From: Ko Fujimura Subject: Re: Has any agenda come out In-reply-to: "In your message of Wed, 01 Mar 2000 22:03:24 -0500" <200003020303.WAA05084@torque.pothole.com> To: dee3@torque.pothole.com Cc: ietf-trade@lists.eListX.com Message-id: MIME-version: 1.0 (generated by REMI 1.14.0 - "Uragawara") Content-type: text/plain; charset=US-ASCII User-Agent: REMI/1.14.0 (Uragawara) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) APEL/10.1 MULE XEmacs/21.2 (beta31) (Iris) (sparc-sun-solaris2.6) References: <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> <200003020303.WAA05084@torque.pothole.com> At Wed, 01 Mar 2000 22:03:24 -0500, Donald E. Eastlake 3rd wrote: > > Nope. I'll try to get a preliminary one out soon. People are welcom > to send me suggestions. I would like to have time to talk about the objective of digital-right trading briefly again, and discuss on the major requirements, e.g., necessity of transferability, introduction of a parameter in the digital-right definition language to select digital-right trading protocol. I think it will need about 20 minute. Is there anyone else who would like to talk about on digital-right trading? I'm also very interested in the requirements for ECML version 2. I'm looking forward to see the draft. Regards, Ko ---------------------------------------------------------- Ko Fujimura, NTT Information Sharing Platform Laboratories 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-8329 Email: fujimura@isl.ntt.co.jp Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01XYKZ9@eListX.com>; Wed, 1 Mar 2000 22:06:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01XYKZ8@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 01 Mar 2000 22:06:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K03XYJZ6@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 22:06:19 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01XYJZ5@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 22:06:19 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQR00IG2XYG3V@eListX.com> for ietf-trade@lists.eListX.com; Wed, 01 Mar 2000 22:06:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id WAA05084; Wed, 01 Mar 2000 22:03:24 -0500 (EST) Date: Wed, 01 Mar 2000 22:03:24 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: Has any agenda come out In-reply-to: "Your message of Thu, 02 Mar 2000 13:12:25 +1030." <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> To: Chun OUYANG Cc: ietf-trade@lists.eListX.com Message-id: <200003020303.WAA05084@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp Nope. I'll try to get a preliminary one out soon. People are welcom to send me suggestions. Thanks, Donald From: Chun OUYANG Date: Thu, 02 Mar 2000 13:12:25 +1030 Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> Organization: ITR >Has any agenda of trade WG in the coming IETF come out? > >Chun Ouyang > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01W36TQ@eListX.com>; Wed, 1 Mar 2000 21:25:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01W35TP@eListX.com> (original mail from ouyang@SPRI.Levels.UniSA.Edu.Au); Wed, 01 Mar 2000 21:25:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K03W35TN@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 21:25:53 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01W35TM@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 21:25:53 -0500 (EST) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQR00IFQW313V@eListX.com> for ietf-trade@lists.eListX.com; Wed, 01 Mar 2000 21:25:52 -0500 (EST) Received: from spri.levels.unisa.edu.au (ouyang@brezhnev [172.17.0.22]) by server1.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id MAA28560 for ; Thu, 02 Mar 2000 12:53:12 +1030 (CST) Date: Thu, 02 Mar 2000 13:12:25 +1030 From: Chun OUYANG Subject: Has any agenda come out Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> Organization: ITR MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Has any agenda of trade WG in the coming IETF come out? Chun Ouyang Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01UJYMJ@eListX.com>; Wed, 1 Mar 2000 20:52:47 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01UJYMI@eListX.com> (original mail from blondeau@exoffice.com) ; Wed, 01 Mar 2000 20:52:46 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K03UJXMG@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 01 Mar 2000 20:52:45 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01UJXMF@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 01 Mar 2000 20:52:45 -0500 (EST) Received: from titan.exoffice.com (host98.ridgeventures.com [207.33.160.98]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQR00IEUUJW3V@eListX.com> for ietf-trade@lists.eListX.com; Wed, 01 Mar 2000 20:52:45 -0500 (EST) Received: from aquarium (fwin.exoffice.com [207.33.160.97]) by titan.exoffice.com (8.9.3/8.9.3) with SMTP id RAA05433 for ; Wed, 01 Mar 2000 17:50:35 -0800 Date: Wed, 01 Mar 2000 17:46:26 -0800 From: David Blondeau Subject: [ietf-trade] OT: This is a test To: ietf-trade@lists.eListX.com Message-id: <009301bf83e9$1f74a520$1101a8c0@aquarium> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)" X-Priority: 3 X-MSMail-priority: Normal This is a multi-part message in MIME format. --Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable As I didn't receive any mail since I have subscribed (5 days), I make a = test=20 David Blondeau --Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ) Content-type: text/html; charset="iso-8859-1" Content-transfer-encoding: quoted-printable
As I didn't receive any mail since I = have=20 subscribed (5 days), I make a test
David = Blondeau
--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01G09JS@eListX.com>; Thu, 30 Mar 2000 06:31:21 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01G08JR@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 30 Mar 2000 06:31:21 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L03G08JP@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:31:20 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01G08JO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:31:20 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS800L0LG069O@eListX.com> for ietf-trade@lists.eListX.com; Thu, 30 Mar 2000 06:31:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id GAA10718; Thu, 30 Mar 2000 06:28:07 -0500 (EST) Date: Thu, 30 Mar 2000 06:28:07 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: Document changes Oct 99 - March 2000 In-reply-to: "Your message of Wed, 29 Mar 2000 09:11:59 +0100." <38E1BACF.D1EE84C9@hplb.hpl.hp.com> To: Russell Perry Cc: ietf-trade@lists.eListX.com Message-id: <200003301128.GAA10718@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp The draft-ietf-trade-iotp-v1.0-protocol-07.txt draft is the final draft for the V1.0 of IOTP and will be out as an RFC soon. The -papi- draft is a little out of date but is expected to be updated within a month. After than happens, the SET Supplement will be updated. Donald From: Russell Perry Date: Wed, 29 Mar 2000 09:11:59 +0100 To: ietf-trade@lists.eListX.com Message-id: <38E1BACF.D1EE84C9@hplb.hpl.hp.com> >Hi, > >I'm looking for some help to clarify some of the apparent discrepancies >between the following documents: >draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and >draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000). For example, >several element tags are not specified in the latter document. Is this >because both documents should be read together, or does it reflect the >evolution of the protocol? > >Also, am I right in assuming that the running footer of "*papi-00.txt" >(SET supplement...) is a typo, or is there a more sinister explanation >:) Thanks. > > >Regards, > >Russ. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01FP4IS@eListX.com>; Thu, 30 Mar 2000 06:24:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01FP4IR@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 30 Mar 2000 06:24:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L03FP3IP@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:24:39 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L01FP3IO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 06:24:39 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS800L0IFP19O@eListX.com> for ietf-trade@lists.eListX.com; Thu, 30 Mar 2000 06:24:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id GAA10606; Thu, 30 Mar 2000 06:22:37 -0500 (EST) Date: Thu, 30 Mar 2000 06:22:37 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: IOTP meeting in 47th IETF In-reply-to: "Your message of Thu, 30 Mar 2000 19:00:24 +0930." <38E31EB0.C87CF77A@spri.levels.unisa.edu.au> To: Chun OUYANG Cc: ietf-trade@lists.eListX.com Message-id: <200003301122.GAA10606@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp Thanks for your note. The draft of the official minutes will be posted shortly. Actually, it's the IOTP HTTP Supplement and the MIME Handler Detector drafts that I plan to working group Last Call soon, after one more revision. It the working group is satisfied, they would then be forwarded to the IESG. It will be a while before IOTP v2.0. B2BXML was a BoF also held at this IETF meeting. Donald From: Chun OUYANG Date: Thu, 30 Mar 2000 19:00:24 +0930 Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38E31EB0.C87CF77A@spri.levels.unisa.edu.au> Organization: ITR >FYI, > >... > >PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon. > 2. xml dsig and b2b xml were also discussed in this IETF meeting. > >Thanks, > >Chun > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0198L49@eListX.com>; Thu, 30 Mar 2000 04:05:09 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0198K48@eListX.com> (original mail from ouyang@SPRI.Levels.UniSA.Edu.Au); Thu, 30 Mar 2000 04:05:08 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0398K46@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 04:05:08 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS800L0198J45@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 30 Mar 2000 04:05:07 -0500 (EST) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS800HFZ98C05@eListX.com> for ietf-trade@lists.eListX.com; Thu, 30 Mar 2000 04:05:07 -0500 (EST) Received: from spri.levels.unisa.edu.au (ouyang@brezhnev [172.17.0.22]) by server1.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id SAA03374 for ; Thu, 30 Mar 2000 18:32:01 +0930 (CST) Date: Thu, 30 Mar 2000 19:00:24 +0930 From: Chun OUYANG Subject: IOTP meeting in 47th IETF Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38E31EB0.C87CF77A@spri.levels.unisa.edu.au> Organization: ITR MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , FYI, Trade WG held its meeting in 47th IETF (http://www.ietf.org/meetings/IETF-47.html) yesterday afternoon. IOTP and its related protocols have been discussed. The Chair, Sir Donald Eastlake, organized the meeting and gave an overview of IOTPs, the history and future. An presentation on DRT was given by Mr. Ko Fujimura from NTT. Here is both the good news and bad news for IOTP. The good news is it will soon become an informational RFC; the bad news is, then it will be the longest RFC document in IETF, according to Patrik, one of the ADs in Applications Area. Could I said boldly that as there isnt any standardized interoperable framework for EC on Internet except IOTP, I do hope that it can be a robust architecure for EC with world-wide popularity in the future. Thanks a lot to Yoshiaki and Andrew from Hitachi for the very nice talk with them on IOTP. Hopefully to have more discussion with the people interested in IOTP, EC or related issues in the future. Furthermore, it couldnt be better if some gurus can give their advice to me, in my future work on IOTP. PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon. 2. xml dsig and b2b xml were also discussed in this IETF meeting. Thanks, Chun Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G01C9KR6@eListX.com>; Wed, 29 Mar 2000 03:15:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G01C9JR5@eListX.com> (original mail from rp@hplb.hpl.hp.com); Wed, 29 Mar 2000 03:15:19 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G03C9JR3@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 29 Mar 2000 03:15:19 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS600G01C9IR2@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 29 Mar 2000 03:15:18 -0500 (EST) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS600CF3C9IPC@eListX.com> for ietf-trade@lists.eListX.com; Wed, 29 Mar 2000 03:15:18 -0500 (EST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 68EB71A70 for ; Wed, 29 Mar 2000 03:12:28 -0500 (EST) Received: from hplb.hpl.hp.com (perry-r-1.hpl.hp.com [15.144.90.85]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id JAA28487 for ; Wed, 29 Mar 2000 09:12:26 +0100 (BST) Date: Wed, 29 Mar 2000 09:11:59 +0100 From: Russell Perry Subject: Document changes Oct 99 - March 2000 To: ietf-trade@lists.eListX.com Message-id: <38E1BACF.D1EE84C9@hplb.hpl.hp.com> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Hi, I'm looking for some help to clarify some of the apparent discrepancies between the following documents: draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000). For example, several element tags are not specified in the latter document. Is this because both documents should be read together, or does it reflect the evolution of the protocol? Also, am I right in assuming that the running footer of "*papi-00.txt" (SET supplement...) is a typo, or is there a more sinister explanation :) Thanks. Regards, Russ. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F01SD0DY@eListX.com>; Tue, 28 Mar 2000 20:05:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F01SCZDX@eListX.com> (original mail from david.burdett@commerceone.com); Tue, 28 Mar 2000 20:05:23 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F03SCZDV@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 28 Mar 2000 20:05:23 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FS500F01SCYDU@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 28 Mar 2000 20:05:22 -0500 (EST) Received: from c1plenaexi02.commerceone.com ([12.22.60.1]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FS500CA4SCXPC@eListX.com> for ietf-trade@lists.eListX.com; Tue, 28 Mar 2000 20:05:22 -0500 (EST) Received: by c1plenaexi02.commerceone.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 16:59:02 -0800 Content-return: allowed Date: Tue, 28 Mar 2000 17:02:30 -0800 From: David Burdett Subject: RE: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.tx t" To: 'Shinji Kikuchi' , ietf-trade@lists.eListX.com Message-id: <80CB4C7E7DE1D311950600508BA5831F5C6DA6@neptune.commerceone.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-2022-jp" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Comments inline marked with ## ... David -----Original Message----- From: Shinji Kikuchi [mailto:s-kikuti@ccs.mt.nec.co.jp] Sent: Thursday, March 23, 2000 3:33 AM To: ietf-trade@lists.eListX.com Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt" Dear Sirs I'm just a new commer to this mailing list. Actually, I have several questions on the document of "draft-ietf-trade-xmlmsg-requirements-00.txt" . Could anyone let me know the right ideas to below items, please ? 1)First, according to the description in the document, around "2.2.4 Document Choreography", we MUST(?) set some descriptions regarding controling sequence or selection, inside of Messages, in particular, in the case of "Explicit". The most suitable part for it or associated with it inside messages seems to be "Message Routing Information" part , I guess. However, according to the description around "2.1.7 Message Routing Information", I feel a little bits difference due to below . By the only description with " Each 'hop' results in another entry.." seems to result in eventually "Peer to Peer" in each interaction in "Hub" way. Therefore, still hard to get idea regarding relationship between Routing matter and Document Choreography clearly, unfortunetely. If there were more details of it, it would be more clear, I think. Anyway, is it right idea, or misunderstanding absolutely ? ##In my view, choreography, is one of the hardest areas to do. Also by using implicit choreography, then typcially these days the choreography is hard coded into the applications that send/receive the messages.## 2)Next, please suggest the future plan or current status regarding other parts of this series. According to this specification document, Other 7 parts have been planned. Actually, I am interesting in Secure Messaging Part [XMLMSG-SM]. I am minding that status, now. So, please let me know it, if possible. ##Much of the work on XML messaging is currently being done within the auspices of ebXML. See http://www.ebxml.org/project_teams/transport.htm for more details.## Thanks, S.Kikuchi. Regards ---------------------------------------------------------- Shinji Kikuchi @ NEC Corp. Client-Server Software Labs. Development Environment Lab. Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN) Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K723Q@eListX.com>; Thu, 23 Mar 2000 07:33:02 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K713P@eListX.com> (original mail from services@eListX.com); Thu, 23 Mar 2000 07:33:01 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E03K713N@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 23 Mar 2000 07:33:01 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K713M@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 23 Mar 2000 07:33:01 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FRV00E01K703L@eListX.com> for ietf-trade@lists.eListX.com; Thu, 23 Mar 2000 07:33:00 -0500 (EST) Received: from TYO203.gate.nec.co.jp (TYO203.gate.nec.co.jp [202.32.8.211]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRV00ABBI9U4F@eListX.com> for ietf-trade@lists.eListX.com; Thu, 23 Mar 2000 06:51:32 -0500 (EST) Received: from mailsv.nec.co.jp (mailsv-le1 [192.168.1.90]) by TYO203.gate.nec.co.jp (8.9.3/3.7W00031314) with ESMTP id UAA17918 for ; Thu, 23 Mar 2000 20:48:49 +0900 (JST) Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.4.2]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id UAA07704 for ; Thu, 23 Mar 2000 20:48:48 +0900 (JST) Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.9.3/3.7W-GW_CCS) with ESMTP id UAA04360 for ; Thu, 23 Mar 2000 20:48:48 +0900 (JST) Received: from splpe851.ccs.mt.nec.co.jp (splpe851.ccs.mt.nec.co.jp [172.16.14.20]) by mail.ccs.mt.nec.co.jp (8.9.1a/3.6W-CCS_Master) with ESMTP id UAA17843 for ; Thu, 23 Mar 2000 20:48:47 +0900 (JST) Received: from splpe948 (splpe948.ccs.mt.nec.co.jp [172.16.14.191]) by splpe851.ccs.mt.nec.co.jp (8.9.3/3.7W-CSSL-99030622) with SMTP id UAA19396 for ; Thu, 23 Mar 2000 20:48:47 +0900 (JST) Resent-date: Thu, 23 Mar 2000 07:33:00 -0500 (EST) Date: Thu, 23 Mar 2000 20:33:03 +0900 From: Shinji Kikuchi Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt" Sender: services@eListX.com To: ietf-trade@lists.eListX.com Resent-message-id: <0FRV00E02K713M@eListX.com> Message-id: <022701bf94bb$8d64ec60$bf0e10ac@ccs.mt.nec.co.jp> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Dear Sirs I'm just a new commer to this mailing list. Actually, I have several questions on the document of "draft-ietf-trade-xmlmsg-requirements-00.txt" . Could anyone let me know the right ideas to below items, please ? 1)First, according to the description in the document, around "2.2.4 Document Choreography", we MUST(?) set some descriptions regarding controling sequence or selection, inside of Messages, in particular, in the case of "Explicit". The most suitable part for it or associated with it inside messages seems to be "Message Routing Information" part , I guess. However, according to the description around "2.1.7 Message Routing Information", I feel a little bits difference due to below . By the only description with " Each 'hop' results in another entry.." seems to result in eventually "Peer to Peer" in each interaction in "Hub" way. Therefore, still hard to get idea regarding relationship between Routing matter and Document Choreography clearly, unfortunetely. If there were more details of it, it would be more clear, I think. Anyway, is it right idea, or misunderstanding absolutely ? 2)Next, please suggest the future plan or current status regarding other parts of this series. According to this specification document, Other 7 parts have been planned. Actually, I am interesting in Secure Messaging Part [XMLMSG-SM]. I am minding that status, now. So, please let me know it, if possible. Thanks, S.Kikuchi. Regards ---------------------------------------------------------- Shinji Kikuchi @ NEC Corp. Client-Server Software Labs. Development Environment Lab. Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN) Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00501COCT5@eListX.com>; Tue, 21 Mar 2000 13:57:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00501COCT4@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Tue, 21 Mar 2000 13:57:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00503COBT2@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 21 Mar 2000 13:57:47 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS00501COBT1@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 21 Mar 2000 13:57:47 -0500 (EST) Received: from smtp2.royalbank.com (smtp2.royalbank.com [198.96.131.29]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FRS0051ZCOA9H@eListX.com> for ietf-trade@lists.eListX.com; Tue, 21 Mar 2000 13:57:47 -0500 (EST) Received: from wsecure4.royalbank.com by smtp2.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Tue, 21 Mar 2000 18:55:20 +0000 (UT) Received: from 10.224.0.66 by se001018.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 21 Mar 2000 13:55:06 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2650.21) id ; Tue, 21 Mar 2000 13:55:06 -0500 Date: Tue, 21 Mar 2000 13:55:04 -0500 From: "Smith, Chris " Subject: RE: Yet more on APPLICATION/IOTP To: "'Donald E. Eastlake 3rd'" , ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B47@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 14C91A00829551-01-01 List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Call me conservative on this one - since there was not yet a formal decision on the matter, we have continued to use APPLICATION/X-IOTP even for IOTP 1.0 (which also is not returned from the editor's desk with an RFC number). I realize that I should probably join the ietf-types mailing list to find this out, but ... is there any ideas on an alternate way besides modifying the actual MIME type to indicate that XML is in use? If there were, I would prefer... APPLICATION/IOTP ...with a charset parameter ...with an encoding or markup parameter The other alternative - a really big one, at that - would be to use: XML/IOTP ...with a charset parameter ..to my mind, this better captures the actual idea of what is happening here. This is much the same as using IMAGE/ or TEXT/ where the /xxx "sub-describes" the higher level item. ------------------------------------------------------------=20 =A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090=20 =A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com=20 =20 > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: March 21, 2000 09:34 AM > To: ietf-trade@lists.eListX.com > Subject: Yet more on APPLICATION/IOTP >=20 >=20 >=20 > There continues to be an incredible blizzard of messages on the > ietf-types mailing list about whether "-xml" suffixes or the like on > MIME types is good or bad, etc. In general, the weight of the > argument seems to be in favor of this... So the question is would > changing to application/iotp-xml be a hardship on current > implementations and implementation efforts? (Early efforts used > APPLICATION/X-IOTP.) >=20 > Also, it turns out that Section F of the XML spec has been changed. > External charset indications, such as an optional charset = Content-Type > parameter, if present, over-ride and internal indication of character > encoding in XML, as specified in Informational RFC 2376. So if there > is an optional charset option, which is probably a good idea, then > when present, it should over-riode any encoding specification > appearing before the XML document unless we wnat to be = non-standard... >=20 > Donald >=20 >=20 > ------- Forwarded Message >=20 > Date: Thu, 09 Mar 2000 23:49:47 -0500 > From: "Donald E. Eastlake 3rd" > Subject: More on APPLICATION/IOTP > To: ietf-trade@lists.eListX.com > Message-id: <200003100449.XAA27249@torque.pothole.com> >=20 > The MIME type registartion template I posted to the ietf-types list > has caused a lot of comment. None of it is really about IOTP, it > is all about two issues: > (1) should it really be APPLICATION/IOTP-XML > and > (2) should it allow/require a charset parameter >=20 > That is, people are arguing about whether all new XML content MIME > types should have a subtype with a "-xml" on the end. I would > assume we don't want to change due to existing implementations. >=20 > On the charset paramter issue, I think I should add it as an > optional parameter. Section F of the XML 1.0 specification makes > it clear that the charset as indicated by the actual data > including any byte order mark and encoding declaration and that > any "external" charset, as the charset parameter would be, is > "solely for error recovery." >=20 > Thanks, > donald > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd dee3@torque.pothole.com > 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) > Carmel, NY 10512 USA +1 508-261-5434(w) >=20 > ------- End of Forwarded Message >=20 >=20 > --JAA02481.953649127/torque.pothole.com-- >=20 >=20 > ------- End of Forwarded Message >=20 >=20 --Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: Yet more on APPLICATION/IOTP

Call me conservative on this one - since there was = not yet a formal
decision on the matter, we have continued to use = APPLICATION/X-IOTP
even for IOTP 1.0 (which also is not returned from = the editor's desk
with an RFC number).

I realize that I should probably join the ietf-types = mailing list
to find this out, but ... is there any ideas on an = alternate way
besides modifying the actual MIME type to indicate = that XML is in
use?

If there were, I would prefer...

   APPLICATION/IOTP
   ...with a charset parameter
   ...with an encoding or markup = parameter

The other alternative - a really big one, at that - = would be
to use:

   XML/IOTP
   ...with a charset parameter

..to my mind, this better captures the actual idea of = what is
happening here. This is much the same as using = IMAGE/ or TEXT/
where the /xxx "sub-describes" the higher = level item.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com


  


> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
> Sent: March 21, 2000 09:34 AM
> To: ietf-trade@lists.eListX.com
> Subject: Yet more on APPLICATION/IOTP
>
>
>
> There continues to be an incredible blizzard of = messages on the
> ietf-types mailing list about whether = "-xml" suffixes or the like on
> MIME types is good or bad, etc.  In = general, the weight of the
> argument seems to be in favor of this...  = So the question is would
> changing to application/iotp-xml be a hardship = on current
> implementations and implementation = efforts?  (Early efforts used
> APPLICATION/X-IOTP.)
>
> Also, it turns out that Section F of the XML = spec has been changed.
> External charset indications, such as an = optional charset Content-Type
> parameter, if present, over-ride and internal = indication of character
> encoding in XML, as specified in Informational = RFC 2376.  So if there
> is an optional charset option, which is = probably a good idea, then
> when present, it should over-riode any encoding = specification
> appearing before the XML document unless we = wnat to be non-standard...
>
> Donald
>
>
> ------- Forwarded Message
>
> Date:  Thu, 09 Mar 2000 23:49:47 = -0500
> From:  "Donald E. Eastlake 3rd" = <dee3@torque.pothole.com>
> Subject:  More on APPLICATION/IOTP
> To:  ietf-trade@lists.eListX.com
> Message-id:  = <200003100449.XAA27249@torque.pothole.com>
>
> The MIME type registartion template I posted to = the ietf-types list
> has caused a lot of comment.  None of it = is really about IOTP, it
> is all about two issues:
> (1) should it really be = APPLICATION/IOTP-XML
> and
> (2) should it allow/require a charset = parameter
>
> That is, people are arguing about whether all = new XML content MIME
> types should have a subtype with a = "-xml" on the end.  I would
> assume we don't want to change due to existing = implementations.
>
> On the charset paramter issue, I think I should = add it as an
> optional parameter.  Section F of the XML = 1.0 specification makes
> it clear that the charset as indicated by the = actual data
> including any byte order mark and encoding = declaration and that
> any "external" charset, as the = charset parameter would be, is
> "solely for error recovery."
>
> Thanks,
> donald
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  Donald E. Eastlake = 3rd           &nb= sp;          = dee3@torque.pothole.com
>  65 Shindegan Hill Road, = RR#1           &n= bsp;         +1 = 914-276-2668(h)
>  Carmel, NY 10512 = USA           &nb= sp;           &nb= sp;     +1 508-261-5434(w)
>
> ------- End of Forwarded Message
>
>
> = --JAA02481.953649127/torque.pothole.com--
>
>
> ------- End of Forwarded Message
>
>

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004010K3SM@eListX.com>; Tue, 21 Mar 2000 09:36:03 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004010K2SL@eListX.com> (original mail from dee3@torque.pothole.com) ; Tue, 21 Mar 2000 09:36:02 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004030K2SJ@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Tue, 21 Mar 2000 09:36:02 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRS004010K1SI@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Tue, 21 Mar 2000 09:36:01 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRS000FU0JY12@eListX.com> for ietf-trade@lists.eListX.com; Tue, 21 Mar 2000 09:36:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id JAA02507 for ietf-trade@lists.elistx.com; Tue, 21 Mar 2000 09:34:15 -0500 (EST) Date: Tue, 21 Mar 2000 09:34:15 -0500 From: "Donald E. Eastlake 3rd" Subject: Yet more on APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003211434.JAA02507@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp There continues to be an incredible blizzard of messages on the ietf-types mailing list about whether "-xml" suffixes or the like on MIME types is good or bad, etc. In general, the weight of the argument seems to be in favor of this... So the question is would changing to application/iotp-xml be a hardship on current implementations and implementation efforts? (Early efforts used APPLICATION/X-IOTP.) Also, it turns out that Section F of the XML spec has been changed. External charset indications, such as an optional charset Content-Type parameter, if present, over-ride and internal indication of character encoding in XML, as specified in Informational RFC 2376. So if there is an optional charset option, which is probably a good idea, then when present, it should over-riode any encoding specification appearing before the XML document unless we wnat to be non-standard... Donald ------- Forwarded Message Date: Thu, 09 Mar 2000 23:49:47 -0500 From: "Donald E. Eastlake 3rd" Subject: More on APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003100449.XAA27249@torque.pothole.com> The MIME type registartion template I posted to the ietf-types list has caused a lot of comment. None of it is really about IOTP, it is all about two issues: (1) should it really be APPLICATION/IOTP-XML and (2) should it allow/require a charset parameter That is, people are arguing about whether all new XML content MIME types should have a subtype with a "-xml" on the end. I would assume we don't want to change due to existing implementations. On the charset paramter issue, I think I should add it as an optional parameter. Section F of the XML 1.0 specification makes it clear that the charset as indicated by the actual data including any byte order mark and encoding declaration and that any "external" charset, as the charset parameter would be, is "solely for error recovery." Thanks, donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) Carmel, NY 10512 USA +1 508-261-5434(w) ------- End of Forwarded Message --JAA02481.953649127/torque.pothole.com-- ------- End of Forwarded Message Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9YXN@eListX.com>; Mon, 13 Mar 2000 06:22:46 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9XXM@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Mon, 13 Mar 2000 06:22:46 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00703Y9XXK@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:45 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9WXJ@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:44 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRC0027VY9VE7@eListX.com> for ietf-trade@lists.eListX.com; Mon, 13 Mar 2000 06:22:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15659; Mon, 13 Mar 2000 06:20:19 -0500 (EST) Date: Mon, 13 Mar 2000 06:20:18 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-set-00.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003131120.GAA15659@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)" --Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Author(s) : Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-set-00.txt Pages : 58 Date : 10-Mar-00 This document describes detailed Input/Output parameter for the IOTP Payment API and a procedure in the Payment Bridge for use SET as the payment protocol within Version 1.0 of the Internet Open Trading Protocol (IOTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-set-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg) Content-type: multipart/alternative; boundary="Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)" --Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310140405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt --Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA) Content-type: Message/External-body; name="draft-ietf-trade-iotp-v1.0-set-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310140405.I-D@ietf.org> --Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)-- --Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9SXE@eListX.com>; Mon, 13 Mar 2000 06:22:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9RXD@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Mon, 13 Mar 2000 06:22:39 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00703Y9RXB@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:39 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00701Y9QXA@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 06:22:38 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRC0027SY9PE7@eListX.com> for ietf-trade@lists.eListX.com; Mon, 13 Mar 2000 06:22:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15633; Mon, 13 Mar 2000 06:20:13 -0500 (EST) Date: Mon, 13 Mar 2000 06:20:13 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-papi-00.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003131120.GAA15633@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)" --Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Architecture and Payment API for Internet Open Trading Protocol (IOTP) Author(s) : W. Hans, H. Beykirch, M. Hiroya, Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-papi-00.txt Pages : 143 Date : 10-Mar-00 The Trading Architecture proposes an abstract layered model of the IOTP based trading environment. Its description sketches the essential functional and data modules and their interfaces at each trading role's installation. This abstract view deals as a guideline for the modules' mapping to actual software modules. The second part of this document focuses on the Payment API that improves the essential interface that relates to payment transactions. Such interface exists at the Consumers', the Merchants' and the Payment Handlers' installations connecting the actual payment software components/legacy systems and the generic IOTP aware front end application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-papi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q) Content-type: multipart/alternative; boundary="Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)" --Boundary_(ID_DrNEC/duxiY9uA42MMTqGA) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310140353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt --Boundary_(ID_DrNEC/duxiY9uA42MMTqGA) Content-type: Message/External-body; name="draft-ietf-trade-iotp-v1.0-papi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310140353.I-D@ietf.org> --Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)-- --Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00501LKHKY@eListX.com>; Mon, 13 Mar 2000 01:48:17 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00501LKGKX@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Mon, 13 Mar 2000 01:48:16 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00503LKGKV@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 01:48:16 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FRC00501LKFKU@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Mon, 13 Mar 2000 01:48:16 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FRC00267LKDE7@eListX.com> for ietf-trade@lists.eListX.com; Mon, 13 Mar 2000 01:48:15 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id PAA07897; Mon, 13 Mar 2000 15:45:37 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/09/00) with ESMTP id PAA02622; Mon, 13 Mar 2000 15:45:29 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by renoir.isl.ntt.co.jp (8.8.8/isl-2.0) id PAA02463; Mon, 13 Mar 2000 15:45:27 +0900 (JST) Date: Mon, 13 Mar 2000 15:45:27 +0900 From: Ko Fujimura Subject: Re: IOTP and Coupons (was RE: future OTP transactions) In-reply-to: "In your message of Fri, 10 Mar 2000 14:35:34 -0500" <2B30A9965635D311A29F002035297FFB1B2B33@se001010.rbc1.royalbank.com> To: CHRIS.SMITH@ROYALBANK.COM Cc: ietf-trade@lists.eListX.com Message-id: MIME-version: 1.0 (generated by REMI 1.14.0 - "Uragawara") Content-type: text/plain; charset=US-ASCII User-Agent: Wanderlust/2.2.18 (Please Forgive Me) REMI/1.14.0 (Uragawara) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) APEL/10.1 MULE XEmacs/21.2 (beta31) (Iris) (sparc-sun-solaris2.6) References: <2B30A9965635D311A29F002035297FFB1B2B33@se001010.rbc1.royalbank.com> Hi, At Fri, 10 Mar 2000 14:35:34 -0500, Smith, Chris wrote: > > [1 ] > Because the blocks in a PaymentRequest (the included > payment system data) have names, it would be possible > to add additional out-ot-payment-protocol blocks that > contained the needed information. > > This would be fine for IOTP, but some payment systems > might consider these additional blocks to be non-standard. > > In a more general case, you could take advantage of a > couple of other features: > > 1) IOTP allows Authentication transactions prior to > any other transaction. Also, the final version > provided a way to send several Authentication > types in the same request. > > A coupon is a form of authorization/authentication, > so a special Authentication Supplement could be > created to handle them. > > Thus a single Auth up front could be the equivalent > of the merchant asking "Do you have AirMiles", "Do > you have coupons", "Are you a club member" - all in > one step. > > Since the AUth precedes the OfferResponse generation, > any information returned on the Auth can be used to > make changes in pricing. > > 2) IOTP does allow for brand-dependent offers as well, > where the payment brand selection precedes the final > generation of the OfferResponse. Yes, the current IOTP spec allows several ways to process coupons, gift certificates, or loyality points. Redemption of a coupon, for example, can be implemented as the Offer, Payment, and/or Authentication Exchanges depending on the Merchant decision as Chris pointed out. Issuance of a coupon can also be implemented as the Delivery Exchanges. I would like to mention my understanding of the relationship between the Digital-Right Trading (DRT) and IOTP model. In short, I think that DRT is a component which can be commonly used within the IOTP Exchanges. In other words, I think that the DRT is layered under the IOTP Exchanges. > > -----Original Message----- > > From: David Bourget [mailto:dbourget@videotron.ca] > > Sent: January 6, 1998 09:15 AM > > To: ietf-trade@lists.eListX.com > > Subject: future OTP transactions > > > > > > Hi, > > > > First question: > > I'd like to know if there is plans for future OTP transactions > > supporting negociation of promotional offers and prices. > > Example : I've > > got a gift certificate, which is only a reference number, and I'd like > > to know its real value. This kind of interaction would allow current > > web-based promotional offers to be used in an OTP context. Since one of the goals of the Digital-Right Trading is to provide a common language to exchange such a promotional offer information needed in the IOTP exchanges, such kind of gift certificates should/can be covered in the DRT model and language. Using the language, it might be roughly defined as below, although the protocols might be left vendor-specific. Thanks, Ko ---------------------------------------------------------- Ko Fujimura, NTT Information Sharing Platform Laboratories 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-8329 Email: fujimura@isl.ntt.co.jp Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0117CNZ@eListX.com>; Fri, 10 Mar 2000 14:38:00 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0117CNY@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 10 Mar 2000 14:38:00 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0317BNW@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:37:59 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A0117BNV@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:37:59 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR8006FE17AIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 14:37:59 -0500 (EST) Received: from wsecure3.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 10 Mar 2000 19:34:58 +0000 (UT) Received: from 10.224.0.66 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 10 Mar 2000 14:35:16 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 10 Mar 2000 14:35:38 -0500 Date: Fri, 10 Mar 2000 14:35:34 -0500 From: "Smith, Chris " Subject: IOTP and Coupons (was RE: future OTP transactions) To: ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B33@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 14D791FE412069-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Because the blocks in a PaymentRequest (the included payment system data) have names, it would be possible to add additional out-ot-payment-protocol blocks that contained the needed information. This would be fine for IOTP, but some payment systems might consider these additional blocks to be non-standard. In a more general case, you could take advantage of a couple of other features: 1) IOTP allows Authentication transactions prior to any other transaction. Also, the final version provided a way to send several Authentication types in the same request. A coupon is a form of authorization/authentication, so a special Authentication Supplement could be created to handle them. Thus a single Auth up front could be the equivalent of the merchant asking "Do you have AirMiles", "Do you have coupons", "Are you a club member" - all in one step. Since the AUth precedes the OfferResponse generation, any information returned on the Auth can be used to make changes in pricing. 2) IOTP does allow for brand-dependent offers as well, where the payment brand selection precedes the final generation of the OfferResponse. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com P.S. Unless you have some psychic ability that allowed you to phrase such coherent questions over two years ago, you need to reset the clock on your system -- see the Sent: line below. > -----Original Message----- > From: David Bourget [mailto:dbourget@videotron.ca] > Sent: January 6, 1998 09:15 AM > To: ietf-trade@lists.eListX.com > Subject: future OTP transactions > > > Hi, > > First question: > I'd like to know if there is plans for future OTP transactions > supporting negociation of promotional offers and prices. > Example : I've > got a gift certificate, which is only a reference number, and I'd like > to know its real value. This kind of interaction would allow current > web-based promotional offers to be used in an OTP context. > > Second question: > Where can I find information about the current work related > to SCCD ? I > can't find anything on the web or the working group site. > > > > > > > --Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable IOTP and Coupons (was RE: future OTP transactions)

Because the blocks in a PaymentRequest (the = included
payment system data) have names, it would be = possible
to add additional out-ot-payment-protocol blocks = that
contained the needed information.

This would be fine for IOTP, but some payment = systems
might consider these additional blocks to be = non-standard.

In a more general case, you could take advantage of = a
couple of other features:

1) IOTP allows Authentication transactions prior = to
   any other transaction. Also, the final = version
   provided a way to send several = Authentication
   types in the same request.

   A coupon is a form of = authorization/authentication,
   so a special Authentication Supplement = could be
   created to handle them.

   Thus a single Auth up front could be the = equivalent
   of the merchant asking "Do you = have AirMiles", "Do
   you have coupons", "Are you a = club member" - all in
   one step.

   Since the AUth precedes the = OfferResponse generation,
   any information returned on the Auth = can be used to
   make changes in pricing.

2) IOTP does allow for brand-dependent offers as = well,
   where the payment brand selection = precedes the final
   generation of the OfferResponse.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com


P.S. Unless you have some psychic ability that = allowed you
to phrase such coherent questions over two years = ago, you
need to reset the clock on your system -- see the = Sent:
line below.

> -----Original Message-----
> From: David Bourget [mailto:dbourget@videotron.ca]<= /FONT>
> Sent: January 6, 1998 09:15 AM
> To: ietf-trade@lists.eListX.com
> Subject: future OTP transactions
>
>
> Hi,
>
> First question:
> I'd like to know if there is plans for future = OTP transactions
> supporting negociation of promotional offers = and prices.
> Example : I've
> got a gift certificate, which is only a = reference number, and I'd like
> to know its real value. This kind of = interaction would allow current
> web-based promotional offers to be used in an = OTP context.
>
> Second question:
> Where can I find information about the current = work related
> to SCCD ? I
> can't find anything on the web or the working = group site.
>
>
>
>
>
>
>

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A010N0LR@eListX.com>; Fri, 10 Mar 2000 14:25:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A010MZLQ@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 10 Mar 2000 14:25:48 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A030MZLO@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:25:47 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR800A010MZLN@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:25:47 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR8006EV0MYIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 14:25:46 -0500 (EST) Received: from wsecure3.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 10 Mar 2000 19:22:45 +0000 (UT) Received: from 10.224.0.67 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 10 Mar 2000 14:23:04 -0500 Received: by se001017.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 10 Mar 2000 14:23:25 -0500 Date: Fri, 10 Mar 2000 14:23:26 -0500 From: "Smith, Chris " Subject: Adopting IOTP (was RE: future OTP transactions) To: ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B31@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 14D79412410716-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit One question at a time... In my opinion, Version 1 of IOTP satisfies the requirements of the vast majority of e-retailing sites, as far as the customer side is concerned. Adoption is subject to the chicken-and-egg problem. Merchants won't jump in large numbers to a protocol (or even a full standard) unless their customers are using it. Customers won't jump in huge numbers unless they see merchants offering it. That said - IOTP is structured to make it's adoption relatively easy. For the simplest setup, the merchant will simply issue an OfferResponse, and then be prepared to accept a DeliveryRequest. The working idea is that the PaymentHandler is operated by one (or more - competition) agencies, much the way credit card processors operate today. The merchant's task is made considerably simpler if they don't have to handle the payment steps, just deliver when notified of successful payments. In a dedicated implementation, even if SCCD is used (which is roughly equivalent to SSL today) the merchant no longer carries the credit card info with its attendant risks. The risks are now transferred to the PaymentHandler - however, ensuring that relatively few PaymentHandlers are properly secured and defended is easier than ensuring that a relatively large number of Merchants are secured and defended. Interestingly, IOTP, if adopted, makes the addition of additional payment systems much easier. The merchant simply updates their offer to indicate the acceptance of the added payment system and the details of the PaymentHandler for that system. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com > -----Original Message----- > From: David Bourget [mailto:dbourget@videotron.ca] > Subject: Re: future OTP transactions > - Second, the real one: What are the expectations of the WG > about merchants > adoption of the protocol ? I'm talking about e-retailing > sites like Amazon, Cdnow > etc. Do you consider "baseline" OTP to fullfil most of their > requirements, i.e will > they have to wait until v2 ? --Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Adopting IOTP (was RE: future OTP transactions)

One question at a time...

In my opinion, Version 1 of IOTP satisfies the = requirements
of the vast majority of e-retailing sites, as far as = the
customer side is concerned.

Adoption is subject to the chicken-and-egg = problem.
Merchants won't jump in large numbers to a protocol = (or
even a full standard) unless their customers are = using
it. Customers won't jump in huge numbers unless they =
see merchants offering it.

That said - IOTP is structured to make it's adoption =
relatively easy. For the simplest setup, the = merchant will
simply issue an OfferResponse, and then be prepared = to
accept a DeliveryRequest. The working idea is that = the
PaymentHandler is operated by one (or more - = competition)
agencies, much the way credit card processors = operate today.
The merchant's task is made considerably simpler if = they
don't have to handle the payment steps, just deliver = when
notified of successful payments. In a dedicated =
implementation, even if SCCD is used (which is = roughly
equivalent to SSL today) the merchant no longer = carries the
credit card info with its attendant risks. The risks = are
now transferred to the PaymentHandler - however, = ensuring
that relatively few PaymentHandlers are properly = secured
and defended is easier than ensuring that a = relatively
large number of Merchants are secured and = defended.

Interestingly, IOTP, if adopted, makes the addition = of
additional payment systems much easier. The merchant = simply
updates their offer to indicate the acceptance of = the added
payment system and the details of the PaymentHandler = for
that system.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com



> -----Original Message-----
> From: David Bourget [mailto:dbourget@videotron.ca]<= /FONT>
> Subject: Re: future OTP transactions

> - Second, the real one: What are the = expectations of the WG
> about merchants
> adoption of the protocol ? I'm talking about = e-retailing
> sites like Amazon, Cdnow
> etc. Do you consider "baseline" OTP = to fullfil most of their
> requirements, i.e will
> they have to wait until v2 ?

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A01ZXCJS@eListX.com>; Fri, 10 Mar 2000 14:10:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A01ZXCJR@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 10 Mar 2000 14:10:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A03ZXBJP@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:10:23 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700A01ZXBJO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 10 Mar 2000 14:10:23 -0500 (EST) Received: from smtp1.royalbank.com (smtp1.royalbank.com [198.96.131.40]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR7006EPZXAIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 14:10:23 -0500 (EST) Received: from wsecure2.royalbank.com by smtp1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 10 Mar 2000 19:07:22 +0000 (UT) Received: from 10.224.0.66 by se001020.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6.2); Fri, 10 Mar 2000 14:09:10 -0500 Received: by SE001016.rbc1.royalbank.com with Internet Mail Service ( 5.5.2448.0) id ; Fri, 10 Mar 2000 14:08:02 -0500 Date: Fri, 10 Mar 2000 14:08:02 -0500 From: "Smith, Chris " Subject: RE: error handling To: ietf-trade@lists.eListX.com Message-id: <2B30A9965635D311A29F002035297FFB1B2B30@se001010.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)" X-Server-Uuid: d237928a-6c98-11d3-985c-00a0c9ea509d X-WSS-ID: 14D797DC4616006-01-01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_zth3wilshPvLHxAEHc2xoQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit At some point, the client will determine that there is a problem, either because some evidence of an unacceptable reply exists, or because a timeout expires. In both cases, the client is permitted to resubmit the original request. (Keep in mind that the client does not know whether or not the original was even received by the server.) At the server side, the receipt of identical requests is supposed to result in the return of the original corresponding reply. Thus, even if the server has processed the request once already, the response can be retrieved a second time without difficulty. (A corollary to this is that the server is expected to check all inbound requests to see if they are duplicates of previous requests.) Over the most common transport, HTTP, there are no sessions held open. As a result, the client can even become disconnected from the network, but if the client has done a proper job of retaining state on its end, the final request can be re-sent, and the transaction completed, once the network reconnects. ------------------------------------------------------------ Chris Smith +1.416.348.6090 Royal Bank chris.smith@royalbank.com > -----Original Message----- > From: David Bourget [mailto:dbourget@videotron.ca] > Subject: error handling > What happen if there is an error in the last message of a transaction > happing over HTTP ? The last message, maybe a delivery note, > is supposed > to close the transaction so the server will not be waiting for a > confirmation before commiting the changes made in the > transaction. This > mean that at this point the transaction cannot be rolled back. But if > the last message is all garbage, then our customer is in trouble. What > is the solution provided by the OTP to this problem ? --Boundary_(ID_zth3wilshPvLHxAEHc2xoQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: error handling

At some point, the client will determine that there = is a problem,
either because some evidence of an unacceptable = reply exists, or
because a timeout expires.

In both cases, the client is permitted to resubmit = the original
request. (Keep in mind that the client does not know = whether or
not the original was even received by the = server.)

At the server side, the receipt of identical requests = is supposed
to result in the return of the original = corresponding reply. Thus,
even if the server has processed the request once = already, the
response can be retrieved a second time without = difficulty. (A
corollary to this is that the server is expected to = check all
inbound requests to see if they are duplicates of = previous requests.)

Over the most common transport, HTTP, there are no = sessions held open.
As a result, the client can even become disconnected = from the network,
but if the client has done a proper job of retaining = state on its
end, the final request can be re-sent, and the = transaction completed,
once the network reconnects.

------------------------------------------------------------ =
=A0Chris = Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090
=A0Royal = Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = chris.smith@royalbank.com

> -----Original Message-----
> From: David Bourget [mailto:dbourget@videotron.ca]<= /FONT>
> Subject: error handling

> What happen if there is an error in the last = message of a transaction
> happing over HTTP ? The last message, maybe a = delivery note,
> is supposed
> to close the transaction so the server will not = be waiting for a
> confirmation before commiting the changes made = in the
> transaction. This
> mean that at this point the transaction cannot = be rolled back. But if
> the last message is all garbage, then our = customer is in trouble. What
> is the solution provided by the OTP to this = problem ?

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M94GH@eListX.com>; Fri, 10 Mar 2000 09:15:04 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M94GG@eListX.com> (original mail from services@eListX.com); Fri, 10 Mar 2000 09:15:04 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700903M93GE@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:15:03 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M93GD@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:15:03 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M93GC@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 09:15:03 -0500 (EST) Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR70066U6OZIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:39:00 -0500 (EST) Received: from videotron.ca ([24.200.182.123]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FR7008GC6L2X1@field.videotron.net> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:36:39 -0500 (EST) Resent-date: Fri, 10 Mar 2000 09:15:03 -0500 (EST) Date: Tue, 03 Mar 1998 17:48:35 -0500 From: David Bourget Subject: error handling Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR700902M93GD@eListX.com> Message-id: <34FC88C3.8A086D35@videotron.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [fr] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr Hi, I'm almost flooding this mailing list these days, but I've got a puzzling question : What happen if there is an error in the last message of a transaction happing over HTTP ? The last message, maybe a delivery note, is supposed to close the transaction so the server will not be waiting for a confirmation before commiting the changes made in the transaction. This mean that at this point the transaction cannot be rolled back. But if the last message is all garbage, then our customer is in trouble. What is the solution provided by the OTP to this problem ? thank you, David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7MG9@eListX.com>; Fri, 10 Mar 2000 09:14:10 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7MG8@eListX.com> (original mail from services@eListX.com); Fri, 10 Mar 2000 09:14:10 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700903M7LG6@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:14:09 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7LG5@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Fri, 10 Mar 2000 09:14:09 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR700901M7LG4@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 09:14:09 -0500 (EST) Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR70066K52OIS@eListX.com> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:04:01 -0500 (EST) Received: from videotron.ca ([24.200.182.123]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FR7005MR4YRGO@field.videotron.net> for ietf-trade@lists.eListX.com; Fri, 10 Mar 2000 03:01:39 -0500 (EST) Resent-date: Fri, 10 Mar 2000 09:14:09 -0500 (EST) Date: Wed, 07 Jan 1998 17:13:50 -0500 From: David Bourget Subject: Re: future OTP transactions Sender: services@eListX.com To: "Donald E. Eastlake 3rd" Cc: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR700902M7LG5@eListX.com> Message-id: <34B3FE1E.CDFAC109@videotron.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [fr] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr References: <200003100406.XAA17543@torque.pothole.com> Hi, Thank you for the information Donald. I'm presently studying the specification and two other questions arises that you or other people on this mailing list might be able to answer : - First, trivial question: is there a version of the 1.0 draft in word, html or any kind of browsable format that would make the experience more enjoyable than scrolling in a 200 pages ASCII file ? I can't find any. That is, can I have the source ? (I have found the version on otp.org to be not enaught current) - Second, the real one: What are the expectations of the WG about merchants adoption of the protocol ? I'm talking about e-retailing sites like Amazon, Cdnow etc. Do you consider "baseline" OTP to fullfil most of their requirements, i.e will they have to wait until v2 ? - Finaly, a third question : I'm trying to fit the baseline purchase transaction on current .com merchants purchase transaction model and the following questions arise : - Can a baseline purchase transaction happen as follow : [ client ] [ merchant ] shop select shipping --- I wanna buy--> start transaction here <-----order,brandslist etc---- prepare order select payment -------( very simple payment process payment, generate delivery note protocol, that is : here's my card number )-----> happy customer <---------delivery note-------- In fact, I'm trying to figure out what is the simplest form of a purchase transaction supported by an OTP agent. It seems to me that being able to do such simples transactions is a priority for online merchants who wants to save bandwidth and streamline the buying process. regards, David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701W5OVL@eListX.com>; Thu, 9 Mar 2000 23:51:25 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701W5OVK@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 09 Mar 2000 23:51:24 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600703W5OVI@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 23:51:24 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701W5NVH@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 23:51:23 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR60065KW5LIS@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 23:51:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA27249 for ietf-trade@lists.elistx.com; Thu, 09 Mar 2000 23:49:47 -0500 (EST) Date: Thu, 09 Mar 2000 23:49:47 -0500 From: "Donald E. Eastlake 3rd" Subject: More on APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003100449.XAA27249@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp The MIME type registartion template I posted to the ietf-types list has caused a lot of comment. None of it is really about IOTP, it is all about two issues: (1) should it really be APPLICATION/IOTP-XML and (2) should it allow/require a charset parameter That is, people are arguing about whether all new XML content MIME types should have a subtype with a "-xml" on the end. I would assume we don't want to change due to existing implementations. On the charset paramter issue, I think I should add it as an optional parameter. Section F of the XML 1.0 specification makes it clear that the charset as indicated by the actual data including any byte order mark and encoding declaration and that any "external" charset, as the charset parameter would be, is "solely for error recovery." Thanks, donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) Carmel, NY 10512 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701UHHS8@eListX.com>; Thu, 9 Mar 2000 23:15:17 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701UHGS7@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 09 Mar 2000 23:15:16 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600703UHGS5@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:15:16 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701UHFS4@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:15:15 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR60064TUHDIS@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 23:15:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA17664; Thu, 09 Mar 2000 23:13:33 -0500 (EST) Date: Thu, 09 Mar 2000 23:13:33 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: question about IotpSignature..! In-reply-to: "Your message of Thu, 09 Mar 2000 14:44:17 +0800." To: Andre Chan Cc: IOTP Group Message-id: <200003100413.XAA17664@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp It's just the declaration of three algorithms. Each is identified by an ID. All of them but algorithm A2 take as an explicit parameter or argument another algorithm identified by an ID. I don't know what you mean by "using sha1 first". It is dom-hash which produces a serialization of the DOM which is fed to sha1. Donald From: Andre Chan Date: Thu, 09 Mar 2000 14:44:17 +0800 To: IOTP Group Resent-message-id: <0FR500402OWE42@eListX.com> Message-id: > I would like to ask what is the meaning of the Element "Parameter". From >the example below (which I copy for the doc >"draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the >signature are generated by the following sequence A2, A1, A3. That means I >will use sha1 first, then dom-hash and finally use the rsa to sign it. But, >the right sequence should be A1, A2, A3. How do I interpret the meaning of >the below example? > > > A2 > > > > > A1 > > >Thanks > >Andre > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701U52PT@eListX.com>; Thu, 9 Mar 2000 23:07:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701U52PS@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 09 Mar 2000 23:07:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600703U51PQ@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:07:49 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR600701U51PP@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 23:07:49 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR60064NU4ZIS@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 23:07:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA17543; Thu, 09 Mar 2000 23:06:06 -0500 (EST) Date: Thu, 09 Mar 2000 23:06:06 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: future OTP transactions In-reply-to: "Your message of Tue, 06 Jan 1998 09:15:22 EST." <34B23C7A.68969715@videotron.ca> To: dbourget@videotron.ca Cc: ietf-trade@lists.eListX.com Message-id: <200003100406.XAA17543@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp Truly different structured transactions will probably wait until IOTP v2. Digital Right such as promotional offers are also being a topic which has been discussed at TRADE WG meetings. See . I post an additonal response on SCCD shortly. Donald From: David Bourget Resent-From: ietf-trade-errors@lists.eListX.com Resent-date: Thu, 09 Mar 2000 08:15:40 -0500 (EST) Date: Tue, 06 Jan 1998 09:15:22 -0500 Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR500402OU53S@eListX.com> Message-id: <34B23C7A.68969715@videotron.ca> >Hi, > >First question: >I'd like to know if there is plans for future OTP transactions >supporting negociation of promotional offers and prices. Example : I've >got a gift certificate, which is only a reference number, and I'd like >to know its real value. This kind of interaction would allow current >web-based promotional offers to be used in an OTP context. > >Second question: >Where can I find information about the current work related to SCCD ? I >can't find anything on the web or the working group site. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWG46@eListX.com>; Thu, 9 Mar 2000 08:17:04 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWF45@eListX.com> (original mail from services@eListX.com); Thu, 09 Mar 2000 08:17:03 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500403OWF43@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:17:03 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWE42@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:17:02 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OWE41@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 08:17:02 -0500 (EST) Received: from mailgw.ust.hk (mailgw.ust.hk [143.89.14.35]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR5000956JL7A@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 01:40:35 -0500 (EST) Received: from imaila.ust.hk (imaila.ust.hk [143.89.14.173]) by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id OAA18437 for ; Thu, 09 Mar 2000 14:30:33 +0800 (HKT) Received: from imz133 (imz133.ust.hk [143.89.56.96]) by imaila.ust.hk (8.9.3/8.9.3) with SMTP id OAA13104 for ; Thu, 09 Mar 2000 14:35:23 +0800 (HKT) Resent-date: Thu, 09 Mar 2000 08:17:02 -0500 (EST) Date: Thu, 09 Mar 2000 14:44:17 +0800 From: Andre Chan Subject: question about IotpSignature..! Sender: services@eListX.com To: IOTP Group Resent-message-id: <0FR500402OWE42@eListX.com> Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal I would like to ask what is the meaning of the Element "Parameter". From the example below (which I copy for the doc "draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the signature are generated by the following sequence A2, A1, A3. That means I will use sha1 first, then dom-hash and finally use the rsa to sign it. But, the right sequence should be A1, A2, A3. How do I interpret the meaning of the below example? A2 A1 Thanks Andre Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU63W@eListX.com>; Thu, 9 Mar 2000 08:15:42 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU53V@eListX.com> (original mail from services@eListX.com); Thu, 09 Mar 2000 08:15:42 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500403OU53T@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:15:41 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU53S@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Thu, 09 Mar 2000 08:15:41 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR500401OU43R@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 08:15:40 -0500 (EST) Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR40004XOXL7A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 19:20:09 -0500 (EST) Received: from videotron.ca ([24.200.182.123]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FR4005I5OTDH0@falla.videotron.net> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 19:17:38 -0500 (EST) Resent-date: Thu, 09 Mar 2000 08:15:40 -0500 (EST) Date: Tue, 06 Jan 1998 09:15:22 -0500 From: David Bourget Subject: future OTP transactions Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR500402OU53S@eListX.com> Message-id: <34B23C7A.68969715@videotron.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [fr] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr Hi, First question: I'd like to know if there is plans for future OTP transactions supporting negociation of promotional offers and prices. Example : I've got a gift certificate, which is only a reference number, and I'd like to know its real value. This kind of interaction would allow current web-based promotional offers to be used in an OTP context. Second question: Where can I find information about the current work related to SCCD ? I can't find anything on the web or the working group site. Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301K14QB@eListX.com>; Thu, 9 Mar 2000 06:31:52 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301K13QA@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Thu, 09 Mar 2000 06:31:52 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500303K13Q8@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 06:31:51 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301K13Q7@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 06:31:51 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR5000COK127A@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 06:31:50 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24973; Thu, 09 Mar 2000 06:29:32 -0500 (EST) Date: Thu, 09 Mar 2000 06:29:31 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-mime-detector-02.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003091129.GAA24973@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)" --Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : HTTP MIME Type Handler Detection Author(s) : D. Eastlake 3rd, C. Smith, D. Soroka Filename : draft-ietf-trade-mime-detector-02.txt Pages : 13 Date : 08-Mar-00 Entities composing web pages to provide services over HTTP frequently have the problem of not knowing what MIME types have handlers installed at a user's browser. For example, whether an IOTP or VRML or SET or some streaming media handler is available. In many cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes a reasonable technique to solve this problem for most of the browsers actually deployed on the Internet as of August 1999. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-mime-detector-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-mime-detector-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ) Content-type: multipart/alternative; boundary="Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)" --Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000308131848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt --Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg) Content-type: Message/External-body; name="draft-ietf-trade-mime-detector-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131848.I-D@ietf.org> --Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)-- --Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301BRJ8Q@eListX.com>; Thu, 9 Mar 2000 03:33:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301BRJ8P@eListX.com> (original mail from rudolf@metechnology.com) ; Thu, 09 Mar 2000 03:33:19 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500303BRJ8N@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 03:33:19 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR500301BRI8M@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Thu, 09 Mar 2000 03:33:18 -0500 (EST) Received: from matavnet.hu (matavnet.hu [145.236.224.246]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR5000ATBRH7A@eListX.com> for ietf-trade@lists.eListX.com; Thu, 09 Mar 2000 03:33:18 -0500 (EST) Received: (qmail 88 invoked from network); Thu, 09 Mar 2000 09:30:51 +0100 Received: from line-208-38.dial.matav.net (HELO apps) (145.236.208.38) by mail.matav.hu with SMTP; Thu, 09 Mar 2000 09:30:51 +0100 Received: from 10.0.0.10 by apps ([10.0.0.1] running VPOP3) with SMTP; Thu, 09 Mar 2000 09:22:17 +0100 Date: Thu, 09 Mar 2000 09:22:16 +0100 From: Rudolf Hornig Subject: RE: IOTP implementations In-reply-to: <200003090030.TAA13544@torque.pothole.com> To: "'Donald E. Eastlake 3rd'" Cc: ietf-trade@lists.eListX.com Reply-to: rudolf@metechnology.com Message-id: <000401bf89a0$95205500$0a00000a@MeTechnology.hu> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Server: VPOP3 V1.3.0b - Registered to: Me Technology This is a multi-part message in MIME format. --Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit > As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal > Bank of Canada. > > The following have said they are implementing IOTP 1.0: > Hitachi (SMILE Project) > Royal Bank of Canada > SIZ > CyberSource > Differential > Xenosys Corporation > > Donald We have also an 1.0 implementation here at Brokat... Rudolf -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rudolf Hornig (Rudolf@MeTechnology.com), Project Leader MeTechnology Ltd. Hungary - a Brokat Company -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg) Content-type: text/x-vcard; name="Rudolf Hornig (E-mail).vcf" Content-disposition: attachment; filename="Rudolf Hornig (E-mail).vcf" Content-transfer-encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Hornig;Rudolf FN:Rudolf Hornig (E-mail) ORG:MeTechnology Ltd. (Hungary) - a Brokat Company;Research&Development TITLE:Project Manager TEL;WORK;VOICE:+36 (1) 437 04 13 TEL;WORK;FAX:+36 (1) 387 37 98 ADR;WORK:;;Kunigunda utca 58.;Budapest;;H1037;Hungary LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Kunigunda utca 58.=0D=0ABudapest H1037=0D=0AHungary KEY;X509;ENCODING=BASE64: MIICjDCCAfWgAwIBAgIDAUf1MA0GCSqGSIb3DQEBBAUAMIG5MQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3 OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4 LjkuMTYwHhcNOTkwODI0MDg0MDA3WhcNMDAwODIzMDg0MDA3WjBJMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdydWRvbGZATWVUZWNobm9sb2d5 LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDH8coNT3BGTG4HGqz08KaFHSjONYQ6BLta HwjWmfH0j+M/hQp86tPpLB73RQjDt5lsbb/EkzGA6QShkabMQyBLAgMBAAGjVTBTMCIGA1Ud EQQbMBmBF3J1ZG9sZkBNZVRlY2hub2xvZ3kuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEACHlsv89kEhISAVFs 1TdW9KKW8kluUJDjC7DDnAEgiCLw6mlm2kvHW3NzYONaefEsCBOsYVOIOBg4RW15HCR4+eay dEuGJXi510jSc2DN/uyYjNB4okvGKYl/zEbgTqJFEUEjwHtSFDIspCbufD1bj4I0/GQc1+fP Vv/VePfpVqo= EMAIL;PREF;INTERNET:rudolf@MeTechnology.com REV:19990830T133416Z END:VCARD --Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400201VB836@eListX.com>; Wed, 8 Mar 2000 21:37:56 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400201VB635@eListX.com> (original mail from ron@paybycheck.com); Wed, 08 Mar 2000 21:37:55 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400203VB632@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 21:37:54 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400201VB531@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 21:37:53 -0500 (EST) Received: from paybycheck.com ([208.49.29.160]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR40006ZVB37A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 21:37:52 -0500 (EST) Received: from zort [10.10.10.133] by paybycheck.com (SMTPD32-6.00) id ADF53860050; Wed, 08 Mar 2000 18:35:33 -0800 Date: Wed, 08 Mar 2000 18:37:16 -0800 From: Ron Ehli Subject: RE: IOTP implementations In-reply-to: <200003090030.TAA13544@torque.pothole.com> To: ietf-trade@lists.eListX.com Message-id: <003501bf8970$624b55b0$850a0a0a@zort.itinternet.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal PayByCheck.com is also implementing IOTP 1.0 for select services. > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: Wednesday, March 08, 2000 4:31 PM > To: dbourget@videotron.ca > Cc: ietf-trade@lists.eListX.com > Subject: Re: IOTP implementations > > > > As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal > Bank of Canada. > > The following have said they are implementing IOTP 1.0: > Hitachi (SMILE Project) > Royal Bank of Canada > SIZ > CyberSource > Differential > Xenosys Corporation > > Donald > > From: David Bourget > Resent-From: ietf-trade-errors@lists.eListX.com > Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST) > Date: Wed, 08 Mar 2000 15:44:07 -0500 > Sender: services@eListX.com > To: ietf-trade@lists.eListX.com > Reply-to: dbourget@videotron.ca > Resent-message-id: <0FR400002GEDQG@eListX.com> > Message-id: <20000308154407.B1997@davidspirit.brg> > > >Hi, > > > >Could someone give me some pointers on early IOTP > implementations ? Is there any ? > > > >/David > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400101PIFNB@eListX.com>; Wed, 8 Mar 2000 19:32:40 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400101PIFNA@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 08 Mar 2000 19:32:39 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400103PIFN8@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 19:32:39 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400101PIEN7@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 08 Mar 2000 19:32:38 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR400056PIC7A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 19:32:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id TAA13544; Wed, 08 Mar 2000 19:30:59 -0500 (EST) Date: Wed, 08 Mar 2000 19:30:59 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: IOTP implementations In-reply-to: "Your message of Wed, 08 Mar 2000 15:44:07 EST." <20000308154407.B1997@davidspirit.brg> To: dbourget@videotron.ca Cc: ietf-trade@lists.eListX.com Message-id: <200003090030.TAA13544@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal Bank of Canada. The following have said they are implementing IOTP 1.0: Hitachi (SMILE Project) Royal Bank of Canada SIZ CyberSource Differential Xenosys Corporation Donald From: David Bourget Resent-From: ietf-trade-errors@lists.eListX.com Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST) Date: Wed, 08 Mar 2000 15:44:07 -0500 Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR400002GEDQG@eListX.com> Message-id: <20000308154407.B1997@davidspirit.brg> >Hi, > >Could someone give me some pointers on early IOTP implementations ? Is there any ? > >/David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEEQK@eListX.com>; Wed, 8 Mar 2000 16:15:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEEQJ@eListX.com> (original mail from services@eListX.com); Wed, 08 Mar 2000 16:15:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400003GEDQH@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 16:15:49 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEDQG@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 16:15:49 -0500 (EST) Received: from eListX.com by eListX.com (PMDF V5.2-32 #43584) id <0FR400001GEDQF@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 16:15:49 -0500 (EST) Received: from davidspirit.brg (modemcable123.182-200-24.que.mc.videotron.net [24.200.182.123]) by eListX.com (PMDF V5.2-32 #43584) with SMTP id <0FR40001JF0Z7A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 15:46:15 -0500 (EST) Received: (qmail 2021 invoked by uid 500); Wed, 08 Mar 2000 20:44:07 +0000 Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST) Date: Wed, 08 Mar 2000 15:44:07 -0500 From: David Bourget Subject: IOTP implementations Sender: services@eListX.com To: ietf-trade@lists.eListX.com Reply-to: dbourget@videotron.ca Resent-message-id: <0FR400002GEDQG@eListX.com> Message-id: <20000308154407.B1997@davidspirit.brg> MIME-version: 1.0 X-Mailer: Mutt 1.0pre2i Content-type: text/plain; charset=us-ascii Hi, Could someone give me some pointers on early IOTP implementations ? Is there any ? /David Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001DZ8HQ@eListX.com>; Wed, 8 Mar 2000 15:23:32 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001DZ7HP@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 08 Mar 2000 15:23:31 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400003DZ7HN@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 15:23:31 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR400001DZ6HM@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 08 Mar 2000 15:23:31 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR40001ADZ47A@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Mar 2000 15:23:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id PAA12759 for ietf-trade@lists.elistx.com; Wed, 08 Mar 2000 15:21:45 -0500 (EST) Date: Wed, 08 Mar 2000 15:21:45 -0500 From: "Donald E. Eastlake 3rd" Subject: APPLICATION/IOTP To: ietf-trade@lists.eListX.com Message-id: <200003082021.PAA12759@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp I went ahead and sent APPLICATION/IOTP to the IETF-Types list, like you are supposed to for new MIME types, and Ned Freed, who is the type czar, thinks its OK. draft-ietf-trade-iotp-http-04.txt still needs to be approved by the IESG. Donald ------- Forwarded Message From: ned.freed@innosoft.com Date: Wed, 08 Mar 2000 12:09:27 -0800 (PST) Subject: Re: Registration of MIME media type APPLICATION/IOTP In-reply-to: "Your message dated Wed, 08 Mar 2000 14:59:59 -0500" <200003081959.OAA12922@torque.pothole.com> To: "Donald E. Eastlake 3rd" Cc: ietf-types@uninett.no, dee3@torque.pothole.com Message-id: <01JMSFWMB7CG000O8C@MAUVE.INNOSOFT.COM> This registration looks fine to me. Ned > [See also draft-ietf-trade-iotp-http-04.txt] > MIME media type name: APPLICATION > MIME subtype name: IOTP > Required parameters: (none) > Optional parameters: (none) > Encoding considerations: Content is XML and may in some cases > require quoted printable or base64 encoding. However, no encoding > is required for HTTP transport which is expected to be common. > Security considerations: IOTP includes provisions for digital > authentication but for confidentiality, other mechanisms such as > TLS should be used. See Security Consideration section of > draft-ietf-trade-iotp-v1.0-protocol-07.txt in RFC Editor's queue. > Interoperability considerations: See draft-ietf-trade-iotp-v1.0- > protocol-07.txt in RFC Editor's queue. > Published specification: See draft-ietf-trade-iotp-v1.0-protocol- > 07.txt in RFC Editor's queue. > Applications which use this media type: Internet Open Trading > Protocol applications. > Additional information: (none) > Person & email address to contact for further information: > Name: Donald E. Eastlake 3rd > Email: Donald.Eastlake@motorola.com > Intended usage: COMMON > Author/Change controller: IETF > ===================================================================== > Donald E. Eastlake 3rd dee3@torque.pothole.com > 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) > Carmel, NY 10512 USA +1 508-261-5434(w) ------- End of Forwarded Message Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100101UP6OW@eListX.com>; Tue, 7 Mar 2000 06:31:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100101UP5OV@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Tue, 07 Mar 2000 06:31:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100103UP5OT@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 07 Mar 2000 06:31:53 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FR100101UP5OS@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Tue, 07 Mar 2000 06:31:53 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FR100M7GUP41I@eListX.com> for ietf-trade@lists.eListX.com; Tue, 07 Mar 2000 06:31:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29267; Tue, 07 Mar 2000 06:29:36 -0500 (EST) Date: Tue, 07 Mar 2000 06:29:35 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-http-04.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200003071129.GAA29267@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)" --Boundary_(ID_QkGemhOeIA11z+6ONPAmBw) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Internet Open Trading Protocol (IOTP) HTTP Supplement Author(s) : D. Eastlake 3rd, C. Smith Filename : draft-ietf-trade-iotp-http-04.txt Pages : 9 Date : 06-Mar-00 Internet Open Trading Protocol (IOTP [draft-ietf-trade-iotp-v1.0- protocol-*.txt]) messages will be carried as XML documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This documents describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-http-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-http-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_QkGemhOeIA11z+6ONPAmBw) Content-type: multipart/alternative; boundary="Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)" --Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt --Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w) Content-type: Message/External-body; name="draft-ietf-trade-iotp-http-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120547.I-D@ietf.org> --Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)-- --Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)-- Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00401YKPGC@eListX.com>; Fri, 3 Mar 2000 00:14:50 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00401YKPGB@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Fri, 03 Mar 2000 00:14:49 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00403YKPG9@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 03 Mar 2000 00:14:49 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQT00401YKOG8@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Fri, 03 Mar 2000 00:14:48 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQT001CAYKL49@eListX.com> for ietf-trade@lists.eListX.com; Fri, 03 Mar 2000 00:14:48 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id OAA27454; Fri, 03 Mar 2000 14:12:31 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/13/00) with ESMTP id OAA05785; Fri, 03 Mar 2000 14:12:22 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from renoir.isl.ntt.co.jp by renoir.isl.ntt.co.jp (8.8.8/isl-2.0) id OAA01005; Fri, 03 Mar 2000 14:12:08 +0900 (JST) Date: Fri, 03 Mar 2000 14:12:08 +0900 From: Ko Fujimura Subject: Re: Has any agenda come out In-reply-to: "In your message of Wed, 01 Mar 2000 22:03:24 -0500" <200003020303.WAA05084@torque.pothole.com> To: dee3@torque.pothole.com Cc: ietf-trade@lists.eListX.com Message-id: MIME-version: 1.0 (generated by REMI 1.14.0 - "Uragawara") Content-type: text/plain; charset=US-ASCII User-Agent: REMI/1.14.0 (Uragawara) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) APEL/10.1 MULE XEmacs/21.2 (beta31) (Iris) (sparc-sun-solaris2.6) References: <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> <200003020303.WAA05084@torque.pothole.com> At Wed, 01 Mar 2000 22:03:24 -0500, Donald E. Eastlake 3rd wrote: > > Nope. I'll try to get a preliminary one out soon. People are welcom > to send me suggestions. I would like to have time to talk about the objective of digital-right trading briefly again, and discuss on the major requirements, e.g., necessity of transferability, introduction of a parameter in the digital-right definition language to select digital-right trading protocol. I think it will need about 20 minute. Is there anyone else who would like to talk about on digital-right trading? I'm also very interested in the requirements for ECML version 2. I'm looking forward to see the draft. Regards, Ko ---------------------------------------------------------- Ko Fujimura, NTT Information Sharing Platform Laboratories 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-8329 Email: fujimura@isl.ntt.co.jp Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01XYKZ9@eListX.com>; Wed, 1 Mar 2000 22:06:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01XYKZ8@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 01 Mar 2000 22:06:20 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K03XYJZ6@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 22:06:19 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01XYJZ5@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 22:06:19 -0500 (EST) Received: from torque.pothole.com ([209.94.126.195]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQR00IG2XYG3V@eListX.com> for ietf-trade@lists.eListX.com; Wed, 01 Mar 2000 22:06:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id WAA05084; Wed, 01 Mar 2000 22:03:24 -0500 (EST) Date: Wed, 01 Mar 2000 22:03:24 -0500 From: "Donald E. Eastlake 3rd" Subject: Re: Has any agenda come out In-reply-to: "Your message of Thu, 02 Mar 2000 13:12:25 +1030." <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> To: Chun OUYANG Cc: ietf-trade@lists.eListX.com Message-id: <200003020303.WAA05084@torque.pothole.com> X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol X-MTS: smtp Nope. I'll try to get a preliminary one out soon. People are welcom to send me suggestions. Thanks, Donald From: Chun OUYANG Date: Thu, 02 Mar 2000 13:12:25 +1030 Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> Organization: ITR >Has any agenda of trade WG in the coming IETF come out? > >Chun Ouyang > Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01W36TQ@eListX.com>; Wed, 1 Mar 2000 21:25:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01W35TP@eListX.com> (original mail from ouyang@SPRI.Levels.UniSA.Edu.Au); Wed, 01 Mar 2000 21:25:54 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K03W35TN@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 21:25:53 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01W35TM@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.eListX.com); Wed, 01 Mar 2000 21:25:53 -0500 (EST) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQR00IFQW313V@eListX.com> for ietf-trade@lists.eListX.com; Wed, 01 Mar 2000 21:25:52 -0500 (EST) Received: from spri.levels.unisa.edu.au (ouyang@brezhnev [172.17.0.22]) by server1.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id MAA28560 for ; Thu, 02 Mar 2000 12:53:12 +1030 (CST) Date: Thu, 02 Mar 2000 13:12:25 +1030 From: Chun OUYANG Subject: Has any agenda come out Sender: ouyang@SPRI.Levels.UniSA.Edu.Au To: ietf-trade@lists.eListX.com Message-id: <38BDD510.9C8AEA9@spri.levels.unisa.edu.au> Organization: ITR MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Has any agenda of trade WG in the coming IETF come out? Chun Ouyang Return-Path: Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01UJYMJ@eListX.com>; Wed, 1 Mar 2000 20:52:47 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01UJYMI@eListX.com> (original mail from blondeau@exoffice.com) ; Wed, 01 Mar 2000 20:52:46 -0500 (EST) Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K03UJXMG@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 01 Mar 2000 20:52:45 -0500 (EST) Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-32 #43584) id <0FQR00K01UJXMF@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822;ietf-trade@lists.elistx.com); Wed, 01 Mar 2000 20:52:45 -0500 (EST) Received: from titan.exoffice.com (host98.ridgeventures.com [207.33.160.98]) by eListX.com (PMDF V5.2-32 #43584) with ESMTP id <0FQR00IEUUJW3V@eListX.com> for ietf-trade@lists.eListX.com; Wed, 01 Mar 2000 20:52:45 -0500 (EST) Received: from aquarium (fwin.exoffice.com [207.33.160.97]) by titan.exoffice.com (8.9.3/8.9.3) with SMTP id RAA05433 for ; Wed, 01 Mar 2000 17:50:35 -0800 Date: Wed, 01 Mar 2000 17:46:26 -0800 From: David Blondeau Subject: [ietf-trade] OT: This is a test To: ietf-trade@lists.eListX.com Message-id: <009301bf83e9$1f74a520$1101a8c0@aquarium> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)" X-Priority: 3 X-MSMail-priority: Normal This is a multi-part message in MIME format. --Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable As I didn't receive any mail since I have subscribed (5 days), I make a = test=20 David Blondeau --Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ) Content-type: text/html; charset="iso-8859-1" Content-transfer-encoding: quoted-printable
As I didn't receive any mail since I = have=20 subscribed (5 days), I make a test
David = Blondeau
--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)--